[wildfly-dev] Keycloak SSO in WildFly 9

[Bill Burke]

On 6/4/2014 1:23 PM, Jason Greene wrote:
>
> On Jun 3, 2014, at 1:25 PM, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
>
>>> Both the auth server and admin console are served from the same WAR.  It
>>> should be possible to deploy this without using a WAR or servlets, but
>>> that is not planned for the initial WildFly integration.  Because of
>>> this current limitation, the auth server and admin console will not be
>>> present in a domain controller.
>>
>> This is going against the current design of AS7/WildFly exposing
>> management related operations over the management interface and leaving
>> the web container to be purely about a users deployments.
>
> Sorry for my delayed reply. I hadn’t had a chance to read the full thread.
>
> My understanding of the original and still current goal of key cloak is to be more of an appliance, and also largely independent of WildFly.
>
>  From that perspective, I don’t think embedding Keycloak solely to be in the same VM makes a lot of sense (more details as to why follow). It’s fine to have KeyCloak running on a WildFly instance (either as a subsystem or a deployment), but to me this seems to be a bit more of a black box to the user.
>
> So a typical topology, based on the factors I am aware of would look like this:
>
>                                                       
>                                                       
>                +------+     Auth       +----------+   
>                |      +---------------->          |   
>                |  DC  |                | Keycloak |   
>           +----+      +----+           |          |   
>           |    +------+    |           +----------+   
>           |                |                          
>       +---v--+          +--v---+                      
>       |      |          |      |                      
>       |  HC  |          |  HC  |                      
>     +-+      +-+      +-+      +-+                    
>     | +--+---+ |      | +--+---+ |                    
>     |    |     |      |    |     |                    
>    +v-+ +v-+ +-v+    +v-+ +v-+ +-v+                   
>    |S1| |S2| |S3|    |S4| |S5| |S6|                   
>    +--+ +--+ +--+    +--+ +--+ +--+                   
>                                                       
>
> Each box represents a different JVM running potentially on separate hardware.
>
> So from the architecture the key element we need is for the DC (and standalone server) to come pre bundled with a client that can talk to the Keycloak blackbox (whether it be WildFly or fat jar or whatever). I assume this mostly amounts to OAUTH communication.
>
> Now as to why I don’t think embedding as it is makes a lot of sense, is because it wouldn’t really be a tightly integrated component, but rather two distinct systems duct taped together. We would have:
>
> 1. Multiple distinct management consoles
> 2. Multiple distinct management APIs
> 3. Multiple distinct management protocols
> 4. Multiple distinct CLI/tools
>
> 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.
>

Jason,

I think we should first get Keycloak to secure Wildfly in standalone 
mode or with a domain controller.  In both cases the Wildfly console 
should be securable by Keycloak.  I'm betting that a lot of these issues 
will flesh out and become much clearer on how to solve.

Irregardless of the Wildfly team vetoing the inclusion of keycloak, it 
is a very important use case for us to be able to be embbeded and to 
secure Wildfly and to manage security for Wildfly.

We have already learned a lot by being embedded with Aerogear UPS as 
their security console and solution.  For example, keycloak now has 
pluggable themes/skins themes/skins for its entire UI: admin console, 
login pages, etc.  This has allowed Keycloak to be branded as an 
Aerogear subsystem and it looks like one product.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com