On 13.03.2015 10:58, Timothy Ward wrote:
So remarks below about what I found:
Authentication
-------------------
I also have an implementation of the authentication part in cxf:
https://github.com/apache/cxf/blob/07c6322a52c12077567a48c9a87e832ea9362886/core/src/main/java/org/apache/cxf/interceptor/security/JAASLoginInterceptor.java
One important thing we found when integrating with cxf is that a JAAS
authentication can not simply be a method call that throws an
exception when the authentication fails. For JAAS it is really
important to call the user code in subject.doAs() as only then
AccessControler.getContext() works.
You’re confusing authentication and authorization here. The
AuthorityAdmin is where you would implement the doAs() to associate
the user subject with the thread.
Ok .. so I would call authenticate to get the userId and then call
AuthorityAdmin.call to establish the JAAS context.
That can work but it requires that the implementation keeps the subject
somewhere. It is created in authenticate and is needed in call.
I looked into the Authenticator API
https://github.com/osgi/osgi.enroute/blob/master/osgi.enroute.base/src/osgi/enroute/authentication/api/Authenticator.java
I dont think the authenticate method in Authenticator makes sense for
JAAS.
String authenticate(Map<String,Object> arguments, String... sources)
throws Exception;
The user code must be executed inside a PrivledgedAction callback for
JAAS to work which is not possible to do with this interface. In
general I wonder if we really need a authentication API in OSGi. I
think JAAS should be able to handle all cases. So an option may be to
describe in the spec how to use JAAS in OSGi and how it relates to
the later Authorization part.
Passing a Map to the authenticator is plenty (I know, I’ve done it).
JAAS works really badly in OSGi because it does so much reflective
class loading. This is why the service based approaches exist. The
implementation of the Authenticator can work through the issues and
load the relevant login modules. The implementation could even be an
adapter that delegates to one of the existing JAAS implementations.
It is definately enough for simple cases. I am not sure for more
advanced cases but I have not tried them with pure JAAS either.
Authorization
------------------
I also did a JEE annotation based authorization module for blueprint:
https://github.com/apache/aries/blob/trunk/blueprint/blueprint-authz/src/main/java/org/apache/aries/blueprint/authorization/impl/AuthorizationInterceptor.java
Inside the interceptor I simply check the principal names against
@RolesAllowed. So they match for user principal as well as for a role
principal. I am not sure if this is correct.
Interceptor checks for security are a flawed model. Firstly they don’t
happen if the interceptor doesn’t run. Secondly they require a
container breach to occur, meaning that internal method calls don’t
apply the security check. This leads to all manner of privilege
escalation attacks. You could still implement the interceptor model on
top of the Authority interface if that’s the way you want to go.
I would not say interceptor checks are flawed but they sure have their
pros and cons. In any case I am well aware that an interceptor model is
not enough as sometimes you want dynamic or very specific checks that
simply can not be expressed with annotations.
The Authority interface looks nice. Together with UserAdmin I should be
able to handle my cases with it.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
