This just sounds like a lot more work than necessary...I mean, how often
are group names going to change?
On 12/8/16 11:14 AM, Marek Posolda wrote:
The issue is, that single group can have more links to userStorage,
not just the single one. That's because single group can be mapped to
users from more different userStorages.
Example:
- I have 2 ldap userStorages (eg. ldap1, ldap2).
- I have group "mygroup" in Keycloak.
- I have user "ldap1-user" and I want him to join the group "mygroup"
. The group mapping will be saved in LDAP and the LDAP user will be
member of LDAP group like "cn=mygroup,dc=ldap1,dc=org"
- I have user "ldap2-user" and I want him to join the group "mygroup"
. The group mapping will be saved in LDAP and the LDAP user will be
member of LDAP group like "cn=mygroup,dc=ldap2,dc=org"
Note that I need this same Keycloak group in both my LDAPs. In first
LDAP, the group is represented by DN "cn=mygroup,dc=ldap1,dc=org", but
in second LDAP it is represented by path "cn=mygroup,dc=ldap2,dc=org" .
So the single properties federationLink+federationIdentifier is
definitely not sufficient. At least it will need to be a map of
federationLinks. But then you will need to have something additional
in the admin console UI to display those federationLinks. Considering
all of this, my vote is to rather stick with attributes.
Marek
On 08/12/16 16:46, Bruno Oliveira wrote:
>>> Should groups and roles instead have a federationLink (which points to
>>> > >the provider) and maybe also a federationIdentifier (which can
contain
>>> > >things like LDAP UUID) as first class properties? Then, you can
search
>>> > >for roles and groups based on those properties so you can
synchronize
>>> > >them.
> That would be fantastic.
>