<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 19 May 2016 at 14:48, Mitya <span dir="ltr"><<a href="mailto:mitya@cargosoft.ru" target="_blank">mitya@cargosoft.ru</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">Hi Stian, thanks for response!<br>
<span class=""><br>
> You don't strictly need to use model interface, JPA adapter, etc..<br>
> You can just make it a entity directly. We have those layers because<br>
> we support JPA and Mongo.<br>
<br>
</span>thx, got it<br>
<br>
(interestingly, many IDM developers end up implementing a JDO-like<br>
engine; this has also happened to PicketLink, they supported both JPA<br>
and LDAP with a single API)<br>
<span class=""><br>
> At the moment you can't add custom entities to the persistence.xml<br>
> without modifying it within the JAR, but we plan to introduce an<br>
> Entity SPI that allows adding custom entities (we have a PR for it,<br>
> it needs some work, but should be included in 2.0.0.CR1 due some time<br>
> in June).<br>
<br>
</span>Glad to hear about Entity SPI! I'll probably start with modified<br>
KeyCloak, and migrate to the SPI as soon as it's ready.<br></blockquote><div><br></div><div>You can give the PR a test if you'd like. It's in the list of PRs waiting to be merged.</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">
<span class=""><br>
> We have added support for custom REST resource, but not admin<br>
> resources. Main difference is how it's secured and URLs.<br>
<br>
</span>Could you please elaborate on "custom REST resources"? I couldn't find<br>
anything in the docs, there is only "21. Admin REST API". What are<br>
custom REST resources, how to implement them? Could they be helpful in<br>
my use case?<br></blockquote><div><br></div><div>It allows adding custom rest endpoints. No docs or examples yet, but you can take a look at <a href="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">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</a>. We use it for our testsuite.</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>
Cheers,<br>
Mitya<br>
<div class=""><div class="h5"><br>
> > You'd also need to modify the admin console, but that can be done<br>
> with a custom theme.<br>
> > > On 19 May 2016 at 12:36, Mitya <<a href="mailto:mitya@cargosoft.ru">mitya@cargosoft.ru</a>> wrote:<br>
> > Hi,<br>
> ><br>
> > My goal is to implement a custom first-class KeyCloak entity (like<br>
> > User, Group, etc.) Entities should persist in KeyCloak database<br>
> > along<br>
> > with Users, Groups etc.; there should be a CRUD interface in the<br>
> > admin<br>
> > console to manage them; it will have an unidirectional N:1<br>
> > relationship<br>
> > to User and will participate in authentication process. In some<br>
> > future,<br>
> > most likely it will also participate in federation (to/from<br>
> > external<br>
> > LDAP server with custom schema).<br>
> ><br>
> > After briefly studying KeyCloak internals, I've got an impression<br>
> > that<br>
> > Provider SPIs won't help me much. Seems like what I'll have to<br>
> > implement is at least:<br>
> ><br>
> > - model interface (org.keycloak.models)<br>
> > - entity class (org.keycloak.models.entities)<br>
> > - JPA adapter (org.keycloak.models.jpa)<br>
> > - JPA entity (org.keycloak.models.jpa.entities)<br>
> > - (the same for Mongo and Infinispan)<br>
> > - REST representation (org.keycloak.representations.idm)<br>
> > - REST resource (org.keycloak.services.resources.admin)<br>
> > <br>
> > Next, there will be custom authenticator (to make use of the<br>
> > entity)<br>
> > and GUI modifications. I hope I didn't forget anything?<br>
> ><br>
> > Important question is - can I implement all of that without<br>
> > modifying<br>
> > KeyCloak code? Maintaining a fork and producing customized builds<br>
> > will<br>
> > complicate development process a lot. Ideally, classes should<br>
> > reside in<br>
> > my own packages (not org.keycloak.*), the code should be packaged<br>
> > as a<br>
> > module (JBoss module? OSGi bundle?) and simply be plugged into an<br>
> > official KeyCloak build. I see forking only as a last resort, it's<br>
> > something I'd like to avoid absolutely.<br>
> ><br>
> > Thanks!<br>
> > Mitya<br>
> ><br>
> > _______________________________________________<br>
> > keycloak-dev mailing list<br>
> > <a href="mailto:keycloak-dev@lists.jboss.org">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>