[keycloak-user] Integration with legacy systems

Marek Posolda mposolda at redhat.com
Tue Mar 14 03:53:08 EDT 2017


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 at redhat.com 
> <mailto:mposolda at redhat.com>> 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 at lists.jboss.org
>         <mailto:keycloak-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>         <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>
>
>
>



More information about the keycloak-user mailing list