> On 13 Mar 2015, at 10:22, Christian Schneider <[email protected]> wrote: > > 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.
The thing returned can be the user id, or some token representing the user (Peter and I disagree slightly on this one :) ), and then yes, that’s what you pass to the Authority > > That can work but it requires that the implementation keeps the subject > somewhere. It is created in authenticate and is needed in call. Yes, it either requires a back channel, or some other contract between the authenticator and the authority admin implementations, to get the subject/user information. En Route uses UserAdmin for this, but you can slice it however you want - the user string may be a token, or whatever. > >> >>> >>> 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. The use cases of the authenticator are listed in the RFP, and the RFP is an open process (hence the public Git Hub repo) - feel free to suggest more use cases if you have them. > >> >>> >>> 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 > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
