Custom mappers should be possible. I didn't document it as I wasn't
sure if we wanted to make the SPI public. Custom mappers should just
follow the Provider SPI and they will be picked up. If you see the
META-INF/services/... file in the resources directory of the "services"
or "broker" modules you'll see how to set this up.
As for extending the JPA datamodel, what you could do is write a new JPA
Connections Provider and plug that in. See connections/jpa. I'm not
sure how you would handle the liquibase db migration.
On 11/4/2015 6:03 AM, Erik Mulder wrote:
Hi everybody,
Quick intro: I’m part of a development team in The Netherlands that is
building a company-wide SSO solution. We’ve chosen KeyCloak to realize
this and will use OpenID Connect to secure our REST services. It’s a
great product and seems to be the only one having both support for all
kinds of security standards and a model and GUI for users and roles.
Thanks for creating it! J
(if this should be asked instead on the users mailing list, please
correct me and I’ll post it there)
So far, so good, but we have some extra requirements that do not fit
into the base KeyCloak data model. See below for details if you’re
interested. My question is: what is the preferred way / best practice to
extend the functionality of KeyCloak while keeping the impact on the
original sources to a minimum? Of course we could just fork the most
recent version and start hacking away, but we’d like to be able to
upgrade to newer versions of KeyCloak without too much hassle.
Possibilities that we’ve come up with so far:
1.Create completely separate modules that will extend the functionality
the way we need.
2.Fork on Github, apply custom changes, and try to merge in updates from
the master / release branches / tags
3.Apply custom changes on KeyCloak artifacts using a Maven plugin, such
as Truezip
(
http://www.mojohaus.org/truezip/truezip-maven-plugin/index.html) -
manipulate zip files by adding/removing/replacing or Shade
(
http://maven.apache.org/plugins/maven-shade-plugin/) - combine multiple
jars to 1 'uber-jar' containing the contents of both and when
overlapping decide on conflicts through configuration.
Of course number 1 is preferred, but I do not see how to add custom
mappers or JPA entities without making changes in the original module
files. The other options seem like valid alternatives, but maybe there
is better / standard way to do this. So any help / insight / shared
experience on this is much appreciated, thanks!
Kind regards,
Erik Mulder
Senior Software Engineer
Docdata Payments – NL
P.S. Details on why we want to extend the KeyCloak data model: (any
feedback on the contents of this P.S. is also welcome!)
Our clients are merchants that have several webshops. We manage their
online payments (shopping cart checkout). We want to be able to let a
merchant manage their own users and let a user have different roles for
different webshops within the same merchant. The overall possible roles
are fixed though, no specific roles per merchant. We could create a
separate realm for every merchant, but then we need to duplicate all
roles every time. Furthermore, in KeyCloak there is no concept of a role
within a certain context. This is very understandable, since every
situation has it’s own requirements. We did a proof of concept by adding
tables and entities for Merchant, UserMerchant, UserMerchantRole etc.
and adding a custom mapper that can put this information on the Access
token. Worked like a charm! But it does need some changes in the
KeyCloak modules and sources to work, hence the question above.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev