[keycloak-dev] inter-realm trust model

Adam Young ayoung at redhat.com
Mon Dec 7 13:25:16 EST 2015


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 at redhat.com 
> <mailto:bburke at 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 at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151207/2ad76e5e/attachment.html 


More information about the keycloak-dev mailing list