Message: 2 Date: Thu, 5 Nov 2015 09:39:21 +0100 From: Marek Posolda <mposolda(a)redhat.com&gt; Subject: Re: [keycloak-user] LDAP Role Mapping after the "memberOf" style To: Giovanni Baruzzi <giovanni.baruzzi(a)syntlogo.de&gt;, &quot;keycloak-user(a)lists.jboss.org&quot; <keycloak-user(a)lists.jboss.org&gt; Message-ID: <563B15B9.8070207(a)redhat.com&gt; 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?

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?

> 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(a)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(a)redhat.com&gt; Subject: Re: [keycloak-user] Generate offline token To: Thomas Raehalme <thomas.raehalme(a)aitiofinland.com&gt; Cc: keycloak-user <keycloak-user(a)lists.jboss.org&gt;, P?l Orby <orby(a)sendregning.no&gt; Message-ID: <CAJgngAdN=M+pgtB8WzqBHOKPtjvj_AJiHn4TSa4+bS4jNwrNCg(a)mail.gmail.com&gt; Content-Type: text/plain; charset="utf-8" On 3 November 2015 at 09:32, Thomas Raehalme < thomas.raehalme(a)aitiofinland.com&gt; wrote: > On Tue, Nov 3, 2015 at 10:23 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; > 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(a)redhat.com&gt; Subject: Re: [keycloak-user] Generate offline token To: P?l Orby <orby(a)sendregning.no&gt; Cc: Thomas Raehalme <thomas.raehalme(a)aitiofinland.com&gt;, keycloak-user <keycloak-user(a)lists.jboss.org&gt; Message-ID: <CAJgngAdRHHsXFkrAvPuT5H9voj=L+dmns9t0aSzt7M4oiusdfA(a)mail.gmail.com&gt; Content-Type: text/plain; charset="utf-8" On 3 November 2015 at 19:10, P?l Orby <orby(a)sendregning.no&gt; 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(a)redhat.com&gt;: > >> On 03/11/15 09:32, Thomas Raehalme wrote: >> >> On Tue, Nov 3, 2015 at 10:23 AM, Stian Thorgersen < &gt;&gt;&lt;sthorger(a)redhat.com&gt; >> sthorger(a)redhat.com&gt; 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@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user End of keycloak-user Digest, Vol 23, Issue 17 *********************************************