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.