Extended SecurityContext interface

[Sergey Beryozkin <sb...@gmail.com>]

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

Re: Extended SecurityContext interface

[Sergey Beryozkin <sb...@gmail.com>]

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 <sb...@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
>