[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