[keycloak-dev] new provider deployer working on branch!

[Bill Burke]

On 8/10/16 5:14 PM, Dmitry Telegin wrote:
> 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?
>
Will only be able to deploy extensions on the servers Keycloak runs on.  
Otherwise, REST API would have to be used

For very good reason, we are dependent on Wildfly/JBoss for JTA, 
deployers, management, clustering, caching, etc.  It is just way too 
much effort to make all that infrastructure pluggable.  So no way we 
could provide extensions within a separate JVM or vendor app server.  We 
could eventually allow the Keycloak subsystem to turn off various 
services, but this subsystem would need to run in the same cluster as 
the SSO server or you could easily end up with stale caches.
> Looking forward, as soon as JSR-375 is ready, do you think KeyCloak 
> could adopt it?
>
Just taking a quick look, I would say not for a very long time.  Its 
unclear to me what it is.  Is it a JASPIC redo?  Or a role-your-own 
IDP?  For the former, EE 8 won't be widely available for years, so whats 
the point?  JASPIC sucks and is implemented different on every 
platform.  As for the former, that is just not a viable direction for 
any spec to go as every "identity store" has its own peculiarities.  
What you need is a well defined model and you integrate with that well 
defined model.  Something too generic is useless.

Bill