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
