-
1. Re: Custom Authorization Provider
It looks like your module is likely seeing a different copy of the ModeShape API JAR than what ModeShape sees.
Does your 'org.test' module include the ModeShape API or JCR API JARs? Can you share your 'module.xml' file?
-
2. Re: Custom Authorization Provider
Hi Randall,
Will sort the module out in the morning, have to make this anonymous because of my employer.
However i am a little confused about something, I am impementing org.modeshape.jcr.security.AuthorizationProvider however modeshape is trying to cast to org.modeshape.jcr.security.AuthenticationProvider which will always fail as i am not implementing it. How is modeshape differentiating AuthorizationProviders & AuthenticationProviders...?
Kind Regards,
Steve
-
3. Re: Custom Authorization Provider
However i am a little confused about something, I am impementing org.modeshape.jcr.security.AuthorizationProvider however modeshape is trying to cast to org.modeshape.jcr.security.AuthenticationProvider which will always fail as i am not implementing it. How is modeshape differentiating AuthorizationProviders & AuthenticationProviders...?
Ah, gotcha. Sorry for not reading more carefully. Bear with me, as this is not documented well and the differences are subtle.
Authentication and authorization go hand-in-hand, and we've tied the concepts together. You can't have a custom authorization solution without a custom authentication solution, since both need some consistent and common notion of "users". ModeShape allows a custom implementaiton of AuthenticationProvider, and its job is to authenticate each user and (if successful) return a new ExecutionContext in which that session will operate. That ExecutionContext is used all over the place internally, and it is the way various components access anything that is specific to the session or environment in which the component is to perform its operation. For example, the ExecutionContext provides access to: the namespace registry; factories for values, properties, names, paths, threads, etc.; and a SecurityContext. The SecurityContext provides access to security-related functionality, including the username, roles, etc. But if the SecurityContext also implements AuthorizationProvider (or AdvancedAuthorizationProvider), then the SecurityContext can be cast and then used to determine permissions, too.
In hindsight, we probably should not have used "AuthenticationProvider" for the name, but instead "AuthorizationContext". But as other people can implement these interfaces, we can't really change them now.
So, you need to create a class that implements AuthenticationProvider (or AdvancedAuthenticationProvider) and configure ModeShape to use this. When you do, its "authenticate" method implementation will return a new ExecutionContext that contains a custom SecurityContext, and that SecurityContext implementation can optionally also implement AuthorizationProvider or AdvancedAuthorizationProvider. (The difference is in what's passed into the methods.)
See our JassProvider implementation class for a pretty good example of how to create an ExecutionContext with a custom SecurityContext. The JaasSecurityContext doesn't happen to implement AuthorizationProvider or AdvancedAuthorizationProvider, but your's would.
Now, having said all this, if you just want to limit access to already authenticated users, then you might be interested in ModeShape's support for JCR 2.0 Access Control Lists (ACLs) that we just added in 3.4.0.Final. (That release is almost out the door: the artifacts for which are already in the JBoss Maven repository, but I'm still working on updating our site and announcements.) We'll document this feature pretty soon, but suffice to say that it allows clients to make individual nodes accessible via ACLs by adding the "mode:accessControlled" mixin to the node and then creating permissions via the Session's AccessControlManager. Generally, the principal should match an existing & valid user (or group in JAAS), though we can't really verify this. When a user authenticates with a session, and a node contains ACLs, access to that node is granted only when those ACLs grant the appropriate permission to that already authenticated. (If there's an invalid username in an ACL, then no session can ever authenticate with that user.)
The ACL feature does pass the JCR TCK, but we still will classify it as "tech preview" until it is more thoroughly vetted. But you still might be interested in trying it.
-
4. Re: Custom Authorization Provider
Hi Randall,
Thank you for the input, what I was attempting to do was to roll my own ACL implementation. Please note the past tense
Will pull 3.4 when it's available lots of other bit's to play with in the mean time.
As always thank you very much for your help.
Kind Regards,
Steve