cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Extended SecurityContext interface
Date Thu, 10 Feb 2011 11:20:55 GMT
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

Mime
View raw message