[wildfly-dev] Keycloak SSO in WildFly 9

[Anil Saldhana]

On 06/03/2014 03:27 PM, Bill Burke wrote:
>
> 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.
PicketLink IDM default storage is file based. Any opportunity to map 
KeyCloak
storage to the IDM API?   Last time, Bill told me that he is not very 
happy with
the IDM API.


>
>
>>> 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.
>
>