Replies: 1 comment 5 replies
-
|
Before answering, let me state a few general considerations for IDs. The answer would then follow.
Since the human-readable DN with clientId does not satisfy the Item 3, I don't think it could be treated as ID. However it seems that it would be possible still to use human readable DN as long as the ID was the GUID. Does it sound viable to you? |
Beta Was this translation helpful? Give feedback.
5 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Problem statement
When retrieving client roles from a store, the query contains the client ID that is a UUID.
There is also the clientID (like "account" or "account-console"), but that is not available to create for example a LDAP DN.
The UUID is not very human friendly. The good thing: the ID doesn't change even when the clientId changes.
DN with UUID: ou=e44b2d1c-9b00-4f22-a8c1-d0aa1c48d7fb,dc=keycloak,dc=org
DN with clientID: ou=account,dc=keycloak,dc=org
Approach
Could the LDAP store use the client ID UUID to look up a client to retrieve additional information to then query
Benefits
API of map storage can stay the same.
Alternatives
Beta Was this translation helpful? Give feedback.
All reactions