Hi Chris,

The problem with the plugable aproach is that we would have to create a new API that then CXF and at least the Shiro "bridge" module would depend on. From another point of view JAAS can even be seen as the basis for the plugable approach. The JAAS API is the common API and we can have different authentication modules in CXF that simply need to result in an established JASS context in the end. The big advantage of JAAS compared to another API ist that it is built into the JRE so everyone already has the API. So I would prefer that we try to attach Shiro to JAAS too. This is indeed something we could discuss on the shiro list.

I see three general scenarios where shiro is involved:

1. Do all authentication and auhorization with shiro. (e.g. Shiro filter for Authentication and Shiro calls in business logic for Authorization).
Here it is all shiro. We probably need no special integration

2. Do authentication in shiro and authorization in CXF.
In this case it would be ideal if shiro could simply establish a JAAS context in addition to its own security context. This alone should then fully work for CXF as soon as we rely on JAAS in CXF. Till then we could use a small CXF module to establish a CXF SecurityContext from an existing JAAS context.

3. Do authentication in CXF using JAAS and authorization in shiro.
There we would need the bridge in the other direction. Shiro would need a small adapter that creates a Shiro Security context from an existing JAAS context

Regarding OSGi I see no real problems with JAAS. I tested The JAASAuthenticationFeature together with my new blueprint authorization module and the karaf role based access system (for OSGi services) and it works well. Cross service calls should be no issue as they use the same thread in OSGi. So the JAAS context is untouched and simply works. In fact JAAS is the standard authentication / authorization model for OSGi. For example the whole OSGi security framework with things like BundlePermission relies on JAAS.

Christian


On 14.07.2014 03:01, Chris Geer wrote:
Christian,

I'm not sure I have specific advice about how to approach Shiro
compatibility without spending some cycles on it. I think we could engage
Les and Shiro community to help though. One possible approach might just be
to have CXF use a pluggable approach so that it calls out to an API when it
checks if a user is authentication/authorized. That way a JAAS
implementation could be put in place but a Shiro or Spring Security
implementation could also be put in place. This would have to be made OSGI
friendly, but I bet it could be done.

I guess I just wanted to toss that out there so that any decisions that
were made wouldn't preclude using frameworks other than JAAS. In my
experience, using JAAS in an OSGI environments, with cross-service calls,
is very problematic so I'd just hate to see CXF require usage of JAAS. One
could argue that CXF didn't need to provide A&A at all in the core and
external libraries can be used through filters/interceptors as the
standard.

I'll give it some more thought as this conversation continues.

Chris





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

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

Reply via email to