[wildfly-dev] Keycloak SSO in WildFly 9

Brian Stansberry brian.stansberry at redhat.com
Wed Jun 4 14:25:33 EDT 2014


On 6/4/14, 12:48 PM, Jason Greene wrote:
>
> On Jun 4, 2014, at 12:23 PM, Jason Greene <jason.greene at redhat.com> wrote:
>
>> There is of course ways to paper over this and shove them together but you end up with leaky abstractions. Like lets say the CLI could issue REST operations against Keycloak as well. Thats great but that means things like the compensating transaction model don’t let you mix management changes with keycloak changes.
>>
>> Another issue is that WildFly has some pretty strict backwards compatibility contracts with regards to management that stem from EAP. Keycloak, at this stage of the process might not want to put up with us requesting similar conservative governance. It might be better for us to limit the API dependencies to best enable the project to continue to evolve.
>
> Other problems I forgot to mention (oops sorry!)
>
> 1. Lifecycle robustness problems - Management is not supposed to affect applications, so if the user takes down or moves the DC it would take down application auth as well - Bad!
> 2. Chicken-egg problems in standalone mode - subsystems aren’t started when the server is in admin-only mode. (Although this one is solvable)

Subsystem services aren't started only because operation handlers by 
default don't do runtime stuff in admin-only mode. But a subsystem 
author could certainly have their handlers do stuff in admin-only if it 
was appropriate.

Your comment however makes me realize a flaw in how I'd been seeing 
this, where the Keycloak server could simply be an application running 
on one of the servers in the domain. But servers are under the control 
of an HC, and an HC in admin-only will not launch servers. So there's a 
chicken-egg issue there.

> 3. Lots of additional work.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat


More information about the wildfly-dev mailing list