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

        Thomas Fromm created issue -
        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.
        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
        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.
        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 ]
        angela made changes -
        Component/s security [ 11646 ]
        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.
        Jukka Zitting made changes -
        Fix Version/s 1.6.0 [ 12313459 ]
        Fix Version/s 2.0.0 [ 12312449 ]
        Jukka Zitting made changes -
        Workflow jira [ 12452469 ] no-reopen-closed, patch-avail [ 12468036 ]
        Jukka Zitting made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        126d 32m 1 angela 18/Jun/09 10:24
        Resolved Resolved Closed Closed
        56d 5h 39m 1 Jukka Zitting 13/Aug/09 16:03

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development