You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Alessio Soldano <as...@redhat.com> on 2013/05/20 10:10:12 UTC
AbstractUsernameTokenAuthenticatingInterceptor.createSubject principal
ordering
Hi,
the AbstractUsernameTokenAuthenticatingInterceptor comes with the
following abstract method:
/**
* Create a Subject representing a current user and its roles.
* This Subject is expected to contain at least one Principal
representing a user
* and optionally followed by one or more principal Groups this user
is a member of.
* It will also be available in doCreateSecurityContext.
* @param name username
* @param password password
* @param isDigest true if a password digest is used
* @param nonce optional nonce
* @param created optional timestamp
* @return subject
* @throws SecurityException
*/
protected abstract Subject createSubject(String name,
String password,
boolean isDigest,
String nonce,
String created) throws
SecurityException;
the javadoc implies that the ordering of principals in the returned
subject is relevant and as a matter of fact there's a check in
'setSubject' method relying on that (that is on the assumption that the
user principal is the first one).
Would it make sense here / not break anything to relax the ordering
requirement a bit (to skip group principals that might be before the
actual principal) and change the check for example as in
http://pastebin.com/0T9mVbj3 ? This might grant some flexibility to
implementors of that abstract method.
Thanks
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
Re: AbstractUsernameTokenAuthenticatingInterceptor.createSubject
principal ordering
Posted by Alessio Soldano <as...@redhat.com>.
Hi,
On 05/20/2013 12:45 PM, Freeman Fang wrote:
> I thought your original problem comes from that you can't tell the difference between UserPrincipal and RolePrincipal in some containers(as I encounter similar issue in Karaf), no? If so, the configuration way used in org.apache.cxf.interceptor.security.JAASLoginInterceptor could be borrowed here.
Well, my problem is actually that I have a user reporting that the
implementor of createSubject might not care about ordering of principals
in subject and put a group principal first. Anyway, talking with Sergey
and Colm on IRC basically revealed that the
AbstractUsernameTokenAuthenticatingInterceptor is to be considered as
deprecated, so I've patched this locally in JBossWS by creating a custom
interceptor directly extending WSS4JInterceptor for the specific
scenario here. Will later refactor the whole integration in JBossWS.
Cheers
Alessio
>
> And about your question, yes, we probably should do it as the RolePrincipal may not always implements Group interface in some cases.
>
> Thanks
> －－－－－－－－－－－－－
> Freeman(Yue) Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Web: http://fusesource.com | http://www.redhat.com/
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
> http://blog.sina.com.cn/u/1473905042
> weibo: @Freeman小屋
>
> www.camelone.org : The open source integration conference:
>
> On 2013-5-20, at 下午5:24, Alessio Soldano wrote:
>
>> 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
>
>
--
Alessio Soldano
Web Service Lead, JBoss
Re: AbstractUsernameTokenAuthenticatingInterceptor.createSubject principal ordering
Posted by Freeman Fang <fr...@gmail.com>.
Hi Alessio,
I thought your original problem comes from that you can't tell the difference between UserPrincipal and RolePrincipal in some containers(as I encounter similar issue in Karaf), no? If so, the configuration way used in org.apache.cxf.interceptor.security.JAASLoginInterceptor could be borrowed here.
And about your question, yes, we probably should do it as the RolePrincipal may not always implements Group interface in some cases.
Thanks
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: @Freeman小屋
www.camelone.org : The open source integration conference:
On 2013-5-20, at 下午5:24, Alessio Soldano wrote:
> 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
Re: AbstractUsernameTokenAuthenticatingInterceptor.createSubject
principal ordering
Posted by Alessio Soldano <as...@redhat.com>.
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
Re: AbstractUsernameTokenAuthenticatingInterceptor.createSubject principal ordering
Posted by Freeman Fang <fr...@gmail.com>.
Hi Alessio,
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
*
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
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: @Freeman小屋
www.camelone.org : The open source integration conference:
On 2013-5-20, at 下午4:10, Alessio Soldano wrote:
> Hi,
> the AbstractUsernameTokenAuthenticatingInterceptor comes with the
> following abstract method:
>
> /**
> * Create a Subject representing a current user and its roles.
> * This Subject is expected to contain at least one Principal
> representing a user
> * and optionally followed by one or more principal Groups this user
> is a member of.
> * It will also be available in doCreateSecurityContext.
> * @param name username
> * @param password password
> * @param isDigest true if a password digest is used
> * @param nonce optional nonce
> * @param created optional timestamp
> * @return subject
> * @throws SecurityException
> */
> protected abstract Subject createSubject(String name,
> String password,
> boolean isDigest,
> String nonce,
> String created) throws
> SecurityException;
>
>
> the javadoc implies that the ordering of principals in the returned
> subject is relevant and as a matter of fact there's a check in
> 'setSubject' method relying on that (that is on the assumption that the
> user principal is the first one).
> Would it make sense here / not break anything to relax the ordering
> requirement a bit (to skip group principals that might be before the
> actual principal) and change the check for example as in
> http://pastebin.com/0T9mVbj3 ? This might grant some flexibility to
> implementors of that abstract method.
>
> Thanks
> Alessio
>
>
> --
> Alessio Soldano
> Web Service Lead, JBoss