[keycloak-dev] Cross-DC and codeToToken request
mposolda at redhat.com
Wed May 24 16:59:46 EDT 2017
On 24/05/17 16:30, Bill Burke wrote:
> On 5/24/17 9:38 AM, Stian Thorgersen wrote:
>> On 24 May 2017 at 15:04, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>> wrote:
>> We've talked about this earlier in the thread. The User session
>> is needed as brokering or some other component might have stored
>> temporary data within the user session that is being mapped to a
>> claim. This will become especially important when we implement
>> no-import brokering. Either the code has to contain all claims,
>> or the user session has to be available.
>> That's the part that I don't understand. Why would it even contain
>> anything if the code is just a permission to obtain a token. We
>> invoke any protocol mappers or anything until the first token is created.
> I'm just saying that you may need information in the UserSession to be
> able to create a token. Protocol mappers are iterated when deciding
> to show the consent screen. I'm not sure why protocol mappers were
> stored in the user session. Marek will have to answer that question.
AFAIR the only reason was scope parameter. If you did SSO login for 2
times with same client and same userSession, it used to create 2
separate clientSessions. Every clientSession may have different roles if
scope parameter is different. That's why roles needed to be listed in
clientSession. For protocolMappers, we didn't support scope parameter,
but we planned to add that.
Anyway, there is JIRA for remove protocolMappers and roles from the
session. It can be done as long as the information is available inside
"code" and inside "refreshToken". So as long as "code" contains the
informations from the authorizationRequest (clientId, scope, etc), we
don't need to keep this information inside userSession.
More information about the keycloak-dev