thank you for your input. Storing additional SCIM attributes as key/value pairs in the
USER_ATTRIBUTE table has two drawbacks:
- Storing of multivalued complex attributes becomes difficult. E.g. the SCIM
phone number type has 4 attributes „value“, „display“, „type“ and „primary“ and each user
may have many phone number objects.
- Searching for users by attributes becomes difficult und maybe has a bad
performance because of the SQL.
Do you still think that’s the preferred way to go?
Von: Stian Thorgersen <sthorger(a)redhat.com>
Gesendet: Montag, 3. September 2018 12:21
An: Lösch, Sebastian <Sebastian.Loesch(a)governikus.de>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Betreff: Re: [keycloak-dev] SCIM v2 support
Adding additional attributes to user entity is probably not the way to go. Rather, it
would be better for backwards compatibility to simply use generic key/value attributes
which the user entity already has.
Implementing the SCIM endpoints is probably pretty straightforward. Most of the work will
probably be down to testing and documentation.
On Wed, 29 Aug 2018 at 13:28, Lösch, Sebastian
in a customer project we use keycloak and need a SCIM (System for
Cross-domain Identity Management) API.
Currently we write a wrapper API and a custom endpoint providing the SCIM
functionality. We wrote a extension of the UserEntity, UserModel and an
extension of the JpaUserProvider.
This strategy seems not ideal and the nicest way is to add this extensions
to Keycloak. This is already suggested in
Is anybody out there who can guide me, what coding would be necessary to
contribute the SCIM functionality?
Currently I think we have to:
- extend the UserEntity with all SCIM attributes. This will result
in additional tables/entities for complex attributes e.g. Address, Name,
- extend the UserModel to povide the additional attributes
- implement the new SCIM endpoint /Users
- make the additional attributes available via Admin REST API
- extend views to be able to edit SCIM user attributes using the
- All the above again for the Groups endpoint…
This also seem to be major changes. To big for one Pull Request. How do you
like to handle this?
keycloak-dev mailing list