On 12/07/2015 02:43 AM, Stian Thorgersen wrote:
Added this comment to the previous thread, but copy/pasting here:
I was thinking a bit more about trust between realms and I think that
should be limited to authentication only. An admin with certain roles
in one realm shouldn't necessarily have the same roles in another
realm. So I think we need either a user that can exist in multiple
realms or utilize identity brokering to get "linked" users. I'm
worried if we allow roles from one realm to give admin permissions in
another it will be hard to get a full picture of who has access to the
realm. It may also give unintentional permissions. Also, if we
introduce admins that can only manage a "group" of users or roles that
specify what roles an admin can grant that would require users in the
specific realm to manage.
Again to use the Keystone comparison-other.
A Domain in OpenStack is the top level entity for ownership. Under
domains in *identity* you have \users and groups. Under domains in
"resource" you have projects. I think projects most map to Realms in
Keycloak.
A user is a resource to be managed by a domain. The fact that a
specific domain owns the user does not give the user any role assignment
in that domain; it is just ownership of the record.
All role assignments are on the "resource" side of Keystone. A user
gets a role assignment on a project or a domain.
Just about everything in Keystone has both a name and an id. For the
majority, these the IDs are UUIDs. An assignement is then a tuple:
actor_id, target_id, role_id.
Actor is either user or group.
Target is either project or domain.
Role is enforced by name, but assigned by ID.
I've been calling this "Scoped RBAC" to contrast it with NIST, where
role assignments are not scoped to some namespace.
The same would work for Keycloak: a Role is always assigned on a Realm,
never just a global role assignment.
What becomes important, then, is that the application, or whatever is
requesting the set of roels for a user, get the right set for the
scope. When I log in to Wordpress for Marketing I get a different set
of roles listed from when I log in to Wordpress for Engineering.
Now, I feel like Domains are bad extension, that we should have just
made projects hierarchical. Are Realms hierarchical in Keycloak?
On 4 December 2015 at 17:23, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
To establish trust between realms I was thinking about a simple table:
realm|trusted-realm|role
Here's some example records:
test-realm|master|manage-clients
test-realm|master|view-users
means
"test-realm" trusts the "master" realm, but they can only
"manage-clients" and "view-users"
The "role" column would just be the name of the realm, not an id and
would reference the "realm-management" client roles (which will be
moved
to security-admin-console client).
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev