Hi After the brief discussion with Christian about propagating the actual roles from the authenticated subject/principal I opened CXF-3322 [1] and added a LoginSecurityContext interface [2] which extends CXF SecurityContext [3].
The main idea is to create a bridge between different security contexts. For example, the Spring Security can be used to authenticate and authorize. A slightly different approach is to ask the CXF JAASLoginInterceptor to help with the container-managed authentication and then delegate to Spring Security to do the authorization. In this latter case JAASLoginInterceptor will create a CXF SecurityContext instance but it has no way of retrieving the list of roles needed for creating a SpringSecurity context. Thus LoginSecurityContext was 'born', it lets query the list actual roles and get to the underlying Subject which in turn may provide more informations and actions needed for doing some advanced security tasks. Christian, thanks for the comments at [1]. - I did consider returning a List<String> in response to getUserRoles(), in fact, one of the SecurityContext impls that CXF ships, RoleBasedSecurityContextImpl, had a cached List<String>. I chose to return List<Principal> because AFAIK in the Java Security space roles are always represented as Principals (or Groups) and thus it is also likely that we will have a case to deal with when a List<Principal>s will be expected further down the chain. Performance-wise, one won't lose anything too, by iterating over List<Principal> and converting it into a List<String> because SecurityContextImpls will have to do exactly that in order to produce a List<String> in the first place. - Retuning a Subject is not something that *JAAS*SecurityContext can only do. All the AbstractSecurityContextInterceptors doing the custom authentication are also providing the Subjects, example, the AbstractUsernameTokenInterceptor picks up a WSS4J-to-CXF UsernameToken and creates a Subject and wraps it in the SecurityContext. I came to the 'LoginSecurityContext' after few iterations :-) and it has been 'inspired' by the JAAS 'LoginContext' name but IMHO I'd keep the LoginSecurityContext as is, it's not necessarily JAAS-driven. - IMHO it would be better to avoid changing existing SecurityContext. It's possible of course, given that it's usually used internally, but I recall advising some users to wrap it for their own custom SecurityContext implementations. I don't really want to be pedantic here :-), but the CXF SecurityContext is the classical basic SecurityContext and many users do not really need to work with the methods LoginSecurityContext introduces. We'd need to add no-ops in quite a few places in the CXF code base too. I really think the cost of checking SecurityContext and casting it to LoginSecurityContext is much less in those 10-20% cases where the more advanced info is needed. Thanks, Sergey [1] https://issues.apache.org/jira/browse/CXF-3322 [2] http://svn.apache.org/repos/asf/cxf/trunk/api/src/main/java/org/apache/cxf/security/LoginSecurityContext.java [3] http://svn.apache.org/repos/asf/cxf/trunk/api/src/main/java/org/apache/cxf/security/SecurityContext.java
