One problem with this approach is that you end up having a separate JDBC
connection and transaction even if it uses the same database the Keycloak
server uses.
Take a look at
https://github.com/keycloak/keycloak/tree/master/examples/providers/domai...
for example which allows adding custom entities to the main EntityManager.
On 6 August 2016 at 17:43, Bill Burke <bburke(a)redhat.com> wrote:
I've implemented a Keycloak provider deployer and it works great.
I
re-implemented the JPA User Storage SPI example. The provider is now a
@Stateful EJB and EntityManager access is all managed by
@PersistenceContext. The example now looks really simple and elegant
rather than the crap I mentioned before. Would not have worked without
the JTA integration I did (see previous email). Things left to do:
* hot deployment. Pretty sure I can implement this
* Make sure things work in WARs and EARs.
* Also thinking of defining a @KeycloakProvider annotation that you can
use on your ProviderFactories. This would remove the need to specify a
META-INF/services file and the annotation could be scanned for at
deployment. Would work like this:
@KeycloakProvider(UserStorageProviderFactory.class)
public class MyProvider ... {
}
As a side note, one thing I could look into is the ability to use
@Inject of a KeycloakSession. Developer could then write entire web
applications that are deployed separately and worked with the keycloak
API directly. @Inject KeycloakSession would work similarly to
@PersistenceContexts EntityManager. KeycloakSessions would be
associated with a transaction. This will give us nice integration with
Java EE and give a lot of power to developers wanting to extend keycloak.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev