Support Standard IdentityStore deferring authentication to the Application Server

[cptaps]

While upgrading some old J2EE applications I have needed to continue supporting an existing EIS based authentication mechanism that some clients preferred to use, but for other clients the options available out-of-the-box with various Application Server providers are sufficient. Regardless of the actual credential validation however, retrieval of the credentials was a custom mechanism and best implemented using the HttpAuthenticationMechanism that the Security specification provides. Unfortunately, for Wildfly at least, this appears to just indicate that the application will handle all authentication itself, and the only IdentityStore options available out-of-the-box are those in the specification thus precluding the use of many options that would otherwise be available.

Could we please come up with a standardized IdentityStore for deferring the credential validation to the Application Server itself? This would surely reduce the number of such IdentityStore mechanisms that need to be added to/removed from the specification over the years and provide incentives for Application Server providers to differentiate their products further. It would also make it much easier for developers to offer a custom authentication mechanism while retaining the option to use out-of-the-box credential validation.

Surely a mechanism such as the ConfigProperty mechanism under the Jakarta Connectors specification could be used to support any custom configuration requirements the Application Server might require for their various options. Payara may already have something like this (, I believe it takes a 'Realm'?) Wildfly could make the 'SecurityDomain' a ConfigProperty as required. If the Application Server provides no built in authentication support, then they wouldn't be required to support this IdentityStore option.

Does this sound reasonable?

[arjantijms]

Does this sound reasonable?

Absolutely! On a more technical level it's about bridging to whatever proprietary credential validation an application server has in place. It's technically not really the difference between an identity store in the application and in the applictation server, as all the default (standard) identity stores live inside the application server, and the application server manages these without the application necessarily doing much more than declaring which one should be used.

The spec already hinted at application servers being free to provide additinal identity stores (meaning, ones directly compatible with the Jakarta Security spec) and application servers being free to enable such stores using proprietary config (config outside the application).

I'm sure this has been discussed before, and indeed, at Payara I proposed something like this and we implemented it back then.

Also, by dropping down to the underlying Jakarta Authentication, and using its jakarta.security.auth.message.callback.PasswordValidationCallback this is basically possible today. The PasswordValidationCallback handler delegates to whatever (propietary) store the server has in place.

That all said, we should be more explicit in the spec about this, and perhaps provide a store / annotation where the application can explicitly ask for an application server specific store (of whatever server specific type). A process difficulty here is with how to require and test this exactly. Since EE 11, we don't have optional features anymore; so every server still has to support this. Since Servlet implicitly requires proprietary stores to exist in a Servlet container, we can kinda assume that every implementation has built-in proprietary authentication support.

[cptaps]

Thanks for pointing out the PasswordValidationCallback, but that seems to always be mentioned in the context of a SAM.

Can we use this PasswordValidationCallback mechanism from an IdentityStore? It seems to require a Subject, which does not appear to be readily available in the IdentityStore api unless I'm missing something again?

Now I understand that a HttpAuthenticationMechanism is an abstraction over a SAM, but does that mean we can use this PasswordValidationCallback in the HttpAuthenticationMechanism directly or do we have to implement a SAM along the lines of this example (Elytron - SimpleServerAuthModule.java).

If we have to drop to the SAM level, then it's no longer 'simple' for an application developer ... and it also means introducing another layer of configuration to either select between HAM and SAM when you want to use a custom identity store (CDI selection possibly) or defer to the container, or alternatively application specific config within the SAM to make that selection.

Thoughts?

[arjantijms]

First of all, sorry for the long delay in getting back to you.

Now I understand that a HttpAuthenticationMechanism is an abstraction over a SAM, but does that mean we can use this PasswordValidationCallback in the HttpAuthenticationMechanism directly

Yes, there's access to this from the HttpMessageContext, but we haven't really provided good tests and examples for this. The API interaction also misses a few key elements, but in broad terms it works.

From an HttpAuthenticationMechanism you can use the HttpMessageContext to get the underlying Handler. You can use this to process the PasswordValidationCallback:

Create the PasswordValidationCallback first:

PasswordValidationCallback passwordValidation =
            new PasswordValidationCallback(
                context.getClientSubject(), "someUser", "somePassword".toCharArray());

Strictly speaking, you don't necessarily need to give it the actual Subject, as here we're just collecting the output of the PasswordValidationCallback calls to the native store.

Then we process this callback via the handler:

context.getHandler().handle(new Callback[] { passwordValidation });

boolean authenticated = passwordValidation.getResult();

The authenticated / non-authenticated answer comes from passwordValidation.getResult(), while the groups (unmapped roles) are stored in a proprietary way into the Subject.

The APIs don't have a way to say "success, and use the proprietary details from the Subject", but we can extract the (mapped) roles from the Subject and return these, as follows:

PrincipalMapper mapper = PolicyContext.get(PRINCIPAL_MAPPER);

Principal callerPrincipal = mapper.getCallerPrincipal(context.getClientSubject());
Set<String> roles = mapper.getMappedRoles(context.getClientSubject());

return context.notifyContainerAboutLogin(callerPrincipal, roles);

I put together a small example demonstrating this: https://github.com/arjantijms/security-native-store

In that example the GlassFish default store (the file realm) is seeded with a user name and a password, and this is subsequently used by the authentication mechanism.