cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Soldano <asold...@redhat.com>
Subject Re: AbstractUsernameTokenAuthenticatingInterceptor.createSubject principal ordering
Date Mon, 20 May 2013 09:24:29 GMT
Hi Freeman,
thanks for the feedback;

On 05/20/2013 10:43 AM, Freeman Fang wrote:
> FYI, we have  org.apache.cxf.interceptor.security.DefaultSecurityContext which also rely
on this logic, please see the comment below
> /**
>  * SecurityContext which implements isUserInRole using the
>  * following approach : skip the first Subject principal, and then checks
>  * Groups the principal is a member of
>  * 

yep, while if you look at the findPrincipal method in there it does
exactly the same I proposed with skipping Group instance to get the user
principal.


> And when deploy cxf endpoint in some container, though by default CXF will assume that
role Principals are represented by javax.security.acl.Group instances, in some containers
objects representing a user principal and role principal are implementing the same marker
interface such as Principal, Karaf is in this case.
> 
> To works with this scenario, in CXF we can configure 
> <property name="roleClassifier" value="RolePrincipal"/>
>    <property name="roleClassifierType" value="classname"/>
>  for org.apache.cxf.interceptor.security.JAASLoginInterceptor, please take a look at
[1] to get more details.
> 
> [1]http://cxf.apache.org/docs/security.html

I previously missed this, thanks.
So basically what would you propose for the
AbstractUsernameTokenAuthenticationInterceptor? Perhaps to extract the
user principal check to a separated protected method that could be
overridden differently according the containers need?


Thanks
Alessio

-- 
Alessio Soldano
Web Service Lead, JBoss

Mime
View raw message