[keycloak-user] Exporting a realm as JSON file should not contain user groups?
mposolda at redhat.com
Wed Mar 2 09:02:11 EST 2016
On 02/03/16 13:48, Stian Thorgersen wrote:
> As it stands Keycloak syncs this to its own database and as the export
> is a dump of the database it wouldn't work to remove it. In the future
> we are planning on providing an option to use LDAP without syncing to
> the Keycloak database. It'll be a while to we get to it though.
> With regards to the deletion of groups synced from LDAP I'm not sure
> how we do that for roles either, I believe the roles remain as well.
> Maybe Marek can comment on this?
Yeah, both groups and roles currently remain. You can create JIRA to
request removing them, however not sure when it will be done. Currently
there are some limitations like:
* We don't have any proper federation SPI for roles or groups. So we
just create roles/groups from LDAP but we don't track which roles/groups
belong to LDAP. This would require adding some attribute like
"federationLink" to both roles and groups. Or at least some generic
attribute (accessible via setAttribute/getAttribute - but this won't
work for roles as RoleModel don't have attributes ATM)
* There is no easy way to track roles/groups removed from LDAP. It may
require query all groups from Keycloak DB and doublecheck if particular
group still exists in LDAP. Similarly during sync of users, we don't
currently remove users, which were removed from LDAP in the meantime
(User is deleted later once it's queried by Keycloak). There is easy and
generic way to send query to LDAP like "Return all users (groups,roles)
created or modified since 2015-02-15 10:00:00" but there is no query to
track removed objects. Some LDAP servers support changelogs though, but
this is vendor specific AFAIK
* Finally there are various other corner cases, so automatically
deleting synced roles/groups is maybe not a good idea anyway. Will
require to be configurable IMO
Btv. If you quickly want removing groups, you can create subclass of
GroupLDAPFederationMapper and override method
"syncDataFromFederationProviderToKeycloak()" . You don't need to deal
with corner cases as you can do it in best way according to requirements
of your deployment.
> On 2 March 2016 at 13:33, Edgar Vonk - Info.nl <Edgar at info.nl
> <mailto:Edgar at info.nl>> wrote:
> Hi Stian,
> I understand. And typically this would indeed by what you want.
> However in our specific case groups are not part of our realm data
> as such but belong to our run-time data and are managed in exactly
> the same way as our users, role mappings and group mappings. But I
> guess you cannot cater for all needs so it’s ok.
> Another, probably related thing, is that with the LDAP group
> synching (using the user federation group mapper) groups synched
> from LDAP to Keycloak are never removed from Keycloak. When a
> group is deleted from LDAP and the sync is done again the group
> remains in Keycloak. Not what you want but I guess the issue is
> that Keycloak cannot make the distinction between a group synched
> from LDAP versus a group created from Keycloak itself? The LDAP
> group mapping is set up quite different from the user synching of
>> On 02 Mar 2016, at 13:25, Stian Thorgersen <sthorger at redhat.com
>> <mailto:sthorger at redhat.com>> wrote:
>> Roles and groups should be exported to the realm export, while
>> role mappings and group mappings should be exported to the user
>> On 2 March 2016 at 13:15, Edgar Vonk - Info.nl <http://info.nl>
>> <Edgar at info.nl <mailto:Edgar at info.nl>> wrote:
>> We notice that when we export our custom realm to a JSON file
>> (to a directory) that this file also contains all User
>> Groups. We do not want this as we synchronise these User
>> Groups from AD/LDAP just like our users. We want to have
>> realm configuration in the realm JSON file only and not any
>> ‘run-time’ managed data such as users and user groups.
>> Currently only users are exported to a different JSON file
>> but groups are not. Does it make sense to create a feature
>> request to also export user groups separately?
>> We have hundreds of groups in AD/LDAP which we sync to
>> Keycloak so we really do not want these in the realm JSON.
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the keycloak-user