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
