[
https://issues.apache.org/jira/browse/OAK-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15107761#comment-15107761
]
Alexander Klimetschek edited comment on OAK-3899 at 1/20/16 8:15 PM:
---------------------------------------------------------------------
Attached a [patch|^OAK-3899.patch] (against oak 1.2.2 release), that basically
takes the shared attribute {{javax.security.auth.login.name}} over the
{{SimpleCredentials.getUserID()}} if it's not null.
It was a bit tricky, as this logic including the
write-back-token-to-credentials happens inside the TokenProviderImpl. The use
of the {{TokenProvider.createToken(Credentials)}} method prevents one from
passing the separate shared login name. Thus I had to move this logic to the
TokenLoginModule, and effectively deprecating
{{TokenProvider.createToken(Credentials)}} (being called from the
TokenLoginModule was it's only usage within Oak at least).
I think this makes sense: the token provider should be concerned only with
creating & managing tokens in the repository (or whatever persistence is
wanted). Parsing jcr Credentials and sending back the new token in the
{{.token}} attribute if it's a SimpleCredentials is orthogonal and better left
with the TokenLoginModule anyway.
was (Author: alexander.klimetschek):
Attached a [patch|^OAK-3899.patch], that basically takes the shared attribute
{{javax.security.auth.login.name}} over the {{SimpleCredentials.getUserID()}}
if it's not null.
It was a bit tricky, as this logic including the
write-back-token-to-credentials happens inside the TokenProviderImpl. The use
of the {{TokenProvider.createToken(Credentials)}} method prevents one from
passing the separate shared login name. Thus I had to move this logic to the
TokenLoginModule, and effectively deprecating
{{TokenProvider.createToken(Credentials)}} (being called from the
TokenLoginModule was it's only usage within Oak at least).
I think this makes sense: the token provider should be concerned only with
creating & managing tokens in the repository (or whatever persistence is
wanted). Parsing jcr Credentials and sending back the new token in the
{{.token}} attribute if it's a SimpleCredentials is orthogonal and better left
with the TokenLoginModule anyway.
> TokenLoginModule ignores shared key javax.security.auth.login.name
> ------------------------------------------------------------------
>
> Key: OAK-3899
> URL: https://issues.apache.org/jira/browse/OAK-3899
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Affects Versions: 1.3.14
> Reporter: Alexander Klimetschek
> Attachments: OAK-3899.patch
>
>
> The {{TokenLoginModule}} and specifically TokenProviderImpl [only look at
> SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/1144914c053ec9c2723450261fabfee1bd9d0e58/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
> when creating a token.
> However, in certain situations, such as with the ExternalLoginModule and
> non-username/password credentials, the SimpleCredentials are used but don't
> have a user id as the real user id is determined not by the caller of
> {{Repository.login()}}, but by the external identity provider inside the
> ExternalLoginModule (and the credentials might not include any kind of user
> id, say an opaque token from an external service). In this case,
> {{SimpleCredentials.getUserID()}} returns null and the token implementation
> fails to create a token and does not return it in the {{.token}} attribute of
> the credentials.
> Instead, the TokenLoginModule should look at the shared
> {{javax.security.auth.login.name}} attribute, which can de-facto override a
> {{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
