6:04 a.m.
Hiya
One of our projects is looking to tie Knox and Keycloak together; with some
documentation here
https://community.hortonworks.com/articles/196751/knox-accept-third-party....
At the moment the users are being federated to an ldap user store.
The issue at the moment is the subject ID, they would like this mapped
'uid' attribute to the user representation in ldap, is this simply a matter
of changing the 'UUID LDAP attribute' .. They did try and they started
getting errors logging in, I'm guessing this was perhaps due to changing
the mapping once users had already been imported? ...
Alas, I don't have access to components myself, so acting as a middle man
at the moment
Rohith
7:08 a.m.
It appears I can map the sub claim to a user property i.e email ... But not
a user attribute ... I was hoping to just add a uid to the user and manage
like that assuming we can't get ldap mapping correctly
On Wed, Jun 20, 2018, 12:04 PM gambol <gambol99(a)gmail.com> wrote:
Hiya
One of our projects is looking to tie Knox and Keycloak together; with
some documentation here
https://community.hortonworks.com/articles/196751/knox-accept-third-party....
At the moment the users are being federated to an ldap user store.
The issue at the moment is the subject ID, they would like this mapped
'uid' attribute to the user representation in ldap, is this simply a matter
of changing the 'UUID LDAP attribute' .. They did try and they started
getting errors logging in, I'm guessing this was perhaps due to changing
the mapping once users had already been imported? ...
Alas, I don't have access to components myself, so acting as a middle man
at the moment
Rohith
7:30 a.m.
On 20/06/18 13:04, gambol wrote:
Hiya
One of our projects is looking to tie Knox and Keycloak together; with some
documentation here
https://community.hortonworks.com/articles/196751/knox-accept-third-party....
At the moment the users are being federated to an ldap user store.
The issue at the moment is the subject ID, they would like this mapped
'uid' attribute to the user representation in ldap, is this simply a matter
of changing the 'UUID LDAP attribute' .. They did try and they started
getting errors logging in, I'm guessing this was perhaps due to changing
the mapping once users had already been imported? ...
Yes, exactly. I think it
should be fine to configure "UUID LDAP
Attribute" to the value "uid" , but if you already have some users
imported from LDAP and then you change configuration later, strange
things can happen. It seems we should document this limitation a bit more...
One thing why "UUID LDAP Attribute" is not "uid" by default is, that
"uid" can't be guaranteed to be 100% unique and it can happen that it's
different user in some cases. For example scenario like:
- User john is in LDAP "uid=john,dc=example,dc=com"
- User john was unregistered from app and hence deleted from the LDAP
- After some time, there is another user "john", who wants to register.
He will be registered in LDAP with same uid like previous user. So
"uid=john,dc=example,dc=com" . At this point, Keycloak won't be able to
differentiate that 1st john and 2nd john is different user in case that
"UUID LDAP Attribute" is mapped to "uid" .
If you're fine with this limitation, it should be ok
Marek
Alas, I don't have access to components myself, so acting as a middle man
at the moment
Rohith
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2376
days inactive
2377
days old
2 comments
2 participants
participants (2)
-
gambol -
Marek Posolda