-
1. Re: Problem using a custom authentication provider
The problem is that my authentication provider is never used.
By "never used" I assume you mean it's never called to perform the actual authentication. The only reason why that can happen is if one of the other providers in the list performed a successful authentication first (see https://github.com/ModeShape/modeshape/blob/master/modeshape-jcr/src/main/java/org/modeshape/jcr/security/AuthenticationProviders.java#L58)
Do I need to configure things in a different manner to ensure my provider gets added first in the providers list?
You can't control the order in this case: the first 2 authentication providers are considered "system" providers and are always added first when running in Wildfly.
If you want your own custom authentication/authorization in Wildfly, there are 2 options I can think of:
1. create your own Wildfly CustomLoginModule which you then add to the modeshape security domain (see Security subsystem configuration - WildFly 8 - Project Documentation Editor and http://www.radcortez.com/custom-principal-and-loginmodule-for-wildfly/). I would say this is the preferred approach, since you're running in Wildfly after all.
2. create your own ModeShape authentication provider, add it to the configuration (like you already did) and then make sure the default security providers (via the modeshape security domain) aren't able to authenticate/authorize your users, deferring the logic to your provider.
You can achieve this easily for example by using a UserRolesLoginModule for the modeshape security domain and use empty users & roles properties files.
-
2. Re: Problem using a custom authentication provider
By "never used" I assume you mean it's never called to perform the actual authentication.
Yes, that's what I mean. And yes, I know it is because the other providers authenticate successfully before my provider.
Thanks for the two suggestions. I will have a look at that although I was hoping there was a simpler way of adding a custom provider when running in WildFly. Maybe Custom authentication providers - ModeShape 3 - Project Documentation Editor should be updated to reflect that when running in WildFly you need to do additional work.
-
3. Re: Problem using a custom authentication provider
I had similar problems when using a custom authenitcation provider and agree that updating the documentation to reflect that the system providers are always called first would be useful. It may also be nice to have a clean way to disable them or re-order them via the configuration.
I worked around this by creating my own application implementation of javax.jcr.Credentials and using that when logging in:
repository.login(new OmakaseCredentials());
As non of the system provided authenticator implementations support this Credentials implementation they are ignored and my custom implementation (which does support the application implementation of Credentials) is used.
-
4. Re: Problem using a custom authentication provider
I've opened [MODE-2496] Custom authentication providers in the AS kit should always be invoked first, before the built-in container … and I'll make the change for 4.4. It does make sense if any custom authentication providers are configured, for them to be invoked first in the chain of providers, before the built-in ones. Having to workaroud/hack the default providers just so that the custom provider is invoked is not nice.
-