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

Fri Nov 6 08:46:27 EST 2015

On 6 November 2015 at 14:29, Erik Mulder <erik.mulder at docdatapayments.com>
wrote:

> Thanks for pointing me explicitly to the SPI documentation. Of course that
> is exactly what I was looking for in my original question. I don't know how
> I overlooked this earlier! Probably I was not picking it up, because of
> almost a decade of developing on Spring projects, where this type of thing
> works differently. :-)
>
> I tried a quick test with a jar with one extra ProtocolMapper configured,
> put it in the providers folder and it worked like a charm!
>
> As for the JPA: We'll probably go with your suggestion of the separate
> EntityManagerFactory. Indeed there seems to be no way to 'programmatically
> extend' the list of entity classes in JPA besides editing or overwriting
> the persistence.xml. As you probably know it can be done in Hibernate, but
> I guess KeyCloak wants to stick to a generic JPA solution. That said, we
> might consider the Hibernate specific solution for our case, since being
> able to switch the JPA provider is not a requirement for us. And keeping
> the same connection/transaction is a lot easier in reasoning and debugging.
>

We could use Hibernate directly to boostrap as long as it can return an
EntityManager. Do you know if that's possible?

>
>
>
> On 05/11/15 10:52, Stian Thorgersen wrote:
>
> The way to extend Keycloak is by implementing your own custom providers of
> the many SPIs we provide. Some SPIs are more stable (so marked as public)
> and others are not (so marked as private). If there are things that you
> want to customize that can't be done with an existing SPI then let us know
> and we may consider adding additional SPIs.
>
> On 4 November 2015 at 17:16, Erik Mulder <erik.mulder at docdatapayments.com>
> wrote:
>
>> Thanks for your response!
>>
>> Indeed we already did a proof of concept where we added a custom mapper
>> the way you described (didn't know it was 'protected' territory :). The
>> question is: do we have to override the file
>> 'org.keycloak.protocol.ProtocolMapper' for this and add the new mapper
>> in the original project or is there another way where we don't need to
>> touch the original sources and keep all our changes in a separate
>> project? And how can we do it such that it stays easy to upgrade to
>> newer KeyCloak releases?
>>
>
> Each jar has it's own org.keycloak.protocol.ProtocolMapper. Take a look at
> the docs (
> http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html)
> and examples for other provider (
> https://github.com/keycloak/keycloak/blob/master/examples/providers/event-listener-sysout/src/main/resources/META-INF/services/org.keycloak.events.EventListenerProviderFactory
> )
>
>
>>
>> As for JPA: it would be easier to integrate with the existing JPA
>> project. Again we are wondering whether to start modifying original
>> sources (like persistence.xml) or try to 'externalize' our changes
>> somehow and integrate them using existing 'hooks' in the system or maybe
>> merge projects during build.
>>
>> Maybe there is no good answer to this and we'll always be having some
>> manual merge pains when upgrading to new KeyCloak versions. We just
>> wanted to check if there are preferred ways to add functionality with
>> the least amount of impact on the original sources.
>>
>
> I initially wanted the ability to add custom entities to the
> JpaConnectProvider, but couldn't find a way to define entities
> programatically with JPA. To add your own persistence.xml you would have to
> define your own implementation of JpaConnectionProvider and change what is
> loaded by default (connectionsJpa/provider attribute in
> keycloak-server.json).
>
> Alternative, which is cleaner, but you end up with separate
> connection/transaction, is to create your own EntityManagerFactory. If it's
> only used by one provider (for example a custom UserFederationProvider)
> there's no need to add a connect provider (that's just a way to share one
> EntityManagerFactory between multiple providers) and you can just create it
> in the MyUserFederationProviderFactory.
>
>
>>
>>
>> On 04/11/15 15:30, Bill Burke wrote:
>> > 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
>> >>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151106/07bd8dad/attachment-0001.html 