<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 6 November 2015 at 14:29, Erik Mulder <span dir="ltr"><<a href="mailto:erik.mulder@docdatapayments.com" target="_blank">erik.mulder@docdatapayments.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>
<div>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. :-)<br>
<br>
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!<br>
<br>
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.</div></div></div></blockquote><div><br></div><div>We could use Hibernate directly to boostrap as long as it can return an EntityManager. Do you know if that's possible?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div><div><div><div class="h5"><br>
<br>
<br>
On 05/11/15 10:52, Stian Thorgersen wrote:<br>
</div></div></div>
</div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">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.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 4 November 2015 at 17:16, Erik
Mulder <span dir="ltr"><<a href="mailto:erik.mulder@docdatapayments.com" target="_blank">erik.mulder@docdatapayments.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Thanks
for your response!<br>
<br>
Indeed we already did a proof of concept where we added a
custom mapper<br>
the way you described (didn't know it was 'protected'
territory :). The<br>
question is: do we have to override the file<br>
'org.keycloak.protocol.ProtocolMapper' for this and add
the new mapper<br>
in the original project or is there another way where we
don't need to<br>
touch the original sources and keep all our changes in a
separate<br>
project? And how can we do it such that it stays easy to
upgrade to<br>
newer KeyCloak releases?<br>
</blockquote>
<div><br>
</div>
<div>Each jar has it's own
org.keycloak.protocol.ProtocolMapper. Take a look at the
docs (<a href="http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html" target="_blank">http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html</a>)
and examples for other provider (<a href="https://github.com/keycloak/keycloak/blob/master/examples/providers/event-listener-sysout/src/main/resources/META-INF/services/org.keycloak.events.EventListenerProviderFactory" target="_blank">https://github.com/keycloak/keycloak/blob/master/examples/providers/event-listener-sysout/src/main/resources/META-INF/services/org.keycloak.events.EventListenerProviderFactory</a>)</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
As for JPA: it would be easier to integrate with the
existing JPA<br>
project. Again we are wondering whether to start modifying
original<br>
sources (like persistence.xml) or try to 'externalize' our
changes<br>
somehow and integrate them using existing 'hooks' in the
system or maybe<br>
merge projects during build.<br>
<br>
Maybe there is no good answer to this and we'll always be
having some<br>
manual merge pains when upgrading to new KeyCloak
versions. We just<br>
wanted to check if there are preferred ways to add
functionality with<br>
the least amount of impact on the original sources.<br>
</blockquote>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div><br>
<br>
On 04/11/15 15:30, Bill Burke wrote:<br>
> Custom mappers should be possible. I didn't
document it as I wasn't<br>
> sure if we wanted to make the SPI public. Custom
mappers should just<br>
> follow the Provider SPI and they will be picked
up. If you see the<br>
> META-INF/services/... file in the resources
directory of the "services"<br>
> or "broker" modules you'll see how to set this
up.<br>
><br>
> As for extending the JPA datamodel, what you
could do is write a new JPA<br>
> Connections Provider and plug that in. See
connections/jpa. I'm not<br>
> sure how you would handle the liquibase db
migration.<br>
><br>
> On 11/4/2015 6:03 AM, Erik Mulder wrote:<br>
>> Hi everybody,<br>
>><br>
>> Quick intro: I’m part of a development team
in The Netherlands that is<br>
>> building a company-wide SSO solution. We’ve
chosen KeyCloak to realize<br>
>> this and will use OpenID Connect to secure
our REST services. It’s a<br>
>> great product and seems to be the only one
having both support for all<br>
>> kinds of security standards and a model and
GUI for users and roles.<br>
>> Thanks for creating it! J<br>
>><br>
>> (if this should be asked instead on the users
mailing list, please<br>
>> correct me and I’ll post it there)<br>
>><br>
>> So far, so good, but we have some extra
requirements that do not fit<br>
>> into the base KeyCloak data model. See below
for details if you’re<br>
>> interested. My question is: what is the
preferred way / best practice to<br>
>> extend the functionality of KeyCloak while
keeping the impact on the<br>
>> original sources to a minimum? Of course we
could just fork the most<br>
>> recent version and start hacking away, but
we’d like to be able to<br>
>> upgrade to newer versions of KeyCloak without
too much hassle.<br>
>> Possibilities that we’ve come up with so far:<br>
>><br>
>> 1.Create completely separate modules that
will extend the functionality<br>
>> the way we need.<br>
>><br>
>> 2.Fork on Github, apply custom changes, and
try to merge in updates from<br>
>> the master / release branches / tags<br>
>><br>
>> 3.Apply custom changes on KeyCloak artifacts
using a Maven plugin, such<br>
>> as Truezip<br>
>> (<a href="http://www.mojohaus.org/truezip/truezip-maven-plugin/index.html" rel="noreferrer" target="_blank">http://www.mojohaus.org/truezip/truezip-maven-plugin/index.html</a>)
-<br>
>> manipulate zip files by
adding/removing/replacing or Shade<br>
>> (<a href="http://maven.apache.org/plugins/maven-shade-plugin/" rel="noreferrer" target="_blank">http://maven.apache.org/plugins/maven-shade-plugin/</a>)
- combine multiple<br>
>> jars to 1 'uber-jar' containing the contents
of both and when<br>
>> overlapping decide on conflicts through
configuration.<br>
>><br>
>> Of course number 1 is preferred, but I do not
see how to add custom<br>
>> mappers or JPA entities without making
changes in the original module<br>
>> files. The other options seem like valid
alternatives, but maybe there<br>
>> is better / standard way to do this. So any
help / insight / shared<br>
>> experience on this is much appreciated,
thanks!<br>
>><br>
>> Kind regards,<br>
>><br>
>> Erik Mulder<br>
>><br>
>> Senior Software Engineer<br>
>><br>
>> Docdata Payments – NL<br>
>><br>
>> P.S. Details on why we want to extend the
KeyCloak data model: (any<br>
>> feedback on the contents of this P.S. is also
welcome!)<br>
>><br>
>> Our clients are merchants that have several
webshops. We manage their<br>
>> online payments (shopping cart checkout). We
want to be able to let a<br>
>> merchant manage their own users and let a
user have different roles for<br>
>> different webshops within the same merchant.
The overall possible roles<br>
>> are fixed though, no specific roles per
merchant. We could create a<br>
>> separate realm for every merchant, but then
we need to duplicate all<br>
>> roles every time. Furthermore, in KeyCloak
there is no concept of a role<br>
>> within a certain context. This is very
understandable, since every<br>
>> situation has it’s own requirements. We did a
proof of concept by adding<br>
>> tables and entities for Merchant,
UserMerchant, UserMerchantRole etc.<br>
>> and adding a custom mapper that can put this
information on the Access<br>
>> token. Worked like a charm! But it does need
some changes in the<br>
>> KeyCloak modules and sources to work, hence
the question above.<br>
>><br>
>><br>
>><br>
>>
_______________________________________________<br>
>> keycloak-dev mailing list<br>
>> <a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
>><br>
<br>
<br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>