I'd like to go ahead and merge it to 2.3.3. There's still some concern to do with the roles being represented as Principals. For now I'd prefer to continue representing them as Principals. Other security frameworks may represent roles differently but we have them as Principals given that at the CXF level Java Security Subject is what is supported by various security interceptors simply because it's kind of the lowest common denominator.
Strings would be the most commonly understood denominators :-) but I'm worried we'll lose the structure of Groups representing complex roles, if we flatten Groups to the list of strings...Returning Principals will let Group-aware consumers properly treat them. It may be tricky sometimes to totally agree on a particular design issue :-) but I feel this interface is not too bad and we can definitely change this particular interface during the next few iterations :-) as we move along. thanks, Sergey On Thu, Feb 10, 2011 at 11:20 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: > 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 >
