[keycloak-user] User roles deleted after SSO idle session expires

MEHDi CHAABOUNi mehdi.chaabouni at gmail.com
Wed Mar 20 15:25:27 EDT 2019


Yes, I'm using a "Claim to Role" identity mapper:

{
  "id": "8836ab75-fc4c-4c49-98bd-c3be177a539b",
  "name": "developer-mapper",
  "identityProviderAlias": "microsoft",
  "identityProviderMapper": "oidc-role-idp-mapper",
  "config": {
    "claim": "groups",
    "role": "admin",
    "claim.value": "fea349bb-4183-477b-b3bc-c489133b4546"
  }
}

Is there a workaround until the issue is fixed?
May be a "Post flow login"? (if it's useful, I'm not sure how to setup it)

Thanks Pedro!


On Wed, Mar 20, 2019 at 3:15 PM Pedro Igor Silva <psilva at redhat.com> wrote:

> Btw, just talked with Marek and he told me there is an issue for the
> behaviour I mentioned https://issues.jboss.org/browse/KEYCLOAK-8690.
>
> On Wed, Mar 20, 2019 at 4:07 PM Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> Are you using a "Claim to Role" identity mapper ? Are you mapping groups
>> to roles in the realm ?
>>
>> Asking because, I think that this specific mapper is only removing roles
>> in case there is no claim in the token from the IdP. So roles are mapped
>> and granted only during the first login.
>>
>>
>> On Wed, Mar 20, 2019 at 12:53 PM MEHDi CHAABOUNi <
>> mehdi.chaabouni at gmail.com> wrote:
>>
>>> They are identity provider mappers.
>>>
>>> We do see in the logs that groups being received from AD:
>>>
>>> {
>>>   "aio": "AVQAq/8KAAAA8PGjXf4lVf/Ydo+0vf17iyg5aSofK2vDHlFc3kT2AJD7aEfowYNdsos5tGCOIcfpclqcEvJm3a/0q9vrOIqFISk5DIiSxsbgXaqOQnDLUjc=",
>>>   "amr": "[\"pwd\",\"mfa\"]",
>>>   "family_name": "Chaabouni",
>>>   "given_name": "Mehdi",
>>>   "ipaddr": "207.96.238.194",
>>>   "name": "Mehdi Chaabouni",
>>>   "oid": "cbb75a8f-09a4-441b-8652-4a13ddb22d1c",
>>>   "onprem_sid": "S-1-5-21-808638481-369274112-3737512417-3656",
>>>   "sub": "MxyEhfA1tiGU2xQ-L7w-CI59-7FS4ibR6BYT6pl6aTc",
>>>   "tid": "aab561d6-005e-45d1-807a-d7f53dc07034",
>>>   "unique_name": "mchaabouni at test.com",
>>>   "upn": "mchaabouni at test.com",
>>>   "uti": "ea2dC_nciUGsfUk4mr4SAQ",
>>>   "ver": "1.0",
>>>   "groups": [
>>>     "[\"fea349bb-4183-477b-b3bc-c489133b4546\",\"882e10f9-3682-4a26-9938-b29084ef8135\"]"
>>>   ]
>>> }
>>>
>>>
>>> The groups are mapped correctly the first time that the user is imported
>>> into keycloak.
>>>
>>>
>>> On Wed, Mar 20, 2019 at 10:42 AM Pedro Igor Silva <psilva at redhat.com>
>>> wrote:
>>>
>>>> Your custom mappers are client mappers or identity provider mappers
>>>> ? It does not make sense an empty list of mappers if you have defined
>>>> mappers to your identity provider.
>>>>
>>>> On Wed, Mar 20, 2019 at 11:01 AM MEHDi CHAABOUNi <
>>>> mehdi.chaabouni at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm using Azure Active Directory to authenticate users and I have
>>>>> setup custom mappers to import roles (mapping groups from Active Directory
>>>>> to Keycloak roles).
>>>>> I'm pretty sure the scenario was not working before. There was a lot
>>>>> of development on the front-end application so we didn't notice the problem
>>>>> until we started using it.
>>>>> When the problem occurs for a user, he's still logged in to the
>>>>> application but all the features are disabled because he has no role (The
>>>>> assigned roles section in keycloak is empty).
>>>>>
>>>>> The logs I sent yesterday mention:
>>>>> DEBUG [org.keycloak.services.resources.IdentityBrokerService] (default
>>>>> task-1) Token will not be stored for identity provider [microsoft]
>>>>>
>>>>> which is logged in the method
>>>>> IdentityBrokerService.authenticated(BrokeredIdentityContext context)
>>>>>
>>>>> Going through that method, I found this piece of code:
>>>>>
>>>>> Set<IdentityProviderMapperModel> mappers = realmModel.getIdentityProviderMappersByAlias(context.getIdpConfig().getAlias());
>>>>> if (mappers != null) {
>>>>>     KeycloakSessionFactory sessionFactory = session.getKeycloakSessionFactory();
>>>>>     for (IdentityProviderMapperModel mapper : mappers) {
>>>>>         IdentityProviderMapper target = (IdentityProviderMapper)sessionFactory.getProviderFactory(IdentityProviderMapper.class, mapper.getIdentityProviderMapper());
>>>>>         target.preprocessFederatedIdentity(session, realmModel, mapper, context);
>>>>>     }
>>>>> }
>>>>>
>>>>> That's why I suspect that the mappers are not triggered.
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 20, 2019 at 8:11 AM Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Are you using a broker to authenticate your users ? Your setup is not
>>>>>> clear if that is the case, so I'm not sure if the method you pointed out is
>>>>>> related.
>>>>>>
>>>>>> Can you confirm that this scenario was working before?
>>>>>>
>>>>>> By losing roles, you mean they are not within the access token?
>>>>>>
>>>>>> Regards.
>>>>>> Pedro Igor
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Mar 19, 2019 at 9:16 AM MEHDi CHAABOUNi <
>>>>>> mehdi.chaabouni at gmail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> This is our Keycloak setup:
>>>>>>>
>>>>>>>    - Keycloak docker container 4.4.0.Final
>>>>>>>    - Azure Active Directory (mapping groups to roles)
>>>>>>>    - Keycloak client protocol: openid-connect
>>>>>>>    - 3 optional client scopes
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We noticed lately that users using the front-end application
>>>>>>> (angular) are
>>>>>>> losing all roles after the SSO idle session expires.
>>>>>>> This behaviour is also seen in the 4.8.3.Final version.
>>>>>>> It seems that the Identity Provider Mappers are not triggered for
>>>>>>> some
>>>>>>> reason and I can't dig any deeper nothing much is logged in the
>>>>>>> method
>>>>>>> IdentityBrokerService.authenticated(BrokeredIdentityContext context).
>>>>>>>
>>>>>>> Any ideas?
>>>>>>> How can I run Keycloak form source?
>>>>>>>
>>>>>> _______________________________________________
>>>>>>> keycloak-user mailing list
>>>>>>> keycloak-user at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>
>>>>>>


More information about the keycloak-user mailing list