Looks cool. Will these annotations be defined in Keycloak or do we integrate with CDI? Marek On 06/08/16 17:43, Bill Burke 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

Hi, > 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. Sounds incredibly cool! From my practice I can say that applications often need to perform queries on an IdM layer; such queries can make an essential part of application's business logic (ex., "retrieve all the members of groups the current user is a member of"). For that, native KeyCloak API seems to be much more convenient than REST. But if I get it right, this will be limited to webapps deployed to the same WildFly instance. Do you think this approach could be nevertheless extended to webapps running in separate JVMs/appservers, or REST is the only option here?

Looking forward, as soon as JSR-375 is ready, do you think KeyCloak could adopt it?

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 18 August 2016 at 19:26, Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>> wrote: On 8/18/16 1:13 AM, Stian Thorgersen wrote: > 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. > Something we have to fix anyways. Its on my todo list. > Take a look at > https://github.com/keycloak/keycloak/tree/master/examples/providers/domai... > <https://github.com/keycloak/keycloak/tree/master/examples/providers/domai... > for example which allows adding custom entities to the main > EntityManager. > I'm really not a big fan of this extension and this is something I do not want to support for product ever. Why, please elaborate? IMO it's a really nice and simple way to add a few extra entities for custom providers.

On 19 August 2016 at 14:57, Bill Burke <bburke(a)redhat.com&gt; wrote: > > > On 8/19/16 2:34 AM, Stian Thorgersen wrote: > > > > On 18 August 2016 at 19:26, Bill Burke <bburke(a)redhat.com&gt; wrote: > >> >> >> On 8/18/16 1:13 AM, Stian Thorgersen wrote: >> >> 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. >> >> Something we have to fix anyways. Its on my todo list. >> > >> >> Take a look at https://github.com/keycloak/ke >> ycloak/tree/master/examples/providers/domain-extension/src/m >> ain/java/org/keycloak/examples/domainextension/jpa for example which >> allows adding custom entities to the main EntityManager. >> >> I'm really not a big fan of this extension and this is something I do >> not want to support for product ever. >> > > Why, please elaborate? IMO it's a really nice and simple way to add a few > extra entities for custom providers. > > Are you going to make our JPA entity classes public? If not, what's the > point of this extension? Now that we have real deployers, its now easier > to write your own persistence unit. Take a look at the example: > Has nothing to do with our entity classes. It allows users to easily register an extra entity in our persistence unit, so same connection and transaction and no need to create a persistence unit at all. It also has support for Liquibase so schema is update the same way as with our stuff. Users would then get the EntityManager from the JpaConnectionProvider and be able to get their custom entities from there. It's simpler than what you have. Doesn't work if folks want a different database and such though. > > https://github.com/keycloak/keycloak/tree/master/examples/pr > oviders/user-storage-jpa/src/main/java/org/keycloak/examples/storage/user > > Coding EJB and JPA is really easy, simple and fast. > For JEE devs yes. > > Also, with this extension, you have the possibility of customers being > dependent on our data model and the data model becomes something that needs > to be backward compatible. > Nah - because our entities is in a private module and they'll get a warning if they include that in their provider. > > Bill > >

On 8/19/16 9:04 AM, Stian Thorgersen wrote: > > > On 19 August 2016 at 14:57, Bill Burke <bburke(a)redhat.com > <mailto:bburke@redhat.com>> wrote: > > > > On 8/19/16 2:34 AM, Stian Thorgersen wrote: >> >> >> On 18 August 2016 at 19:26, Bill Burke <bburke(a)redhat.com >> <mailto:bburke@redhat.com>> wrote: >> >> >> >> On 8/18/16 1:13 AM, Stian Thorgersen wrote: >>> 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. >>> >> Something we have to fix anyways. Its on my todo list. >> >> >> >>> Take a look at >>> https://github.com/keycloak/keycloak/tree/master/examples/providers/domai... >>> <https://github.com/keycloak/keycloak/tree/master/examples/providers/domai... >>> for example which allows adding custom entities to the main >>> EntityManager. >>> >> I'm really not a big fan of this extension and this is >> something I do not want to support for product ever. >> >> >> Why, please elaborate? IMO it's a really nice and simple way to >> add a few extra entities for custom providers. > Are you going to make our JPA entity classes public? If not, > what's the point of this extension? Now that we have real > deployers, its now easier to write your own persistence unit. > Take a look at the example: > > > Has nothing to do with our entity classes. It allows users to easily > register an extra entity in our persistence unit, so same connection > and transaction and no need to create a persistence unit at all. It > also has support for Liquibase so schema is update the same way as > with our stuff. Users would then get the EntityManager from the > JpaConnectionProvider and be able to get their custom entities from > there. > > It's simpler than what you have. Doesn't work if folks want a > different database and such though. I disagree. Its not simpler than using standard EJB/JPA. @PersistenceContext EntityManager em; is simpler than EntityManager em = KeycloakSession.getProvider(JpaConnectionProvider.class);