Jackrabbit Content Repository
  1. Jackrabbit Content Repository
  2. JCR-1977

authentication order has changed from 1.4.x to 1.5.x

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.5, 1.5.2
    • Fix Version/s: 1.6
    • Component/s: jackrabbit-core, security
    • Labels:
      None
    • Environment:
      JBoss 4.0.5 + deployed Liferay 4.2.2 on any Platform

      Description

      In 1.4.x inside RepositoryImpl.login(...) at first the local configuration is checked for configured LoginModules and after it was unsuccessful, the JAAS component is asked:

      AuthContext authCtx;
      LoginModuleConfig lmc = repConfig.getLoginModuleConfig();
      if (lmc == null)

      { authCtx = new AuthContext.JAAS(repConfig.getAppName(), credentials); }

      else {
      ...

      With 1.5.x this behaviour has moved to SimpleSecurityManager.init(..) and is changed:
      LoginModuleConfig loginModConf = config.getLoginModuleConfig();
      authCtxProvider = new AuthContextProvider(config.getAppName(), loginModConf);
      if (authCtxProvider.isJAAS())

      { log.info("init: using JAAS LoginModule configuration for " + config.getAppName()); }

      else if (authCtxProvider.isLocal()) {
      ...

      The problem is with JBoss JAAS implemantation, that authCtxProvider.isJAAS() is always true.
      Because for any reason, the result of Configuration.getAppConfigurationEntry(appName) is never empty,
      when a jaas.config is specified for Liferay. Using different appName takes no effect, always the configuration inside the jaas.config is used.

      I think still first the local configuration should be concerned, before using JAAS.

        Activity

        Jukka Zitting made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Jukka Zitting made changes -
        Workflow jira [ 12452469 ] no-reopen-closed, patch-avail [ 12468036 ]
        Jukka Zitting made changes -
        Fix Version/s 1.6.0 [ 12313459 ]
        Fix Version/s 2.0.0 [ 12312449 ]
        Hide
        Jukka Zitting added a comment -

        Merged to the 1.x branch in revision 791815.

        Show
        Jukka Zitting added a comment - Merged to the 1.x branch in revision 791815.
        angela made changes -
        Component/s security [ 11646 ]
        angela made changes -
        Field Original Value New Value
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee angela [ anchela ]
        Fix Version/s 2.0.0 [ 12312449 ]
        Resolution Fixed [ 1 ]
        Hide
        angela added a comment -

        rev. 785981
        Changed AuthContextProvider to prefer 'local' LoginModule over JAAS. This means that the 'local' configuration always takes precedence and JAAS configuration is only respected if no local config is present.

        Show
        angela added a comment - rev. 785981 Changed AuthContextProvider to prefer 'local' LoginModule over JAAS. This means that the 'local' configuration always takes precedence and JAAS configuration is only respected if no local config is present.
        Hide
        Jason Gritman added a comment -

        We created a workaround for this issue by subclassing org.apache.jackrabbit.core.security.authentication.AuthContextProvider and overridding isJAAS() to always return false.

        Next we had to create a complete copy of org.apache.jackrabbit.core.security.simple.SimpleSecurityManager and have it call our new AuthContextProvider class in the init() method instead of the old one.

        Finally we added a <SecurityManager> element to our repository configuration referencing the new class.

        It seems like this issue could be fixed by allowing the <SecurityManger> node to pass in a param for enabling/disabling JAAS. This flag could then be passed to AuthContextProvider.

        Show
        Jason Gritman added a comment - We created a workaround for this issue by subclassing org.apache.jackrabbit.core.security.authentication.AuthContextProvider and overridding isJAAS() to always return false. Next we had to create a complete copy of org.apache.jackrabbit.core.security.simple.SimpleSecurityManager and have it call our new AuthContextProvider class in the init() method instead of the old one. Finally we added a <SecurityManager> element to our repository configuration referencing the new class. It seems like this issue could be fixed by allowing the <SecurityManger> node to pass in a param for enabling/disabling JAAS. This flag could then be passed to AuthContextProvider.
        Hide
        Jason Gritman added a comment -

        We're also experiencing this issue on JBoss 5.0.

        Show
        Jason Gritman added a comment - We're also experiencing this issue on JBoss 5.0.
        Thomas Fromm created issue -

          People

          • Assignee:
            angela
            Reporter:
            Thomas Fromm
          • Votes:
            3 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development