[wildfly-dev] Keycloak SSO in WildFly 9

[Bill Burke]

On 6/3/2014 2:25 PM, Darran Lofthouse 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.

Keycloak uses Resteasy.  We could write an adapter for whatever HTTP 
engine the mgmt interface is using.  Unfortunately, we also need a 
storage mechanism  JPA or Mongo.  We could write a file-based back-end 
if needed.


>> Questions for further discussion
>> --------------------------------------------
>> 1.  WildFly ships with pre-defined RBAC roles. [3]  Should these roles
>> be available at the realm level or only to the WildFly Web Console?
>> Could/should other consoles make use of these roles?
>
> The direction we are moving towards with the wildfly-elytron work is
> that role assignment / mapping is something that happens at the point a
> call reaches a secured resource and will be in the context of that
> secure resource.  As an example a user could call one deployment and be
> assigned one set of roles, that same user could call a different
> deployment and have a completely different set of roles - for simplicity
> we will allow a 1:1 mapping from what was loaded from the identity store
> to roles but that will not be always the case.

Keycloak works similarly, albeit with remote invocations.  Clients get a 
unique token with each application they do SSO with.  For nested 
invocations, i.e. If you log into Application A and it needs to invoke 
on Application B, things can be configured so that the token has all 
role mappings that are needed.  Each application in the nested call 
chain looks inside the token for the role mappings it is interested in.

If there was an adequate SPI, then Keycloak would fit in with this idea 
of each deployment call would have its own set of role mappings.


* Keycloak supports realm-level and per-app-level roles.

* Keycloak has the concept of scope mappings. Scopes are the roles the 
application is allowed to ask for.  So the token is only populated with 
permissions the application is allowed to ask for.  So, if a user has 
"admin" role, the token will not get populated with the "admin" role 
mapping unless the application has that scope.

* Keycloak has the concept of a "composite role".  Its kinda like a 
combination of a role group and a role.

BTW, I think cross-component calls need to be able to inherit the 
"identity store" from the calling component.   IMO, it would be very 
rare (even weird) if cross-component calls each used their own "identity 
store".

Currently, Its even more weird (and wrong) that each time you cross a 
component layer (deployment) reauthentication happens with the identity 
store.




>
>> 2.  On first login, you are required to change the admin password. What
>> other initial setup should be required?  Change realm public key?
>> Change client secret?  Others?
>
> This is something that would be required to happen at the command line,
> a connection from a web browser could not be trusted to perform this.
>

What if Keycloak out of the box only allowed connections from localhost? 
  That it would block all other incoming traffic and only allow 
connections from 127.0.0.1?  Admins would have to remove this restriction.


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