cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <>
Subject Re: AbstractUsernameTokenAuthenticatingInterceptor.createSubject principal ordering
Date Mon, 20 May 2013 08:43:58 GMT
Hi Alessio,

FYI, we have 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 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, please take a look at [1] to
get more details.


Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat
Web: |
Twitter: freemanfang
weibo: @Freeman小屋 : 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
> ? This might grant some flexibility to
> implementors of that abstract method.
> Thanks
> Alessio
> -- 
> Alessio Soldano
> Web Service Lead, JBoss

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