[keycloak-dev] Cross-DC and codeToToken request
mposolda at redhat.com
Tue May 23 04:34:41 EDT 2017
On 22/05/17 19:29, Stian Thorgersen wrote:
>>> I reckon protocol mappers should be refactored regardless though. The
>>> details should be in the code and token not in the user session.
>> For protocol mappers, the reason why the user session need to be
>> available is that some component might be storing temporary information
>> within the session that needs to be mapped to the token. Any example is
>> a broker login that doesn't want or need to import into database, but
>> instead stores in in the session. Doesn't kerberos store stuff in the
>> session that can be mapped to the token? Finally, eventually we will
>> want import-less brokering where the user is created within the session
>> and destroyed with the session so we dont' have to hit the DB and import.
> True, so we basically will need to make sure the user session exists and is
> persisted. I reckon on-demand replication if technically possible the best
Regarding this, I was thinking about adding separate callback method to
protocolMappers SPI, which will be invoked at the time when OAuth code
is generated (and before it is sent to the application). This would be
done in browser request and userSession will be available here. So the
mappers, which need userSession (UserSessionNoteMapper etc) will add the
claim into the code JWT. Then later code-to-token endpoint will just
copy those claims from the code JWT to the token JWT. The claims, which
don't need user session (eg. UserAttributeMapper) won't do anything in
the new code JWT callback, but claims will be added to the token in the
code-to-token endpoint directly from UserModel in same way like it is now.
Anyway, I don't know if it handles all the corner cases and future
scenarios (in-memory UserModel etc), so will try to go the "on-demand
replication of userSession" path. We will see if that's sufficient.
More information about the keycloak-dev