On 10/03/17 18:41, Marcelo Nardelli wrote: > Hello, > > We recently started using Keycloak in our organization but we are not sure > which approach would be best to use when there are some user permissions > that rely on information managed by other systems (legacy systems that we > have). > > In our specific case, we have the following setup: > > - A Keycloak server integrated with LDAP to retrieve users > - A Java backend protected by Bearer Token > - A Javascript frontend developed in EmberJS that accesses the Java > backend > > One of the requirements we have is the following: > > - Users who have a certain managerial position must have a common set of > permissions. > > To meet this requirement, we created a group, included the relevant users, > and assigned the appropriate permissions (roles) to the group. This works > fine for us. > > However, we have a legacy system that manages the positions that a user > assumes in the organization, so that a user who today holds a management > position may no longer have that position tomorrow in the legacy system. > When he loses the management position, someone needs to be warned and > manually remove the user from the Keycloak group. > > Ideally, we would like this process not to be so manual. Which approaches > would be recommended for this situation? > > - Make the legacy system somehow access Keycloak to remove users from the > group when needed > That should work. We have admin REST API, which can be used to remove user from some group. So if you can somehow notify that change in legacy system will invoke this REST API, you should be fine. > - Make our application query the legacy system to verify that the > permissions that are on the token are appropriate for the user's current > position > That can work too, but question here is performance. > - Change the keycloak in some way to query the legacy system and determine > based on this information whether the user should receive the permissions > That can finally work too. If your users are in LDAP and the information about group membership is in LDAP too, you can use our builtin LDAP Group mapper. Then will mean that Keycloak will be able to retrieve group memberships from LDAP. If this information is somewhere else, but still, your users are in LDAP, you can possibly implement new LDAP mapper, which will be able to query your 3rd party system. But note that we have caching for LDAP, so Keycloak may not be immediatelly aware of the change in legacy system. In shortcut, last solution is the best in case that your group membership can be retrieved from LDAP. Otherwise probably the first one as long as you can be automatically notified by your legacy system. Really depends on the details of your usecase which solution is best. Marek > > Thanks for the attention > > Marcelo Nardelli > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user >

On 13/03/17 15:49, Marcelo Nardelli wrote: Thanks for answering, Marek Are there any examples on how to implement a custom LDAP mapper? The information I need is not on LDAP, so the mapper would need to query the other system. If I can't make that work, I'll problably go with the option of trying to make the other system notify keycloak through the admin REST API. Nope. This is considered private SPI, so no example. You can take a look to the Keycloak codebase for the example how to implement LDAP mapper. For example class GroupLDAPStorageMapper. Marek Marcelo Nardelli On Mon, Mar 13, 2017 at 5:50 AM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > On 10/03/17 18:41, Marcelo Nardelli wrote: > >> Hello, >> >> We recently started using Keycloak in our organization but we are not >> sure >> which approach would be best to use when there are some user permissions >> that rely on information managed by other systems (legacy systems that we >> have). >> >> In our specific case, we have the following setup: >> >> - A Keycloak server integrated with LDAP to retrieve users >> - A Java backend protected by Bearer Token >> - A Javascript frontend developed in EmberJS that accesses the Java >> backend >> >> One of the requirements we have is the following: >> >> - Users who have a certain managerial position must have a common set of >> permissions. >> >> To meet this requirement, we created a group, included the relevant >> users, >> and assigned the appropriate permissions (roles) to the group. This works >> fine for us. >> >> However, we have a legacy system that manages the positions that a user >> assumes in the organization, so that a user who today holds a management >> position may no longer have that position tomorrow in the legacy system. >> When he loses the management position, someone needs to be warned and >> manually remove the user from the Keycloak group. >> >> Ideally, we would like this process not to be so manual. Which approaches >> would be recommended for this situation? >> >> - Make the legacy system somehow access Keycloak to remove users from the >> group when needed >> > That should work. We have admin REST API, which can be used to remove > user from some group. So if you can somehow notify that change in legacy > system will invoke this REST API, you should be fine. > >> - Make our application query the legacy system to verify that the >> permissions that are on the token are appropriate for the user's current >> position >> > That can work too, but question here is performance. > >> - Change the keycloak in some way to query the legacy system and >> determine >> based on this information whether the user should receive the permissions >> > That can finally work too. If your users are in LDAP and the information > about group membership is in LDAP too, you can use our builtin LDAP Group > mapper. Then will mean that Keycloak will be able to retrieve group > memberships from LDAP. If this information is somewhere else, but still, > your users are in LDAP, you can possibly implement new LDAP mapper, which > will be able to query your 3rd party system. But note that we have caching > for LDAP, so Keycloak may not be immediatelly aware of the change in legacy > system. > > In shortcut, last solution is the best in case that your group membership > can be retrieved from LDAP. Otherwise probably the first one as long as you > can be automatically notified by your legacy system. Really depends on the > details of your usecase which solution is best. > > Marek > >> >> Thanks for the attention >> >> Marcelo Nardelli >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > >