[ 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)