[keycloak-user] LDAP Role Mapping after the "memberOf" style (Marek Posolda)

Thu Nov 5 07:42:47 EST 2015

Merk,

Please see my comments inline.

Giovanni

>
>Message: 2
>Date: Thu, 5 Nov 2015 09:39:21 +0100
>From: Marek Posolda <mposolda at redhat.com>
>Subject: Re: [keycloak-user] LDAP Role Mapping after the "memberOf"
>	style
>To: Giovanni Baruzzi <giovanni.baruzzi at syntlogo.de>,
>	"keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
>Message-ID: <563B15B9.8070207 at redhat.com>
>Content-Type: text/plain; charset="windows-1252"
>
>Hi,
>
>
>On 04/11/15 19:58, Giovanni Baruzzi wrote:
>> Dear all,
>>
>>
>> at the moment using the LDAP Identity federation we can map a role to
>> the membership to a group.
>>
>> We are using instead of the groupMembership the ?menberOf? approach,
>> dedicating an attribute to list the values of the roles owned by the
>>user.
>
>AFAIK memberOf is just read-only mirror of "member" attribute where
>"member" is writable and it's available on the group (roles) objects
>when memberOf is mirrored on users. At least it works this way on the
>Active Directory and some other LDAP servers too. Or doesn't it work on
>your LDAP server and you are not seeing "member" attribute on groups?

Yes the „memberOf“ is just the group membership seen from the point of
view of the user object.

We resorted to this technique for mainly two reasons:
1) Scalability: the LDAP groups technique gives acceptable results up to
80.000 members. After this threshold the insert times are growing
unacceptable
2) flexibility: sometime, to describe a Role, you need more than just a
name. For this reason we defined a custom attribute „syUserRole“
containing a case ignore string, structured as a name and a parameter. One
value of this attribute describe a role.

This very simple approach would allow us to scale the design to 1.000.000
users, our target, because with just one access to the user object you get
even all the needed roles.

Of course it would be nice to map those roles to the Keycloak roles.
I’m going to follow your suggestion to  implement a "custom
LDAPFederationMapper“.

I will keep you current.

Regards,
Giovanni

>
>Our RoleLDAPFederationMapper implementation is using "member" attribute
>approach because "member" attribute is writable and it's sufficient to
>achieve to all of CRUD user role mappings operations.
>
>At this moment, the only reason when I can see the advantage of
>"memberOf" is better performance in read-only LDAP servers as you need
>to query just user object to receive both it's attributes and role
>mappings in single step. Is this the reason why you want it or do you
>have other reason?

As said above this is one of the reasons, the other one is to have a
parameter.

>> How would you suggest the implementation of this requirement?
>> Can you imagine a way to implement it using the planned customised
>>filter?
>> Should we go for a custom federation provider?
>There are 2 steps to achieve it.
>
>1) You can use existing "User attribute" mapper to map "memberOf"
>attribute to some attribute in user model. This way the "memberOf" will
>be queried from LDAP and saved into Keycloak DB as part of the user
>record. You can check in admin console (tab "Attributes" of user) if the
>memberOf was successfully returned
>
>2) Then you may need to implement custom LDAPFederationMapper, which
>will return proxy user object and you override some methods of this
>proxy ( getRoleMappings , hasRole, maybe getRealmRoleMappings and
>getClientRoleMappings) to return the roles based on the "memberOf"
>attribute, which is available on UserModel thanks to previous step. See
>existing RoleLDAPFederationMapper for inspiration.
>
>So you don't need custom federation provider, but just custom federation
>mapper.
>
>I wonder if we should support "memberOf" in Keycloak OOTB. I am curious
>about your reasons to use it in prefer to "member" .
>
>Marek
>>
>> thank you for your answers,
>> Giovanni
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> 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/20151105/d84c32
>0b/attachment-0001.html
>
>------------------------------
>
>Message: 3
>Date: Thu, 5 Nov 2015 12:38:51 +0100
>From: Stian Thorgersen <sthorger at redhat.com>
>Subject: Re: [keycloak-user] Generate offline token
>To: Thomas Raehalme <thomas.raehalme at aitiofinland.com>
>Cc: keycloak-user <keycloak-user at lists.jboss.org>, P?l Orby
>	<orby at sendregning.no>
>Message-ID:
>	<CAJgngAdN=M+pgtB8WzqBHOKPtjvj_AJiHn4TSa4+bS4jNwrNCg at mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>On 3 November 2015 at 09:32, Thomas Raehalme <
>thomas.raehalme at aitiofinland.com> wrote:
>
>> On Tue, Nov 3, 2015 at 10:23 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> * Create service account for customers - they can then use this to
>>>obtain
>>> a token (offline or standard refresh) using REST endpoints on Keycloak
>>>
>>
>> Sorry to step in, but could you please explain the use case or the
>> reasoning for offline tokens on service accounts? If I have understood
>>it
>> correctly you'll still need clientId and secret to generate the access
>> token from the offline token. Why not just use them to login whenever
>> necessary? Thanks!
>>
>
>I wouldn't use offline tokens myself, but if you want to provide customers
>with a "token" rather than a service account it should be an offline
>token.
>Problem is that it'll be rather big, not just a short "api key".
>
>
>>
>> Best regards,
>> Thomas
>>
>>
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
>http://lists.jboss.org/pipermail/keycloak-user/attachments/20151105/4f2eec
>b2/attachment-0001.html
>
>------------------------------
>
>Message: 4
>Date: Thu, 5 Nov 2015 12:42:48 +0100
>From: Stian Thorgersen <sthorger at redhat.com>
>Subject: Re: [keycloak-user] Generate offline token
>To: P?l Orby <orby at sendregning.no>
>Cc: Thomas Raehalme <thomas.raehalme at aitiofinland.com>,	keycloak-user
>	<keycloak-user at lists.jboss.org>
>Message-ID:
>	<CAJgngAdRHHsXFkrAvPuT5H9voj=L+dmns9t0aSzt7M4oiusdfA at mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>On 3 November 2015 at 19:10, P?l Orby <orby at sendregning.no> wrote:
>
>> Ok, so after reading the replies here I understand that it isn't offline
>> tokens I'm looking for.
>>
>> The token I'm looking for is what I would call an "application token".
>>Any
>> plans implementing that?
>>
>
>No, we don't have any plans for that. However as I suggested you can
>relatively easily provide that yourself by creating a client with service
>account for a customer then create an offline token to send to them. Main
>issue still stands though is that an offline token is not just a short
>"API
>Key" it's a relatively big base64 string.
>
>If you want a short "API Key" you'd need a proxy in front of your services
>that can swap the key for the actual token.
>
>
>>
>> Example:
>> If you enable two factor authentication on Github, you can't connect
>>with
>> username/password anymore in terminal or other 3. party applications
>> integrated with GitHub without using an "application token" that you
>>create
>> on your GitHub account page.
>>
>> /P?l
>>
>> *P?l Orby*
>> UNIT4 Agresso AS
>> Programvareingeni?r
>> Tlf: 22 58 85 00
>> Mobil: 900 91 705
>>
>> SendRegning - Gj?r det enkelt!
>> http://www.sendregning.no
>> http://facebook.com/sendregning
>> http://twitter.com/sendregning
>> http://faktura.no
>>
>> 2015-11-03 13:49 GMT+01:00 Marek Posolda <mposolda at redhat.com>:
>>
>>> On 03/11/15 09:32, Thomas Raehalme wrote:
>>>
>>> On Tue, Nov 3, 2015 at 10:23 AM, Stian Thorgersen <
>>><sthorger at redhat.com>
>>> sthorger at redhat.com> wrote:
>>>
>>>> * Create service account for customers - they can then use this to
>>>> obtain a token (offline or standard refresh) using REST endpoints on
>>>> Keycloak
>>>>
>>>
>>> Sorry to step in, but could you please explain the use case or the
>>> reasoning for offline tokens on service accounts? If I have understood
>>>it
>>> correctly you'll still need clientId and secret to generate the access
>>> token from the offline token. Why not just use them to login whenever
>>> necessary? Thanks!
>>>
>>> We support offline tokens for service accounts because there is no
>>>reason
>>> (bad side effect) of not supporting it. Or at least I am not aware of
>>>any.
>>> Are you? Adding this support came "for free".
>>>
>>> One usecase when it can be useful is, for example if you have offline
>>> token and you don't know how was this offline token authenticated (if
>>>it
>>> was direct grant, service account or browser). You can send the refresh
>>> token request with this token regardless of the offline token type as
>>>the
>>> refreshToken endpoint is same for all cases.
>>>
>>> Marek
>>>
>>>
>>> Best regards,
>>> Thomas
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing
>>>listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinf
>>>o/keycloak-user
>>>
>>>
>>>
>>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
>http://lists.jboss.org/pipermail/keycloak-user/attachments/20151105/e47298
>d7/attachment.html
>
>------------------------------
>
>_______________________________________________
>keycloak-user mailing list
>keycloak-user at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>End of keycloak-user Digest, Vol 23, Issue 17
>*********************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5133 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20151105/7020613c/attachment.bin 