[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