> On 13 Mar 2015, at 09:34, Christian Schneider <[email protected]> wrote: > > The rfps sound very interesting as they could cover my case too. I will read > through them. It would be great if we can reuse the upcoming spec for karaf > too. > Do you have the jaas based implementation somewhere? The links to enroute do > not seem to use jaas.
The JAAS based implementation I wrote isn’t open source. > > 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 > > <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. > > I looked into the Authenticator API > https://github.com/osgi/osgi.enroute/blob/master/osgi.enroute.base/src/osgi/enroute/authentication/api/Authenticator.java > > <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. > > 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 > > <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. > > Christian > > > On 13.03.2015 09:53, Timothy Ward wrote: >> Hi Christian, >> >> It sounds like what you want is the Authentication Service [1] from the En >> Route project (and probably also the Authorization service [2]). These are >> feeding into the OSGi standardisation process as part of some RFPs [3] and >> [4]. >> >> I have already created a viable JAAS-based version of the Authenticator, and >> a group/role mapping Authorization implementation. Lessons from these will >> also feed into the standardisation process. >> >> Regards, >> >> Tim >> >> [1] >> https://github.com/osgi/osgi.enroute.bundles/tree/master/osgi.enroute.authenticator.simple.provider >> >> <https://github.com/osgi/osgi.enroute.bundles/tree/master/osgi.enroute.authenticator.simple.provider> >> [2] >> https://github.com/osgi/osgi.enroute.bundles/tree/master/osgi.enroute.authorization.simple.provider >> >> <https://github.com/osgi/osgi.enroute.bundles/tree/master/osgi.enroute.authorization.simple.provider> >> [3] >> https://github.com/osgi/design/blob/master/rfps/rfp-0164-Authentication.pdf >> <https://github.com/osgi/design/blob/master/rfps/rfp-0164-Authentication.pdf> >> [4] >> https://github.com/osgi/design/blob/master/rfps/rfp-0165-Authorization.pdf >> <https://github.com/osgi/design/blob/master/rfps/rfp-0165-Authorization.pdf> >> >> >> > > -- > Christian Schneider > http://www.liquid-reality.de <http://www.liquid-reality.de/> > > Open Source Architect > http://www.talend.com <http://www.talend.com/> > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
