[
https://issues.apache.org/jira/browse/OAK-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-6345.
-------------------------
Resolution: Not A Problem
> Allow TokenLoginModule framework to create token for other LoginModules if
> userid is not known in login()
> ---------------------------------------------------------------------------------------------------------
>
> Key: OAK-6345
> URL: https://issues.apache.org/jira/browse/OAK-6345
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
> Reporter: Alexander Klimetschek
> Priority: Major
>
> 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:
> {code:java}
> TokenInfo createToken(@Nonnull Credentials credentials, String loginName)
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
