9:57 a.m.
Hello,
With Keycloak 3.1.0 configured with a ldap as user storage provider, we had a problem
where when an attribute is modified the ldap directly, it is not immediately picked up by
keycloak (in account or administrative interface), even though the attribute in question
is marked as "Always Read Value From LDAP" in the mapper.
We tried changing the cache policy on the user federation configuration, or even with
"import" option off. But it seems the cache is global to keycloak (wildfly?).
There is 2 needs behind that question :
1) we have an attribute in ldap which governs if the user must change password. Our idea
was to check the attribute in a script based authenticator to add and user action if
found. Except, in our situation the new value was never read from ldap, we finally had a
solution by calling "user.getDelegateForUpdate();" before reading the attribute,
but I don't think it is the best way to do that.
2) We have some attribute changing independantly from keycloak, which could change some
access authorization for an user. So we need thos attribute picked up immediatly. Clearing
the realm cache seems to work, but it is far from a good solution.
Is there something we missed? What are the recommended ways to treat these cases?
Best regards,
Cédric Couralet
2:42 p.m.
Cache is global. No way around it except to invalidate the cache of the
specific user or all users for that storage provider. You can define a
cache policy per user storage provider. We've been meaning to add an
cache option to either evict on login or evict on logout. Even an option
to validate the cache. Guess we need it for this case.
On 6/29/17 9:57 AM, Couralet Cédric wrote:
Hello,
With Keycloak 3.1.0 configured with a ldap as user storage provider, we had a problem
where when an attribute is modified the ldap directly, it is not immediately picked up by
keycloak (in account or administrative interface), even though the attribute in question
is marked as "Always Read Value From LDAP" in the mapper.
We tried changing the cache policy on the user federation configuration, or even with
"import" option off. But it seems the cache is global to keycloak (wildfly?).
There is 2 needs behind that question :
1) we have an attribute in ldap which governs if the user must change password. Our
idea was to check the attribute in a script based authenticator to add and user action if
found. Except, in our situation the new value was never read from ldap, we finally had a
solution by calling "user.getDelegateForUpdate();" before reading the attribute,
but I don't think it is the best way to do that.
2) We have some attribute changing independantly from keycloak, which could change some
access authorization for an user. So we need thos attribute picked up immediatly. Clearing
the realm cache seems to work, but it is far from a good solution.
Is there something we missed? What are the recommended ways to treat these cases?
Best regards,
Cédric Couralet
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
2491
days inactive
2491
days old
1 comments
2 participants
participants (2)
-
Bill Burke -
Couralet Cédric