[
https://issues.apache.org/jira/browse/OAK-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated OAK-6345:
---------------------------------------
Description:
If a custom LoginModule accepting custom credentials 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. The 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, and now has 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).
Another approach might be to
was:
If a custom LoginModule accepting custom credentials 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. The 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, and now has 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).
> Allow TokenLoginModule 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
>
> If a custom LoginModule accepting custom credentials 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. The 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, and now has 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).
> Another approach might be to
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
