[keycloak-dev] Preferred way to make KeyCloak custom changes

[Bill Burke]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com