Description
If a custom LoginModule accepting custom credentials (or ExternalIdentityProvider) wants to switch the credentials (e.g. on the first request of a web app) to a token from the TokenModule (i.e. return this in the (Simple)Credentials after login() for use by a request handler) this is currently not possible when the user id is not known up front in the login() call, but only detected by the custom LoginModule, and passed around between login modules using javax.security.auth.login.name.
This is a follow up from OAK-3899.
1. The main recommendation there was, instead of the the TokenLoginModule respecting the shared key javax.security.auth.login.name and a special handling of SimpleCredentials as in the patch, leave this to a custom TokenProvider.
This would require to change the TokenProvider API to pass through the key (or all keys), something along the lines of:
TokenInfo createToken(@Nonnull Credentials credentials, String loginName)
Since it also requires an application that has been relying on the default TokenProviderImpl, to replicate that logic, it might be desirable to make it easy to reuse that code. E.g. by wrapping and calling the other token provider (maybe this is already possible today in some way).
2. Another approach might be to call TokenInfo.createToken(userId, attributes) from the custom LoginModule aka ExternalIdentityProvider. The question then would be how it can access it (as e.g. osgi service) and if that's a good solution.
3. There might be another intended way through reusing the new CredentialsSupport from OAK-4129, but it seems the crucial javax.security.auth.login.name is not passed through to the relevant code.
Attachments
Issue Links
- supercedes
-
OAK-3899 Extend TokenLoginModule to respect shared key javax.security.auth.login.name
- Resolved
It seems there is some documentation in the meantime: http://jackrabbit.apache.org/oak/docs/security/authentication/token/default.html#Pluggability
AFAICS, this means a custom CredentialsSupport and an ExternalIdentityProvider need some way to share the user id (resolution), likely internally in the custom Credentials object. As the External IDP would resolve the external user first (phase 1) and then later the token login module would call the CredentialsSupport to get the user id (phase 2).
If that's correct, feel free to close the issue.