Jackrabbit Oak
  1. Jackrabbit Oak
  2. OAK-91 Implement Authentication Support
  3. OAK-256

JAAS Authentication failing in OSGi env due to classloading issue

    Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.5
    • Fix Version/s: 0.5
    • Component/s: jcr
    • Labels:

      Description

      At times Repository login fails because the LoginModule cannot be instantiated

      Caused by: javax.jcr.LoginException: unable to find LoginModule class: org.apache.jackrabbit.oak.security.authentication.LoginModuleImpl
      	at org.apache.jackrabbit.oak.jcr.RepositoryImpl.login(RepositoryImpl.java:139)
      	at org.apache.jackrabbit.oak.jcr.SessionImpl.impersonate(SessionImpl.java:114)
      	at org.apache.sling.jcr.base.SessionProxyHandler$SessionProxyInvocationHandler.invoke(SessionProxyHandler.java:101)
      	at $Proxy9.impersonate(Unknown Source)
      	at org.apache.sling.jcr.davex.impl.servlets.SlingDavExServlet$1.getLongLivedSession(SlingDavExServlet.java:206)
      
      

      As a fix LoginContextProviderImpl should switch the Thread's context classloader (TCCL) to oak-jcr bundle's classloader so that required loginmodule class can be instantiated

        Activity

        Hide
        angela added a comment -

        as stated in OAK-91 having proper jaas auth also within osgi is on our todo list and we are aware of the problem. but as long as OAK-91 has not been resolved there is no need in expecting this to work -> making this a subtask.

        Show
        angela added a comment - as stated in OAK-91 having proper jaas auth also within osgi is on our todo list and we are aware of the problem. but as long as OAK-91 has not been resolved there is no need in expecting this to work -> making this a subtask.
        Hide
        Jukka Zitting added a comment -

        fails for those calls where impersonation is performed as in Session#impersonate

        The impersonate() method calls login(), so the TCCL will still get set with my fix.

        We should eventually come up with a more reliable solution.

        Agreed. See also my recent blog post on this: http://blogs.adobe.com/jzitting/jaas-authentication-and-osgi/ Once we have something like that we can drop these TCCL workarounds.

        Show
        Jukka Zitting added a comment - fails for those calls where impersonation is performed as in Session#impersonate The impersonate() method calls login(), so the TCCL will still get set with my fix. We should eventually come up with a more reliable solution. Agreed. See also my recent blog post on this: http://blogs.adobe.com/jzitting/jaas-authentication-and-osgi/ Once we have something like that we can drop these TCCL workarounds.
        Hide
        Michael Dürig added a comment -

        The TCCL approach won't work reliably I think. We should eventually come up with a more reliable solution. See also http://www.slideshare.net/mfrancis/common-security-services-consolidation-patterns-for-legacy-components-stefan-vladov

        Show
        Michael Dürig added a comment - The TCCL approach won't work reliably I think. We should eventually come up with a more reliable solution. See also http://www.slideshare.net/mfrancis/common-security-services-consolidation-patterns-for-legacy-components-stefan-vladov
        Hide
        Chetan Mehrotra added a comment -

        As noted in previous comment I tried to use the same approach however it fails for those calls where impersonation is performed as in Session#impersonate. As by the time that call is done TCCL would have been reverted back.

        I am not sure of a better approach. Probably in OSGi env we can have a custom LoginContextProvider which handles it better. However untill then I cannot workaround it from outside

        Show
        Chetan Mehrotra added a comment - As noted in previous comment I tried to use the same approach however it fails for those calls where impersonation is performed as in Session#impersonate. As by the time that call is done TCCL would have been reverted back. I am not sure of a better approach. Probably in OSGi env we can have a custom LoginContextProvider which handles it better. However untill then I cannot workaround it from outside
        Hide
        Jukka Zitting added a comment -

        Fixing this in LoginContextProviderImpl is a bit troublesome, as in non-OSGi environments a configured LoginModule could well come from outside the oak-core class loader.

        Therefore I adjusted the patch a bit to only force the thread context class loader when a login() call when running inside an OSGi environment. See revision 1380738 for details.

        Show
        Jukka Zitting added a comment - Fixing this in LoginContextProviderImpl is a bit troublesome, as in non-OSGi environments a configured LoginModule could well come from outside the oak-core class loader. Therefore I adjusted the patch a bit to only force the thread context class loader when a login() call when running inside an OSGi environment. See revision 1380738 for details.
        Hide
        Chetan Mehrotra added a comment -

        We might have to set the TCCL at LoginContextProviderImpl because switching it in ContentRepository level or any other layer does not help in case where impersonation is performed Session#impersonate. So the only safe place would be to switch it in LoginContextProviderImpl

        Show
        Chetan Mehrotra added a comment - We might have to set the TCCL at LoginContextProviderImpl because switching it in ContentRepository level or any other layer does not help in case where impersonation is performed Session#impersonate. So the only safe place would be to switch it in LoginContextProviderImpl
        Hide
        Chetan Mehrotra added a comment -

        Patch to switch TCCL while creating LoginContext. Note that LoginContext stores the TCCL as part of creation itself. If required the TCCL switch can be done ContentRepository.login method also

        Show
        Chetan Mehrotra added a comment - Patch to switch TCCL while creating LoginContext. Note that LoginContext stores the TCCL as part of creation itself. If required the TCCL switch can be done ContentRepository.login method also

          People

          • Assignee:
            Jukka Zitting
            Reporter:
            Chetan Mehrotra
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development