[jira] [Comment Edited] (OAK-4129) Use CredentialsSupport in TokenConfigurationImpl and TokenProviderImpl

["Alexander Klimetschek (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263268#comment-15263268 ] 

Alexander Klimetschek edited comment on OAK-4129 at 4/28/16 11:42 PM:
----------------------------------------------------------------------

Will this really solve the problem of OAK-3899? Maybe it would, but the description doesn't make it clear...

The problem over there is that some authentication mechanisms do not have a user id that is passed into session.login(), but some other credential like a token, and only in the middle of the login module process the external identity provider figures out the (local) user id (very much like the TokenLoginModule itself), which is required for the TokenLoginModule to create a token in commit().

This means we currently cannot do "external identity provider authentication w/o user id in credentials + create token" in one go. We are using a workaround in which we create a new token using a new JCR session in the sling authentication handler after the first login was successful (but did not provide a ".token" in the attributes).

The only thing to get this issue fixed would be to respect {{javax.security.auth.login.name}} in the shared state - which is completely independent on the type of Credentials passed in. Also, to support the .token creation, the custom Credentials must have a map where you can add the token to, to return it to the caller of session.login(), and that would require a common interface like "AttributedCredentials" with set/getAttributes().


was (Author: alexander.klimetschek):
Will this really solve the problem of OAK-3899? Maybe it would, but the description doesn't make it clear...

The problem over there is that some authentication mechanisms do not have a user id that is passed into session.login(), but some other credential like a token, and only in the middle of the login module process the external identity provider figures out the (local) user id (very much like the TokenLoginModule itself), which is required for the TokenLoginModule to create a token in commit().

This means we currently cannot do "external identity provider authentication + create token" in one go. We are using a workaround in which we create a new token using a new JCR session in the sling authentication handler after the first login was successful (but did not provide a ".token" in the attributes).

The only thing to get this issue fixed would be to respect {{javax.security.auth.login.name}} in the shared state - which is completely independent on the type of Credentials passed in. Also, to support the .token creation, the custom Credentials must have a map where you can add the token to, to return it to the caller of session.login(), and that would require a common interface like "AttributedCredentials" with set/getAttributes().

> Use CredentialsSupport in TokenConfigurationImpl and TokenProviderImpl
> ----------------------------------------------------------------------
>
>                 Key: OAK-4129
>                 URL: https://issues.apache.org/jira/browse/OAK-4129
>             Project: Jackrabbit Oak
>          Issue Type: New Feature
>          Components: core
>            Reporter: angela
>            Assignee: angela
>            Priority: Minor
>
> the default token implementation could make use of the {{CredentialsSupport}} thus not limiting the functionality to {{SimpleCredentials}}, which could still be used as default.
> in order to do so the {{CredentialsSupport}} would need to be extended with the ability to setAttibutes (i.e. an attribute map) to credentials corresponding to the getAttributes method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)