5 Replies Latest reply on Aug 8, 2013 2:31 PM by Randall Hauch

    Custom Authorization Provider

    Steven Taylor Newbie

      Hi,

       

      I am trying to get a custom authorization prover working, i have implemented a class which implements the org.modeshape.jcr.security.AuthorizationProvider interface.  I have added it to the configuration as per the documentation, with the following command in the CLI

       

      /subsystem=modeshape/repository=drsopen/authenticator=custom:add(classname="org.test.DRSAuthorizationProvider", module="org.test")

       

      however i get the following error in the log files when i try to invoke any action

       

      Unable to initialize authentication provider "{ "name" : "DRSAuthorization" , "classloader" : "com.hp.drsopen" , "classname" : "org.test.DRSAuthorizationProvider" }" for repository "drsopen": org.test.DRSAuthorizationProvider cannot be cast to org.modeshape.jcr.security.AuthenticationProvider: java.lang.ClassCastException: org.test.DRSAuthorizationProvider cannot be cast to org.modeshape.jcr.security.AuthenticationProvider

       

      The actual code in the class doesn't do anything at all other than log a message and return true.

       

      I'm running modeshape 3.3.0 Final in EAP 6.1GA

       

      Kind Regards,

       

      Steve

        • 1. Re: Custom Authorization Provider
          Randall Hauch Master

          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
            Steven Taylor Newbie

            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
              Randall Hauch Master

              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
                Steven Taylor Newbie

                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