[wildfly-dev] Keycloak SSO in WildFly 9

Darran Lofthouse darran.lofthouse at jboss.com
Wed Jun 4 03:37:01 EDT 2014


On 03/06/14 21:27, Bill Burke wrote:
> 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".

Yes that is something we have been discussing on the wildfly-elytron 
discussions, the concept that when a call crosses one container to the 
next we already have an authenticated identity what we need to be doing 
to re mapping the roles so that the role mapping is in the context of 
the second component.

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

As far as I am concerned this is just a side effect of JAAS, as I say 
above we will have the need for re analysing the role mapping on the 
crossing of containers so that each container sees the correct role 
mapping but not this re-authentication.

This in itself however is moving into the teritory of other design 
discussions we will be bringing to this list - I just wanted to confirm 
that we are moving away from this assumption of a principal and 
credential that gets authenticated on each container crossing.

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

In early AS7 discussions that was deemed insufficient due to privilege 
escalation of clients running on the same box, this is the whole reason 
the CLI has a local authentication mechanism to verify the user of the 
CLI actually has access to the AS installation.

>
>


More information about the wildfly-dev mailing list