[keycloak-dev] Preferred way to make KeyCloak custom changes
Erik Mulder
erik.mulder at docdatapayments.com
Wed Nov 4 06:03:59 EST 2015
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151104/fb7235a8/attachment.html
More information about the keycloak-dev
mailing list