cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Ideas for standardizing CXF authentication and authorization
Date Thu, 10 Jul 2014 16:25:42 GMT
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

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.


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
> --
> Twitter: ldywicki
> Blog:
> Code-House -
> 2014-07-10 14:06 GMT+02:00 Christian Schneider <>:
>> 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
>>> --
>>> Twitter: ldywicki
>>> Blog:
>>> Code-House -
>> --
>> Christian Schneider
>> Open Source Architect

Christian Schneider

Open Source Architect
Talend Application Integration Division

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message