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
