<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 19 May 2016 at 20:44, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Stian,<br>
<br>
A follow-up on realm resources - I've stumbled upon this thread: <a href="http://lists.jboss.org/pipermail/keycloak-dev/2015-December/006100.html" rel="noreferrer" target="_blank">http://lists.jboss.org/pipermail/keycloak-dev/2015-December/006100.html</a><br>
<br>
That "(coming) ability to freely extend the JPA entities and DB schema" is the very same Entity SPI you were talking about, right?<br></blockquote><div><br></div><div>Yep</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I see now how to implement realm resources. It's a pity that custom<br>
admin resources (initially included into Pedro Igor's commit) were<br>
removed; these would be a fairly natural addition to the upcoming<br>
Entity SPI. Are there any plans to include that back?<br></blockquote><div><br></div><div>We plan to add it, but we'd like it to have some support for authorization, which the PR didn't provide. So there was basically no difference between the two in the original PR.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As a workaround, is it possible to install a custom realm resource<br>
(/realms/{realm}/foo), manually protect it with an authorization<br>
constraint, and use it inside admin console (as a surrogate admin<br>
resource)?<br></blockquote><div><br></div><div>Yes, that's fine. You can look at the source code for how we deal with authorization in the admin resources. Look at AdminRootResource I think it is.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Mitya<br>
<br>
P.S. BTW, examples/providers/rest/pom.xml contains an erroneous "<name>Authenticator Example</name>" inside<br>
<div class="HOEnZb"><div class="h5"><br>
> Hi Stian, thanks for response!<br>
><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<br>
> > because<br>
> > we support JPA and Mongo. <br>
><br>
> 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>
><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<br>
> > time<br>
> > in June).<br>
><br>
> 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>
><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>
> Could you please elaborate on "custom REST resources"? I couldn't<br>
> 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<br>
> in<br>
> my use case?<br>
><br>
> Cheers,<br>
> Mitya<br>
><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<br>
> > > (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,<br>
> > > 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>
> _______________________________________________<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>