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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev



_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev