3:27 p.m.
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