[keycloak-dev] Implementing custom entities with KeyCloak

Stian Thorgersen sthorger at redhat.com
Thu May 19 09:01:25 EDT 2016


On 19 May 2016 at 14:48, Mitya <mitya at cargosoft.ru> wrote:

> Hi Stian, thanks for response!
>
> > You don't strictly need to use model interface, JPA adapter, etc..
> > You can just make it a entity directly. We have those layers because
> > we support JPA and Mongo.
>
> thx, got it
>
> (interestingly, many IDM developers end up implementing a JDO-like
> engine; this has also happened to PicketLink, they supported both JPA
> and LDAP with a single API)
>
> > At the moment you can't add custom entities to the persistence.xml
> > without modifying it within the JAR, but we plan to introduce an
> > Entity SPI that allows adding custom entities (we have a PR for it,
> > it needs some work, but should be included in 2.0.0.CR1 due some time
> > in June).
>
> Glad to hear about Entity SPI! I'll probably start with modified
> KeyCloak, and migrate to the SPI as soon as it's ready.
>

You can give the PR a test if you'd like. It's in the list of PRs waiting
to be merged.


>
> > We have added support for custom REST resource, but not admin
> > resources. Main difference is how it's secured and URLs.
>
> Could you please elaborate on "custom REST resources"? I couldn't find
> anything in the docs, there is only "21. Admin REST API". What are
> custom REST resources, how to implement them? Could they be helpful in
> my use case?
>

It allows adding custom rest endpoints. No docs or examples yet, but you
can take a look at
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/servers/auth-server/services/testsuite-providers/src/main/java/org/keycloak/testsuite/rest/TestingResourceProvider.java.
We use it for our testsuite.


>
> Cheers,
> Mitya
>
> > > You'd also need to modify the admin console, but that can be done
> > with a custom theme.
> > > > On 19 May 2016 at 12:36, Mitya <mitya at cargosoft.ru> wrote:
> > > Hi,
> > >
> > > My goal is to implement a custom first-class KeyCloak entity (like
> > > User, Group, etc.) Entities should persist in KeyCloak database
> > > along
> > > with Users, Groups etc.; there should be a CRUD interface in the
> > > admin
> > > console to manage them; it will have an unidirectional N:1
> > > relationship
> > > to User and will participate in authentication process. In some
> > > future,
> > > most likely it will also participate in federation (to/from
> > > external
> > > LDAP server with custom schema).
> > >
> > > After briefly studying KeyCloak internals, I've got an impression
> > > that
> > > Provider SPIs won't help me much. Seems like what I'll have to
> > > implement is at least:
> > >
> > > - model interface (org.keycloak.models)
> > > - entity class (org.keycloak.models.entities)
> > > - JPA adapter (org.keycloak.models.jpa)
> > > - JPA entity (org.keycloak.models.jpa.entities)
> > > - (the same for Mongo and Infinispan)
> > > - REST representation (org.keycloak.representations.idm)
> > > - REST resource (org.keycloak.services.resources.admin)
> > >
> > > Next, there will be custom authenticator (to make use of the
> > > entity)
> > > and GUI modifications. I hope I didn't forget anything?
> > >
> > > Important question is - can I implement all of that without
> > > modifying
> > > KeyCloak code? Maintaining a fork and producing customized builds
> > > will
> > > complicate development process a lot. Ideally, classes should
> > > reside in
> > > my own packages (not org.keycloak.*), the code should be packaged
> > > as a
> > > module (JBoss module? OSGi bundle?) and simply be plugged into an
> > > official KeyCloak build. I see forking only as a last resort, it's
> > > something I'd like to avoid absolutely.
> > >
> > > Thanks!
> > > Mitya
> > >
> > > _______________________________________________
> > > 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/20160519/0aa7814d/attachment-0001.html 


More information about the keycloak-dev mailing list