cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Ideas for standardizing CXF authentication and authorization
Date Mon, 14 Jul 2014 07:48:12 GMT
I fully agree.

The simplest bridge would be to solve key based authentication schemes 
outside JAAS and then simply create a JAAS context without doing further 
authentication. This especially works well with how ws security is 
designed right now.

A better though more complicated way is like you described to let a JAAS 
module do the authentication of the token or certificate. This approach 
would allow the user more flexibility by adding custom checks to the 
JAAS config.
Perhaps a way to achieve this is to simply add JAAS support directly to 
WS Security. So from cxf side we would simply configure ws security and 
after it has done its processing we have a fully populated JAAS context.

Support for container based authentication is quite similar to ws 
security in that regard. The simplest bridge is to let the container do 
the authentication and on CXF side just create a JAAS security context 
by populating the prinicples. The more advanced case would be to let the 
container establish the full JAAS context.

So in both cases we should work with the respective communities to 
ideally let them do all the JAAS authentication for us.

Christian

On 13.07.2014 16:21, Andrei Shakirin wrote:
> Hi Christian,
>
> I find your ideas great, IMO it will be the step in the right direction. The JAAS helps
to cleanly decouple authentication/authorization logic from business code.
>
> Some thoughts regarding that:
> 1. Authentication
>      Authentication scenarios can be collected in two large groups:
>      a) Service receives client credentials with request and it is responsibility either
of custom code or container to authenticate the user.
>          For example: usernameToken, basic and digest authentication, SSL with client
authentication, etc.
>      b) Client firstly communicates with some security server validating client credentials
and issuing security token. Client injects this token into the request.  Service validates
the token (by sending request to security server or itself). Samples are SAML token authentication,
OAuth, Kerberos.
>
> Group (a) fits very good to JAAS concept, it is necessary: extract credentials from appropriate
source (UT, AuthroizationPolicy, etc) depending on authentication mode, create CallbackHandler
and invoke login context. Configured JAAS Login Modules will be used to authenticate user,
create Subject and Principles. Most of this is already implemented in JAASLoginInterceptor.
>
> Group (b) is a bit tricky, because user is authenticated by security server and service
should just validate the token. In this case JAAS Login Module can either take over token
validation and fill Subject Principles based on token attributes (like Kerberos does) or skip
validation step (if it is already done by CXF interceptors) and create Subject with Principles.
>
> 2. Authorization
> IMO the task fit good for JAAS is mapping user to role and creating Role Principles.
Other authorization steps is either technology or container specific: using security annotations,
container configuration, role-method maps, etc.
>
> By the way, JEE 6 introduced some extensions for JAAS in Java Specification Request 196
(http://docs.oracle.com/cd/E19575-01/820-3740/ghcwf/index.html). It is more message processing
oriented, introduces agents for validating security tokens or signatures and determines a
standard way to obtain user principals and group principals. The JSR is primarily designed
for JEE application servers, but perhaps it makes sense to look in and use some ideas/API
from that.
>
> Regards,
> Andrei.
>

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Mime
View raw message