[keycloak-user] Integration with legacy systems

[Marcelo Nardelli]

Ok, I'll take look at that.

Thanks again, Marek!

Marcelo Nardelli

On Tue, Mar 14, 2017 at 4:53 AM, Marek Posolda <mposolda at redhat.com> wrote:

> 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>
> 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
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>>
>
>