[keycloak-user] retrieving group membership info from LDAP/AD

Marek Posolda mposolda at redhat.com
Wed Jan 13 17:07:07 EST 2016


On 08/01/16 15:02, Mahantesh Prasad Katti wrote:
>
> Thanks Marek. I looked at the built in example. I am looking for a 
> couple of details.
>
> 1.What is the bind password for the embedded apache ds?
>
secret

See the property bindCredential in ldaprealm.json document
>
> 2.I had a quick look at the ldaprealm.json document. It turned out 
> that group name and the realm role name are identical. Is that a 
> requirement for role-group mapping to work in keycloak?
>
ATM yes. You may need to override RoleLDAPFederationMapper if you have 
more fancy requirements around this.
>
> 3.Also, is role to group mapping always one to one? In our 
> application, one role is invariably mapped to multiple ldap groups.
>
I think you can create multiple Role LDAP federation mappers for your 
federation provider. For example you can create mapper for 2 group trees 
"ou=roles1,dc=example,dc=com" and "ou=roles2,dc=example,dc=com" . In 
that case, if you create keycloak realm role "foo", it will be saved 
into LDAP into both "cn=foo,ou=roles1,dc=example,dc=com" and 
"cn=foo,ou=roles2,dc=example,dc=com" . If you assign some user into the 
"foo" role in Keycloak, he will be always added as member into both LDAP 
groups. The role mappings in Keycloak should be union of both LDAP 
groups. For example if user "john" is declared as member in any of 
"cn=foo,ou=roles1,dc=example,dc=com" or 
"cn=foo,ou=roles2,dc=example,dc=com", he will be member of this role in 
Keycloak.

Marek
>
> Regards,
>
> Prasad
>
> *From:*Marek Posolda [mailto:mposolda at redhat.com]
> *Sent:* Monday, January 04, 2016 3:17 PM
> *To:* Mahantesh Prasad Katti; keycloak-user at lists.jboss.org
> *Subject:* Re: [keycloak-user] retrieving group membership info from 
> LDAP/AD
>
> On 30/12/15 18:42, Mahantesh Prasad Katti wrote:
>
>     Hi All,
>
>     In our application, we integrate with Microsoft AD for
>     authenticating users. As part of the authentication result, we
>     also fetch group information for the user authenticated. We also
>     have a pre-defined group-role mapping defined in the application
>     server [This is a JEE configuration file]. This helps decide
>     whether a particular user based on the role he belongs to can
>     access a resource or not. I read another thread “Apply group
>     membership filter on ldap login
>     <http://lists.jboss.org/pipermail/keycloak-user/2015-December/003982.html>”
>     on similar lines. Couple of clarifications.
>
>     1.Based on what I read there is no feature to get roles and map
>     them to specific roles in keycloak and would be available in a
>     future release. I just wanted to understand if my reading of this
>     is on the right lines. Also, wanted to know if there’s a
>     workaround for this in the short term.
>
> The feature to get LDAP roles and map them to specific roles in 
> Keycloak is available. We have LDAP Role Mapper (See documentation 
> http://keycloak.github.io/docs/userguide/keycloak-server/html/user_federation.html#ldap_mappers 
> and our ldap example for details).
>
> The thread "Apply group membership filter on ldap login" is more about 
> restricting that some LDAP users are not able to login at all (For 
> example, specify that just users, which are members of LDAP group 
> "cn=mygroup,o=myorg,dc=example,dc=com" are able to login and all the 
> other users are filtered). This will be available from 1.8 release 
> (it's in master already).
>
> 2.Also does keycloak provide fine grained access control on the lines 
> of apache shiro?
>
> Keycloak provides SSO and authentication. Once you authenticate, your 
> application will receive access token with the roles of user from 
> Keycloak (We have stuff like scope, protocol mappers etc, which allows 
> better control under what exactly will go to access token. See docs 
> and examples for details).
>
> Then it's up to the application how it interprets roles from 
> accessToken . The authorization needs to be actually done by 
> application itself (unless it's JEE application where we have mapping 
> of accessToken roles to JEE roles. Again see examples). We have 
> separate subproject  under development (no official release yet 
> available), which will allow more authorization possibilities.
>
> Marek
>
>
>
> Thanks
>
> Prasad
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160113/26b4492c/attachment-0001.html 


More information about the keycloak-user mailing list