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

[Pedro Igor Silva]

Btw, I've already worked on a SPI to plug custom endpoints to both Admin and Realm API. I'm still holding a PR with these changes, but if you need it I can send them. Just to avoid re-work :)

----- Original Message -----
From: "Stian Thorgersen" <sthorger at redhat.com>
To: "Erik Mulder" <erik.mulder at docdatapayments.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Thursday, November 5, 2015 7:52:13 AM
Subject: Re: [keycloak-dev] Preferred way to make KeyCloak custom changes

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 


_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev