[
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:43 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}} from the shared state in the token impl -
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
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().
> 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)
