You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2014/07/10 10:55:57 UTC
Ideas for standardizing CXF authentication and authorization
CXF already supports a wide range of authentication and authorization
methods. Each of these has to be configured differently though
and some are almost unknown by users.
So I would like to improve that by standardizing on a common approach
that covers all existing variants but makes them accessible in the same way.
The only real java standard for authentication is JAAS. It is built into
the jre and quite flexible. Security frameworks normally also integrate
well with JAAS.
So the idea is to standardize on JAAS for authentication.
Authorization on the other hand has very diverse requirements and in
fact is not really directly coupled to CXF at all. After all the same
kind of authorization also has to happen in the UI and in the business code.
So the idea there is to solve authorization outside of CXF and base the
authorization on the JAAS login CXF provides.
I have written down my ideas in detail on:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42568988
I would be very interested in your feedback on my ideas.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Ideas for standardizing CXF authentication and authorization
Posted by Christian Schneider <ch...@die-schneider.net>.
I think it could still work at least partly.
In a project we had a similar requirement. The service call was
authenticated using a SAML token from an STS server.
So we did the following. In a first step we mapped from the identity
provided by the saml token to a username. Then we used a modified
LdapLoginModule to do the JAAS login.
As the authentication already happened inside WS-Security we made the
LdapLoginModule skip the password check and just establish the JAAS
login context and add the roles of the user.
So the effect was that we had a JAAS login that could be used for
authorization. So the authorization part was the same as with a username
/ password based authentication.
I think our approach could event be improved. With a special LoginModule
we could do the mapping from token identity to username inside the login
module and perhaps even do the token validation.
Then we could also add the SAML token to the JAAS Subject.
This would then allow to use the JAAS login for a chained service call
to another service. We could retrieve the SAML token there and use it to
get an onBehalfOf token from STS. So we would be able to do chained
service calls with full single sign on.
Another single sign on case would be to start with a local JAAS login
with kerberos. The jaas context from this login could then be used on
outgoing calls to authenticate against the STS using Spnego auth and
retrieve a SAML token.
Both cases together would then support a complete single sign on from
kerberos on the client (e.g. Windows Auth) to directly called service
endpoints (SAML Token) as well as chained calls from there (onBehalfOf
SAML token).
What do you think?
Christian
On 10.07.2014 11:55, Oliver Wulff wrote:
> Hi Christian
>
> I do support the ideas. I think it's important to include claims based authorization concept as well as supported by Fediz, but primarely for Web SSO.
>
> JAAS is a good concept to seperate the transport (HTTP) and the access to the identity store. But JAAS doesn't work for SSO approaches as supporting HTTP Basic Authorization Header is not sufficient for SAML based protocols (SAML-P, WS-Federation).
>
> WDYT?
>
> Thanks
> Oli
>
>
> ------
>
> Oliver Wulff
>
> Blog: http://owulff.blogspot.com
> Solution Architect
> http://coders.talend.com
>
> Talend Application Integration Division http://www.talend.com
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Ideas for standardizing CXF authentication and authorization
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Łukasz
On 10/07/14 12:38, Łukasz Dywicki wrote:
> Hey Christian,
> Great you brought this discussion. I already started working on
> integration between spring security (SS) and cxf, mainly because JAAS
> was not sufficient in all our cases and SS provides nice cover to it
> such AccessDecisionManager session controlling and so on. As Oliver
> pointed out - currently CXF is bound to HTTP headers or WSS4J
> callbacks requiring re-sending credentials for each invocation which
> really limit users while working on more advanced APIs. I would love
> to see support for login/logout operations and session handling within
> CXF.
>
> There are couple issues which can not be solved with current CXF code
> - for example AbstractAuthorizingInInterceptor forces presence of
> security context even if subject is not necessary and method is not
> annotated with any secure annotation or is annotated with @PermitAll.
We fixed it yesterday
Cheers, Sergey
>
> Best regards,
> Łukasz
> --
> luke@code-house.org
> Twitter: ldywicki
> Blog: http://dywicki.pl
> Code-House - http://code-house.org
>
>
> 2014-07-10 11:55 GMT+02:00 Oliver Wulff <ow...@talend.com>:
>> Hi Christian
>>
>> I do support the ideas. I think it's important to include claims based authorization concept as well as supported by Fediz, but primarely for Web SSO.
>>
>> JAAS is a good concept to seperate the transport (HTTP) and the access to the identity store. But JAAS doesn't work for SSO approaches as supporting HTTP Basic Authorization Header is not sufficient for SAML based protocols (SAML-P, WS-Federation).
>>
>> WDYT?
>>
>> Thanks
>> Oli
>>
>>
>> ------
>>
>> Oliver Wulff
>>
>> Blog: http://owulff.blogspot.com
>> Solution Architect
>> http://coders.talend.com
>>
>> Talend Application Integration Division http://www.talend.com
>>
>> ________________________________________
>> From: Christian Schneider [cschneider111@gmail.com] on behalf of Christian Schneider [chris@die-schneider.net]
>> Sent: 10 July 2014 10:55
>> To: CXF Dev List
>> Subject: Ideas for standardizing CXF authentication and authorization
>>
>> CXF already supports a wide range of authentication and authorization
>> methods. Each of these has to be configured differently though
>> and some are almost unknown by users.
>>
>> So I would like to improve that by standardizing on a common approach
>> that covers all existing variants but makes them accessible in the same way.
>>
>> The only real java standard for authentication is JAAS. It is built into
>> the jre and quite flexible. Security frameworks normally also integrate
>> well with JAAS.
>> So the idea is to standardize on JAAS for authentication.
>>
>> Authorization on the other hand has very diverse requirements and in
>> fact is not really directly coupled to CXF at all. After all the same
>> kind of authorization also has to happen in the UI and in the business code.
>> So the idea there is to solve authorization outside of CXF and base the
>> authorization on the JAAS login CXF provides.
>>
>> I have written down my ideas in detail on:
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42568988
>>
>> I would be very interested in your feedback on my ideas.
>>
>> Christian
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
Re: Ideas for standardizing CXF authentication and authorization
Posted by Łukasz Dywicki <lu...@code-house.org>.
Hey Christian,
I'll take a look, however my other code is bound to CXF 2.7.7 (and
TESB 5.4.x) so I can not rely on new features yet.
Cheers,
Łukasz
--
luke@code-house.org
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
2014-07-10 18:25 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
> The Subject.doAs problem is already solved (See issue below). You can
> already test it with the current trunk.
> Simply add a JAASAuthenticationFeature to your bus or service. This will add
> JAAS Authentication suitable for Apache Karaf.
>
> You can then login with karaf/karaf and inside your service impl use this to
> retreive the subject:
> |AccessControlContext acc = AccesController.getContext();|
> |Subject subject = Subject.getSubject(acc);|
>
> If you can make shiro or Spring Security create their security context from
> a JAAS one they should also work nicely.
> I experimented with both but am not a big fan. The problem with shiro is
> that it does not seem to provide nice authorization support.
> So for example they do not support @RolesAllowed and the like.
>
> Spring security on the other hand is not really suitable to combine with
> anything else than spring. For spring it is quite nice though.
>
> Establish Jaas login context using Subject.doAs
> https://issues.apache.org/jira/browse/CXF-5868
>
> Now we need some nice Authorization support of course. This I would like to
> implement outside of CXF
> as authorization is not only needed inside the service but also when calling
> other code.
>
> Christian
>
> Am 10.07.2014 15:33, schrieb Łukasz Dywicki:
>
>> Issue which I mentioned was fixed. Issue for it is CXF-5864. I also
>> opt for JAAS as underlying framework since there is no other standard.
>> I was looking for Shrio-JAAS integrations but except couple statements
>> there is no live example of it. With SS it's easier as it supports
>> JAAS out of the box and allows to reduce amount of code needed to call
>> JAAS login module. I'm not sure but in SS 2.x there was reverse bridge
>> allowing to call Spring Security authentication manager via JAAS,
>> sadly can not find it right now.
>> In some scenarios as you already pointed additional check is needed.
>> Kerberos verifies identity but does not offer any way to retrieve user
>> privileges. I can imagine situation that someone is using Kerberos
>> without directory services - for these cases SS requires
>> implementation of UserDetailsService.
>>
>> My plan was also to let service implementer retrieve Subject and it's
>> roles from current security context regardless if its JAX-RS or JAX-WS
>> code. Now CXF relies on JAX-RS in one place and I'm not aware of any
>> similarity for JAX-WS. With plain JAAS it will be possible, CXF just
>> needs to call Subject.doAs() in service invoker.
>>
>> Best regards,
>> Łukasz
>> --
>> luke@code-house.org
>> Twitter: ldywicki
>> Blog: http://dywicki.pl
>> Code-House - http://code-house.org
>>
>> 2014-07-10 14:06 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
>>>
>>> Spring security integration would be an interesting case that I hope can
>>> be
>>> covered with my approach.
>>>
>>> We could do the JAAS aauthentication with CXF without Spring Security and
>>> then use Spring security just for Authorization.
>>> The only thing we would need to do is provide a small module for Spring
>>> Security that retrieves the JAAS Login Context and creates a Spring
>>> Security
>>> context from it. Perhaps
>>> this is even present somewhere in spring security as this case should not
>>> be
>>> that uncommon. After that step Spring security would fully work.
>>>
>>> This of course only can work if the Authentication phase can be covered
>>> by
>>> JAAS. Which kind of authentication do you have in mind?
>>>
>>> Christian
>>>
>>>
>>>
>>>
>>> On 10.07.2014 13:38, Łukasz Dywicki wrote:
>>>>
>>>> Hey Christian,
>>>> Great you brought this discussion. I already started working on
>>>> integration between spring security (SS) and cxf, mainly because JAAS
>>>> was not sufficient in all our cases and SS provides nice cover to it
>>>> such AccessDecisionManager session controlling and so on. As Oliver
>>>> pointed out - currently CXF is bound to HTTP headers or WSS4J
>>>> callbacks requiring re-sending credentials for each invocation which
>>>> really limit users while working on more advanced APIs. I would love
>>>> to see support for login/logout operations and session handling within
>>>> CXF.
>>>>
>>>> There are couple issues which can not be solved with current CXF code
>>>> - for example AbstractAuthorizingInInterceptor forces presence of
>>>> security context even if subject is not necessary and method is not
>>>> annotated with any secure annotation or is annotated with @PermitAll.
>>>>
>>>> Best regards,
>>>> Łukasz
>>>> --
>>>> luke@code-house.org
>>>> Twitter: ldywicki
>>>> Blog: http://dywicki.pl
>>>> Code-House - http://code-house.org
>>>>
>>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
Re: Ideas for standardizing CXF authentication and authorization
Posted by Christian Schneider <ch...@die-schneider.net>.
The Subject.doAs problem is already solved (See issue below). You can
already test it with the current trunk.
Simply add a JAASAuthenticationFeature to your bus or service. This will
add JAAS Authentication suitable for Apache Karaf.
You can then login with karaf/karaf and inside your service impl use
this to retreive the subject:
|AccessControlContext acc = AccesController.getContext();|
|Subject subject = Subject.getSubject(acc);|
If you can make shiro or Spring Security create their security context
from a JAAS one they should also work nicely.
I experimented with both but am not a big fan. The problem with shiro is
that it does not seem to provide nice authorization support.
So for example they do not support @RolesAllowed and the like.
Spring security on the other hand is not really suitable to combine with
anything else than spring. For spring it is quite nice though.
Establish Jaas login context using Subject.doAs
https://issues.apache.org/jira/browse/CXF-5868
Now we need some nice Authorization support of course. This I would like
to implement outside of CXF
as authorization is not only needed inside the service but also when
calling other code.
Christian
Am 10.07.2014 15:33, schrieb Łukasz Dywicki:
> Issue which I mentioned was fixed. Issue for it is CXF-5864. I also
> opt for JAAS as underlying framework since there is no other standard.
> I was looking for Shrio-JAAS integrations but except couple statements
> there is no live example of it. With SS it's easier as it supports
> JAAS out of the box and allows to reduce amount of code needed to call
> JAAS login module. I'm not sure but in SS 2.x there was reverse bridge
> allowing to call Spring Security authentication manager via JAAS,
> sadly can not find it right now.
> In some scenarios as you already pointed additional check is needed.
> Kerberos verifies identity but does not offer any way to retrieve user
> privileges. I can imagine situation that someone is using Kerberos
> without directory services - for these cases SS requires
> implementation of UserDetailsService.
>
> My plan was also to let service implementer retrieve Subject and it's
> roles from current security context regardless if its JAX-RS or JAX-WS
> code. Now CXF relies on JAX-RS in one place and I'm not aware of any
> similarity for JAX-WS. With plain JAAS it will be possible, CXF just
> needs to call Subject.doAs() in service invoker.
>
> Best regards,
> Łukasz
> --
> luke@code-house.org
> Twitter: ldywicki
> Blog: http://dywicki.pl
> Code-House - http://code-house.org
>
> 2014-07-10 14:06 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
>> Spring security integration would be an interesting case that I hope can be
>> covered with my approach.
>>
>> We could do the JAAS aauthentication with CXF without Spring Security and
>> then use Spring security just for Authorization.
>> The only thing we would need to do is provide a small module for Spring
>> Security that retrieves the JAAS Login Context and creates a Spring Security
>> context from it. Perhaps
>> this is even present somewhere in spring security as this case should not be
>> that uncommon. After that step Spring security would fully work.
>>
>> This of course only can work if the Authentication phase can be covered by
>> JAAS. Which kind of authentication do you have in mind?
>>
>> Christian
>>
>>
>>
>>
>> On 10.07.2014 13:38, Łukasz Dywicki wrote:
>>> Hey Christian,
>>> Great you brought this discussion. I already started working on
>>> integration between spring security (SS) and cxf, mainly because JAAS
>>> was not sufficient in all our cases and SS provides nice cover to it
>>> such AccessDecisionManager session controlling and so on. As Oliver
>>> pointed out - currently CXF is bound to HTTP headers or WSS4J
>>> callbacks requiring re-sending credentials for each invocation which
>>> really limit users while working on more advanced APIs. I would love
>>> to see support for login/logout operations and session handling within
>>> CXF.
>>>
>>> There are couple issues which can not be solved with current CXF code
>>> - for example AbstractAuthorizingInInterceptor forces presence of
>>> security context even if subject is not necessary and method is not
>>> annotated with any secure annotation or is annotated with @PermitAll.
>>>
>>> Best regards,
>>> Łukasz
>>> --
>>> luke@code-house.org
>>> Twitter: ldywicki
>>> Blog: http://dywicki.pl
>>> Code-House - http://code-house.org
>>>
>>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Ideas for standardizing CXF authentication and authorization
Posted by Łukasz Dywicki <lu...@code-house.org>.
Issue which I mentioned was fixed. Issue for it is CXF-5864. I also
opt for JAAS as underlying framework since there is no other standard.
I was looking for Shrio-JAAS integrations but except couple statements
there is no live example of it. With SS it's easier as it supports
JAAS out of the box and allows to reduce amount of code needed to call
JAAS login module. I'm not sure but in SS 2.x there was reverse bridge
allowing to call Spring Security authentication manager via JAAS,
sadly can not find it right now.
In some scenarios as you already pointed additional check is needed.
Kerberos verifies identity but does not offer any way to retrieve user
privileges. I can imagine situation that someone is using Kerberos
without directory services - for these cases SS requires
implementation of UserDetailsService.
My plan was also to let service implementer retrieve Subject and it's
roles from current security context regardless if its JAX-RS or JAX-WS
code. Now CXF relies on JAX-RS in one place and I'm not aware of any
similarity for JAX-WS. With plain JAAS it will be possible, CXF just
needs to call Subject.doAs() in service invoker.
Best regards,
Łukasz
--
luke@code-house.org
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
2014-07-10 14:06 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
> Spring security integration would be an interesting case that I hope can be
> covered with my approach.
>
> We could do the JAAS aauthentication with CXF without Spring Security and
> then use Spring security just for Authorization.
> The only thing we would need to do is provide a small module for Spring
> Security that retrieves the JAAS Login Context and creates a Spring Security
> context from it. Perhaps
> this is even present somewhere in spring security as this case should not be
> that uncommon. After that step Spring security would fully work.
>
> This of course only can work if the Authentication phase can be covered by
> JAAS. Which kind of authentication do you have in mind?
>
> Christian
>
>
>
>
> On 10.07.2014 13:38, Łukasz Dywicki wrote:
>>
>> Hey Christian,
>> Great you brought this discussion. I already started working on
>> integration between spring security (SS) and cxf, mainly because JAAS
>> was not sufficient in all our cases and SS provides nice cover to it
>> such AccessDecisionManager session controlling and so on. As Oliver
>> pointed out - currently CXF is bound to HTTP headers or WSS4J
>> callbacks requiring re-sending credentials for each invocation which
>> really limit users while working on more advanced APIs. I would love
>> to see support for login/logout operations and session handling within
>> CXF.
>>
>> There are couple issues which can not be solved with current CXF code
>> - for example AbstractAuthorizingInInterceptor forces presence of
>> security context even if subject is not necessary and method is not
>> annotated with any secure annotation or is annotated with @PermitAll.
>>
>> Best regards,
>> Łukasz
>> --
>> luke@code-house.org
>> Twitter: ldywicki
>> Blog: http://dywicki.pl
>> Code-House - http://code-house.org
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
Re: Ideas for standardizing CXF authentication and authorization
Posted by Christian Schneider <ch...@die-schneider.net>.
Spring security integration would be an interesting case that I hope can
be covered with my approach.
We could do the JAAS aauthentication with CXF without Spring Security
and then use Spring security just for Authorization.
The only thing we would need to do is provide a small module for Spring
Security that retrieves the JAAS Login Context and creates a Spring
Security context from it. Perhaps
this is even present somewhere in spring security as this case should
not be that uncommon. After that step Spring security would fully work.
This of course only can work if the Authentication phase can be covered
by JAAS. Which kind of authentication do you have in mind?
Christian
On 10.07.2014 13:38, Łukasz Dywicki wrote:
> Hey Christian,
> Great you brought this discussion. I already started working on
> integration between spring security (SS) and cxf, mainly because JAAS
> was not sufficient in all our cases and SS provides nice cover to it
> such AccessDecisionManager session controlling and so on. As Oliver
> pointed out - currently CXF is bound to HTTP headers or WSS4J
> callbacks requiring re-sending credentials for each invocation which
> really limit users while working on more advanced APIs. I would love
> to see support for login/logout operations and session handling within
> CXF.
>
> There are couple issues which can not be solved with current CXF code
> - for example AbstractAuthorizingInInterceptor forces presence of
> security context even if subject is not necessary and method is not
> annotated with any secure annotation or is annotated with @PermitAll.
>
> Best regards,
> Łukasz
> --
> luke@code-house.org
> Twitter: ldywicki
> Blog: http://dywicki.pl
> Code-House - http://code-house.org
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Ideas for standardizing CXF authentication and authorization
Posted by Łukasz Dywicki <lu...@code-house.org>.
Hey Christian,
Great you brought this discussion. I already started working on
integration between spring security (SS) and cxf, mainly because JAAS
was not sufficient in all our cases and SS provides nice cover to it
such AccessDecisionManager session controlling and so on. As Oliver
pointed out - currently CXF is bound to HTTP headers or WSS4J
callbacks requiring re-sending credentials for each invocation which
really limit users while working on more advanced APIs. I would love
to see support for login/logout operations and session handling within
CXF.
There are couple issues which can not be solved with current CXF code
- for example AbstractAuthorizingInInterceptor forces presence of
security context even if subject is not necessary and method is not
annotated with any secure annotation or is annotated with @PermitAll.
Best regards,
Łukasz
--
luke@code-house.org
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
2014-07-10 11:55 GMT+02:00 Oliver Wulff <ow...@talend.com>:
> Hi Christian
>
> I do support the ideas. I think it's important to include claims based authorization concept as well as supported by Fediz, but primarely for Web SSO.
>
> JAAS is a good concept to seperate the transport (HTTP) and the access to the identity store. But JAAS doesn't work for SSO approaches as supporting HTTP Basic Authorization Header is not sufficient for SAML based protocols (SAML-P, WS-Federation).
>
> WDYT?
>
> Thanks
> Oli
>
>
> ------
>
> Oliver Wulff
>
> Blog: http://owulff.blogspot.com
> Solution Architect
> http://coders.talend.com
>
> Talend Application Integration Division http://www.talend.com
>
> ________________________________________
> From: Christian Schneider [cschneider111@gmail.com] on behalf of Christian Schneider [chris@die-schneider.net]
> Sent: 10 July 2014 10:55
> To: CXF Dev List
> Subject: Ideas for standardizing CXF authentication and authorization
>
> CXF already supports a wide range of authentication and authorization
> methods. Each of these has to be configured differently though
> and some are almost unknown by users.
>
> So I would like to improve that by standardizing on a common approach
> that covers all existing variants but makes them accessible in the same way.
>
> The only real java standard for authentication is JAAS. It is built into
> the jre and quite flexible. Security frameworks normally also integrate
> well with JAAS.
> So the idea is to standardize on JAAS for authentication.
>
> Authorization on the other hand has very diverse requirements and in
> fact is not really directly coupled to CXF at all. After all the same
> kind of authorization also has to happen in the UI and in the business code.
> So the idea there is to solve authorization outside of CXF and base the
> authorization on the JAAS login CXF provides.
>
> I have written down my ideas in detail on:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42568988
>
> I would be very interested in your feedback on my ideas.
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
RE: Ideas for standardizing CXF authentication and authorization
Posted by Oliver Wulff <ow...@talend.com>.
Hi Christian
I do support the ideas. I think it's important to include claims based authorization concept as well as supported by Fediz, but primarely for Web SSO.
JAAS is a good concept to seperate the transport (HTTP) and the access to the identity store. But JAAS doesn't work for SSO approaches as supporting HTTP Basic Authorization Header is not sufficient for SAML based protocols (SAML-P, WS-Federation).
WDYT?
Thanks
Oli
------
Oliver Wulff
Blog: http://owulff.blogspot.com
Solution Architect
http://coders.talend.com
Talend Application Integration Division http://www.talend.com
________________________________________
From: Christian Schneider [cschneider111@gmail.com] on behalf of Christian Schneider [chris@die-schneider.net]
Sent: 10 July 2014 10:55
To: CXF Dev List
Subject: Ideas for standardizing CXF authentication and authorization
CXF already supports a wide range of authentication and authorization
methods. Each of these has to be configured differently though
and some are almost unknown by users.
So I would like to improve that by standardizing on a common approach
that covers all existing variants but makes them accessible in the same way.
The only real java standard for authentication is JAAS. It is built into
the jre and quite flexible. Security frameworks normally also integrate
well with JAAS.
So the idea is to standardize on JAAS for authentication.
Authorization on the other hand has very diverse requirements and in
fact is not really directly coupled to CXF at all. After all the same
kind of authorization also has to happen in the UI and in the business code.
So the idea there is to solve authorization outside of CXF and base the
authorization on the JAAS login CXF provides.
I have written down my ideas in detail on:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42568988
I would be very interested in your feedback on my ideas.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Ideas for standardizing CXF authentication and authorization
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Chris
On 14/07/14 02:01, Chris Geer wrote:
> Christian,
>
> I'm not sure I have specific advice about how to approach Shiro
> compatibility without spending some cycles on it. I think we could engage
> Les and Shiro community to help though. One possible approach might just be
> to have CXF use a pluggable approach so that it calls out to an API when it
> checks if a user is authentication/authorized. That way a JAAS
> implementation could be put in place but a Shiro or Spring Security
> implementation could also be put in place. This would have to be made OSGI
> friendly, but I bet it could be done.
>
> I guess I just wanted to toss that out there so that any decisions that
> were made wouldn't preclude using frameworks other than JAAS. In my
> experience, using JAAS in an OSGI environments, with cross-service calls,
> is very problematic so I'd just hate to see CXF require usage of JAAS.
AFAIK depending on JAAS will be completely optional.
Cheers, Sergey
> One
> could argue that CXF didn't need to provide A&A at all in the core and
> external libraries can be used through filters/interceptors as the
> standard.
>
> I'll give it some more thought as this conversation continues.
>
> Chris
>
>
> On Sun, Jul 13, 2014 at 10:56 AM, Christian Schneider <
> chris@die-schneider.net> wrote:
>
>> I think it would be great to stay compatible to the external security
>> frameworks.
>>
>> What do you think needs to be considered regarding shiro?
>>
>> Christian
>>
>>
>> Am 13.07.2014 17:50, schrieb Chris Geer:
>>
>> While authentication/authorization is being discussed it would also be
>>> good
>>> if compatibility with Apache Shiro was kept in mind.
>>>
>>>
>>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
>
Re: Ideas for standardizing CXF authentication and authorization
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Chris,
The problem with the plugable aproach is that we would have to create a
new API that then CXF and at least the Shiro "bridge" module would
depend on.
From another point of view JAAS can even be seen as the basis for the
plugable approach. The JAAS API is the common API and we can have
different authentication modules in CXF that simply need to result in an
established JASS context in the end. The big advantage of JAAS compared
to another API ist that it is built into the JRE so everyone already has
the API.
So I would prefer that we try to attach Shiro to JAAS too. This is
indeed something we could discuss on the shiro list.
I see three general scenarios where shiro is involved:
1. Do all authentication and auhorization with shiro. (e.g. Shiro filter
for Authentication and Shiro calls in business logic for Authorization).
Here it is all shiro. We probably need no special integration
2. Do authentication in shiro and authorization in CXF.
In this case it would be ideal if shiro could simply establish a JAAS
context in addition to its own security context. This alone should then
fully work for CXF as soon as we rely on JAAS in CXF. Till then
we could use a small CXF module to establish a CXF SecurityContext from
an existing JAAS context.
3. Do authentication in CXF using JAAS and authorization in shiro.
There we would need the bridge in the other direction. Shiro would need
a small adapter that creates a Shiro Security context from an existing
JAAS context
Regarding OSGi I see no real problems with JAAS. I tested The
JAASAuthenticationFeature together with my new blueprint authorization
module and the karaf role based access system (for OSGi services) and it
works well. Cross service calls should be no issue as they use the same
thread in OSGi. So the JAAS context is untouched and simply works. In
fact JAAS is the standard authentication / authorization model for OSGi.
For example the whole OSGi security framework with things like
BundlePermission relies on JAAS.
Christian
On 14.07.2014 03:01, Chris Geer wrote:
> Christian,
>
> I'm not sure I have specific advice about how to approach Shiro
> compatibility without spending some cycles on it. I think we could engage
> Les and Shiro community to help though. One possible approach might just be
> to have CXF use a pluggable approach so that it calls out to an API when it
> checks if a user is authentication/authorized. That way a JAAS
> implementation could be put in place but a Shiro or Spring Security
> implementation could also be put in place. This would have to be made OSGI
> friendly, but I bet it could be done.
>
> I guess I just wanted to toss that out there so that any decisions that
> were made wouldn't preclude using frameworks other than JAAS. In my
> experience, using JAAS in an OSGI environments, with cross-service calls,
> is very problematic so I'd just hate to see CXF require usage of JAAS. One
> could argue that CXF didn't need to provide A&A at all in the core and
> external libraries can be used through filters/interceptors as the
> standard.
>
> I'll give it some more thought as this conversation continues.
>
> Chris
>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Ideas for standardizing CXF authentication and authorization
Posted by Chris Geer <ch...@cxtsoftware.com>.
Christian,
I'm not sure I have specific advice about how to approach Shiro
compatibility without spending some cycles on it. I think we could engage
Les and Shiro community to help though. One possible approach might just be
to have CXF use a pluggable approach so that it calls out to an API when it
checks if a user is authentication/authorized. That way a JAAS
implementation could be put in place but a Shiro or Spring Security
implementation could also be put in place. This would have to be made OSGI
friendly, but I bet it could be done.
I guess I just wanted to toss that out there so that any decisions that
were made wouldn't preclude using frameworks other than JAAS. In my
experience, using JAAS in an OSGI environments, with cross-service calls,
is very problematic so I'd just hate to see CXF require usage of JAAS. One
could argue that CXF didn't need to provide A&A at all in the core and
external libraries can be used through filters/interceptors as the
standard.
I'll give it some more thought as this conversation continues.
Chris
On Sun, Jul 13, 2014 at 10:56 AM, Christian Schneider <
chris@die-schneider.net> wrote:
> I think it would be great to stay compatible to the external security
> frameworks.
>
> What do you think needs to be considered regarding shiro?
>
> Christian
>
>
> Am 13.07.2014 17:50, schrieb Chris Geer:
>
> While authentication/authorization is being discussed it would also be
>> good
>> if compatibility with Apache Shiro was kept in mind.
>>
>>
>>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
Re: Ideas for standardizing CXF authentication and authorization
Posted by Christian Schneider <ch...@die-schneider.net>.
I think it would be great to stay compatible to the external security
frameworks.
What do you think needs to be considered regarding shiro?
Christian
Am 13.07.2014 17:50, schrieb Chris Geer:
> While authentication/authorization is being discussed it would also be good
> if compatibility with Apache Shiro was kept in mind.
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Ideas for standardizing CXF authentication and authorization
Posted by Chris Geer <ch...@cxtsoftware.com>.
While authentication/authorization is being discussed it would also be good
if compatibility with Apache Shiro was kept in mind.
On Sunday, July 13, 2014, Andrei Shakirin <as...@talend.com> wrote:
> Hi Christian,
>
> I find your ideas great, IMO it will be the step in the right direction.
> The JAAS helps to cleanly decouple authentication/authorization logic from
> business code.
>
> Some thoughts regarding that:
> 1. Authentication
> Authentication scenarios can be collected in two large groups:
> a) Service receives client credentials with request and it is
> responsibility either of custom code or container to authenticate the user.
> For example: usernameToken, basic and digest authentication, SSL
> with client authentication, etc.
> b) Client firstly communicates with some security server validating
> client credentials and issuing security token. Client injects this token
> into the request. Service validates the token (by sending request to
> security server or itself). Samples are SAML token authentication, OAuth,
> Kerberos.
>
> Group (a) fits very good to JAAS concept, it is necessary: extract
> credentials from appropriate source (UT, AuthroizationPolicy, etc)
> depending on authentication mode, create CallbackHandler and invoke login
> context. Configured JAAS Login Modules will be used to authenticate user,
> create Subject and Principles. Most of this is already implemented in
> JAASLoginInterceptor.
>
> Group (b) is a bit tricky, because user is authenticated by security
> server and service should just validate the token. In this case JAAS Login
> Module can either take over token validation and fill Subject Principles
> based on token attributes (like Kerberos does) or skip validation step (if
> it is already done by CXF interceptors) and create Subject with Principles.
>
> 2. Authorization
> IMO the task fit good for JAAS is mapping user to role and creating Role
> Principles. Other authorization steps is either technology or container
> specific: using security annotations, container configuration, role-method
> maps, etc.
>
> By the way, JEE 6 introduced some extensions for JAAS in Java
> Specification Request 196 (
> http://docs.oracle.com/cd/E19575-01/820-3740/ghcwf/index.html). It is
> more message processing oriented, introduces agents for validating security
> tokens or signatures and determines a standard way to obtain user
> principals and group principals. The JSR is primarily designed for JEE
> application servers, but perhaps it makes sense to look in and use some
> ideas/API from that.
>
> Regards,
> Andrei.
>
> > -----Original Message-----
> > From: Christian Schneider [mailto:cschneider111@gmail.com <javascript:;>]
> On Behalf Of
> > Christian Schneider
> > Sent: Donnerstag, 10. Juli 2014 10:56
> > To: CXF Dev List
> > Subject: Ideas for standardizing CXF authentication and authorization
> >
> > CXF already supports a wide range of authentication and authorization
> > methods. Each of these has to be configured differently though and some
> are
> > almost unknown by users.
> >
> > So I would like to improve that by standardizing on a common approach
> that
> > covers all existing variants but makes them accessible in the same way.
> >
> > The only real java standard for authentication is JAAS. It is built into
> the jre and
> > quite flexible. Security frameworks normally also integrate well with
> JAAS.
> > So the idea is to standardize on JAAS for authentication.
> >
> > Authorization on the other hand has very diverse requirements and in
> fact is
> > not really directly coupled to CXF at all. After all the same kind of
> authorization
> > also has to happen in the UI and in the business code.
> > So the idea there is to solve authorization outside of CXF and base the
> > authorization on the JAAS login CXF provides.
> >
> > I have written down my ideas in detail on:
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42568988
> >
> > I would be very interested in your feedback on my ideas.
> >
> > Christian
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
>
>
Re: Ideas for standardizing CXF authentication and authorization
Posted by Christian Schneider <ch...@die-schneider.net>.
I fully agree.
The simplest bridge would be to solve key based authentication schemes
outside JAAS and then simply create a JAAS context without doing further
authentication. This especially works well with how ws security is
designed right now.
A better though more complicated way is like you described to let a JAAS
module do the authentication of the token or certificate. This approach
would allow the user more flexibility by adding custom checks to the
JAAS config.
Perhaps a way to achieve this is to simply add JAAS support directly to
WS Security. So from cxf side we would simply configure ws security and
after it has done its processing we have a fully populated JAAS context.
Support for container based authentication is quite similar to ws
security in that regard. The simplest bridge is to let the container do
the authentication and on CXF side just create a JAAS security context
by populating the prinicples. The more advanced case would be to let the
container establish the full JAAS context.
So in both cases we should work with the respective communities to
ideally let them do all the JAAS authentication for us.
Christian
On 13.07.2014 16:21, Andrei Shakirin wrote:
> Hi Christian,
>
> I find your ideas great, IMO it will be the step in the right direction. The JAAS helps to cleanly decouple authentication/authorization logic from business code.
>
> Some thoughts regarding that:
> 1. Authentication
> Authentication scenarios can be collected in two large groups:
> a) Service receives client credentials with request and it is responsibility either of custom code or container to authenticate the user.
> For example: usernameToken, basic and digest authentication, SSL with client authentication, etc.
> b) Client firstly communicates with some security server validating client credentials and issuing security token. Client injects this token into the request. Service validates the token (by sending request to security server or itself). Samples are SAML token authentication, OAuth, Kerberos.
>
> Group (a) fits very good to JAAS concept, it is necessary: extract credentials from appropriate source (UT, AuthroizationPolicy, etc) depending on authentication mode, create CallbackHandler and invoke login context. Configured JAAS Login Modules will be used to authenticate user, create Subject and Principles. Most of this is already implemented in JAASLoginInterceptor.
>
> Group (b) is a bit tricky, because user is authenticated by security server and service should just validate the token. In this case JAAS Login Module can either take over token validation and fill Subject Principles based on token attributes (like Kerberos does) or skip validation step (if it is already done by CXF interceptors) and create Subject with Principles.
>
> 2. Authorization
> IMO the task fit good for JAAS is mapping user to role and creating Role Principles. Other authorization steps is either technology or container specific: using security annotations, container configuration, role-method maps, etc.
>
> By the way, JEE 6 introduced some extensions for JAAS in Java Specification Request 196 (http://docs.oracle.com/cd/E19575-01/820-3740/ghcwf/index.html). It is more message processing oriented, introduces agents for validating security tokens or signatures and determines a standard way to obtain user principals and group principals. The JSR is primarily designed for JEE application servers, but perhaps it makes sense to look in and use some ideas/API from that.
>
> Regards,
> Andrei.
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
RE: Ideas for standardizing CXF authentication and authorization
Posted by Andrei Shakirin <as...@talend.com>.
Hi Christian,
I find your ideas great, IMO it will be the step in the right direction. The JAAS helps to cleanly decouple authentication/authorization logic from business code.
Some thoughts regarding that:
1. Authentication
Authentication scenarios can be collected in two large groups:
a) Service receives client credentials with request and it is responsibility either of custom code or container to authenticate the user.
For example: usernameToken, basic and digest authentication, SSL with client authentication, etc.
b) Client firstly communicates with some security server validating client credentials and issuing security token. Client injects this token into the request. Service validates the token (by sending request to security server or itself). Samples are SAML token authentication, OAuth, Kerberos.
Group (a) fits very good to JAAS concept, it is necessary: extract credentials from appropriate source (UT, AuthroizationPolicy, etc) depending on authentication mode, create CallbackHandler and invoke login context. Configured JAAS Login Modules will be used to authenticate user, create Subject and Principles. Most of this is already implemented in JAASLoginInterceptor.
Group (b) is a bit tricky, because user is authenticated by security server and service should just validate the token. In this case JAAS Login Module can either take over token validation and fill Subject Principles based on token attributes (like Kerberos does) or skip validation step (if it is already done by CXF interceptors) and create Subject with Principles.
2. Authorization
IMO the task fit good for JAAS is mapping user to role and creating Role Principles. Other authorization steps is either technology or container specific: using security annotations, container configuration, role-method maps, etc.
By the way, JEE 6 introduced some extensions for JAAS in Java Specification Request 196 (http://docs.oracle.com/cd/E19575-01/820-3740/ghcwf/index.html). It is more message processing oriented, introduces agents for validating security tokens or signatures and determines a standard way to obtain user principals and group principals. The JSR is primarily designed for JEE application servers, but perhaps it makes sense to look in and use some ideas/API from that.
Regards,
Andrei.
> -----Original Message-----
> From: Christian Schneider [mailto:cschneider111@gmail.com] On Behalf Of
> Christian Schneider
> Sent: Donnerstag, 10. Juli 2014 10:56
> To: CXF Dev List
> Subject: Ideas for standardizing CXF authentication and authorization
>
> CXF already supports a wide range of authentication and authorization
> methods. Each of these has to be configured differently though and some are
> almost unknown by users.
>
> So I would like to improve that by standardizing on a common approach that
> covers all existing variants but makes them accessible in the same way.
>
> The only real java standard for authentication is JAAS. It is built into the jre and
> quite flexible. Security frameworks normally also integrate well with JAAS.
> So the idea is to standardize on JAAS for authentication.
>
> Authorization on the other hand has very diverse requirements and in fact is
> not really directly coupled to CXF at all. After all the same kind of authorization
> also has to happen in the UI and in the business code.
> So the idea there is to solve authorization outside of CXF and base the
> authorization on the JAAS login CXF provides.
>
> I have written down my ideas in detail on:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42568988
>
> I would be very interested in your feedback on my ideas.
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com