Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Won't Fix
-
1.3.14
-
None
-
None
Description
The TokenLoginModule and specifically TokenProviderImpl only look at SimpleCredentials.getUserID() 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.
Attachments
Attachments
Issue Links
- is related to
-
OAK-3876 ExternalLoginModule ignores authorizable ID returned from IDP
- Resolved
Attached a 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.