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! :)
(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.