Uploaded image for project: 'ModeShape'
  1. ModeShape
  2. MODE-1451

Anonymous Authentication in providers array ranks above custom provider

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 2.8.1.Final, 2.8.1.GA
    • 2.8.0.Final
    • Common
    • None
    • Hide

      Run with anonymous provider in config, then take it out.

      Show
      Run with anonymous provider in config, then take it out.
    • Hide

      Remove <anonymousUserRoles jcr:primaryType="mode:option" mode:value="" /> from config. Doesn't throw exception but appears to then set String rawAnonRoles = 'admin' (JcrRepository line 963), never getting to custom provider so not actually authenticated.

      Show
      Remove <anonymousUserRoles jcr:primaryType="mode:option" mode:value="" /> from config. Doesn't throw exception but appears to then set String rawAnonRoles = 'admin' (JcrRepository line 963), never getting to custom provider so not actually authenticated.
    • Low

    Description

      Iteration over providers starts with anonymousProvider even if there is a custom provider.

      This means if an anonymousProvider with empty ACL value is specified in the config, a non-null result will get returned by org.modeshape.jcr.security.AuthenticationProviders.authenticate().

      Therefore configuration is fragile, in that you need to either use custom OR anonymous, and specifying <anonymousUserRoles jcr:primaryType="mode:option" mode:value="" /> causes the custom provider to be ignored (commenting out fixes the problem).

      I believe the code that populates the providers array should push the anonymous provider to the bottom. I think this can be done in org.modeshape.jcr.JcrRepository constructor (line 984: // Set up any custom AuthenticationProvider classes ...) by moving that statement block to run before anonymousprovider (line 962), however there is also an issue where if no anonymousProvider is specified in the config, one seems to get created anyway (with 'admin' privileges) so it doesn't look like it is possible to actually authenticate as the user, and therefore any custom SecurityContext is never used.

      Removes ambiguity in configuration: I discovered if I commented out the anonymous provider then the 'null' result moves onto custom, but I'd expect Modeshape to try custom then anonymous before throwing a login exception.

      Could be documented but think having custom read/write + anonymous readonly access is a feature Modeshape should provide, and I believe this prevents that from happening.

      Attachments

        Activity

          People

            rhauch Randall Hauch (Inactive)
            djg2002 David Green (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: