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. 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).

We have added support for custom REST resource, but not admin resources. Main difference is how it's secured and URLs.

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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev