[keycloak-dev] inter-realm trust model

[Bill Burke]

On 12/7/2015 1:25 PM, Adam Young wrote:
> 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?
>
>

The realm in Keycloak is the top-level construct.  Realms are completely 
isolated from one another.  Realms contain users, roles, groups and 
applications/clients.  Each realm can have a theme that describes the 
css templates/screens, etc. for login, account management, even the 
admin console.  Each realm decides on its flows for authentication, 
registration, credential reset, etc.  For the realm you can state how 
the user logs in, username?  password?  otp? terms and conditions?  This 
is the login flow.  So, all that stuff makes up a realm.

Each realm has a set of admin roles which are really different 
permissions for managing the roles (view users, edit users, edit 
clients, etc..).  We also currently have the concept of a master realm. 
  Admins in the master realm can manage other realms configured on the 
server.  Because we never created the separate concept of a namespace 
for roles, clients were used to hack in the concept of a namespace for 
admin roles.  So the master realm has all these "clients" that are 
really nothing more than role namespaces

Right now, Keycloak does not have the concept of permissions and 
resources.  It is up to each individual client/application what 
permissions a particular role has.

The original idea was that each application has their own set of roles 
that have their own meaning in that context.  An "admin" in one app may 
mean something totally different than "admin" in another.  So, what we 
hoped to get to is that in JBoss somebody would click on a button to 
secure an existing WAR via Keycloak, enter in some admin credential, and 
the role metdata in the WAR would automatically be uploaded to keycloak, 
registered and the appropriate config would be saved at the JBoss side. 
  Admins would then assign application roles as appropriate to each user 
or group.

With pedro's permission stuff the idea is to be able to define a 
permission model for resources, where resource could be anything:  a 
url, a machine, etc.  But right now Keycloak just manages users, groups, 
and roles and role mappings for each of those things.

Hope that makes sense.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com