[keycloak-dev] Cross-DC and codeToToken request

[Marek Posolda]

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
> option.
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.

Marek