Page History

CXF already supports a wide range of authentication and authorization approaches. Unfortunately they are all configured differently and do not integrate well with each other.

...

An XACML policy enforcement point can retrieve the JAAS login data and do authorization against an XACML Policy Decision Point (PDP).

Separating Authorization from CXF

As authorization is not only relevant for webservices it makes sense to keep the authorization code separate from cxf too. So one way to implement authorization would be to put it into a blueprint extension. Of course this would cover only OSGi and blueprint but it would be a start.

It could work similar to the XA transaction support. Unlike in tx support we could scan all beans for security annotations like @RolesAllowed. Then for each bean that has this annotation we could proxy it with a class that does the security check. This would allow to have minimal xml configuration.

Another approach is to mark beans for security checks using xml like in tx support. This variant then would also work nicely for XACML authorization as in that case there would be no annotation to scan for.

Karaf role based OSGi service Authorization

Karaf 3 already supports authorization on the OSGi service level and uses JAAS for authentication. So if we do a JAAS login in CXF and the service impl code calls an OSGi service then the Karaf role based securtiy should already work out of the box.We could add annotation based Authorization to karaf code to make it even better and require less config.

Exception handling and answer generation

...

• Failure at Authentication: javax.security.auth.login.LoginException could also be more specific like AccountLockedException
• Failure at Authorization: org.apache.cxf.interceptor.security.AccessDeniedException or java.security.AccessControlException. The later one is better for code separate from cxf as it does not depend on CXF.

Then in the transport like the http transport we map the exception to the defined status code and http response:

• LoginException: HTTP Code 401
• AccessDeniedException, AccessControlException: HTTP Code 403

...

Unfortunately CXF currently does not handle the status code generation in the transport. The exception is already mapped into a Fault at PhaseInterceptorChain. The Fault then holds the statusCode which is by default 500. So one simple way to do the mapping isto map from exception type to fault code in the Fault constructor. This is not extensible but would do for the start.

JAAS Feature

The JAAS feature needs some configuration like the jaas context name. So it makes sense to integrate it with config admin in OSGi and publish it as an OSGi service. So we can keep the JAAS configuration centralized and keep it out of each bundle.

As long as the configs are very limited we could of course also integrate it in each bundles cxf bus. This would have the advantage that it also works outside OSGi.

Authentication activation

Ideally we should integrate the new authentication / authorization model in a way that enable the user to switch on authentication for the karaf server without specific configurations in the user bundles that implement the services. One problem with this very loosely coupled approach is that switching on authentication would secure all services but perhaps some are expected to work without. The other problem is that the services might start before the auth module and then run unsecured.

So we could have a config setting for the CXF OSGi servlet to enable JAAS authentication and set a JAAS config. This would then enable authentication for all services using the named JAAS config from karaf. We could then also switch on the annotaion based authorization. So users could leverage this for their service by just supplying the annotations and doing no other configs on the service level.need a way to mark services that need authentication. One existing way to do so is to bind the auhorization Feature as an OSGi service and add it to the features "by hand". This is a bit verbose but on the other hand it is very clear what happens.

One other approach would be to publish the feature as a an OSGi service with a unique ID (which is already present for features). Then we could have a new Element for cxf:bus and endpoints like that:

<namedFeatures>authentication, xacmlAuthorization</namedFeatures>

This Element would mean that cxf will only publish the endpoint once both of these named features are present and will add the features to the endpoint /busA further approach would be to let the user configure named features on the CXF servlet level (which are then retrieved as OSGi services). So the user can even attach his own extensions on the server level like for ecxample integrating a custom XACML PEP.

Problems

Doing a full JAAS login requires to use subject.doAs to populate the AcessControlContext. This is not possible in a CXF interceptor as the interceptor only works on a message but can not call the next interceptor for doAs. So the question is where to do the JAAS login and the doAs?

...