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
<mailto:mposolda@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(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
<
https://lists.jboss.org/mailman/listinfo/keycloak-user>