[keycloak-dev] user groups vs. client groups

Sun Nov 22 22:50:41 EST 2015

We should have a Google Hangout or BlueJeans sometime:

before I get deeper, you'll have to explain more on what you mean that 
you wanted to avoid centralization of mapping SAML assertions.  I didn't 
get that part...

I think this is related to a lot of what you wrote, but resource 
permissions are going to be a separate, but integrated service to 
roles/users/groups.  Pedro is working on a permission service that 
allows you to have complex permission models.  There's some nice 
protocols out there that help manage this.

Most Java EE apps, simple permission stuff is handled by the 
applications themselves.  The security layer propagates identity and 
user/role mappings and the application decides which roles have 
permission to access which resource.  So, Keycloak core can focus on 
provide user/group/role/attribute authentication and information.  The 
service Pedro is working on will offer an optional, complimentary way to 
centrally manage permissions if you want to.  My on personal opinion is 
that most apps will want to manage resource permissions in their own 
special app-specific way and Pedro's stuff will be most useful as a 
backend-service.

As for our architecture, we have a common security domain model that all 
our core component work with.  This is a pluggable abstraction that is 
designed to sit on a pluggable datastore.  We currently have SQL and 
Mongo mappings sitting on top of our own datamodel.   We have a 
distributed, clustered cache sitting on top of our datamodel 
(Infinispan).  It uses an invalidation model to keep synching message 
size minimal and to avoid transmiting sensitive data.

For federation of external identity stores (i.e. LDAP) we offer a hybrid 
approach.  The idea is that we want Keycloaok to have a set of features 
that a user can leverage irregardless of whether the underlying external 
store can handle it or not.  This means that Keylocak might locally 
store additional security metadata that is not available in the LDAP 
store.  The SPI is a bit complex right now, but we're hoping to fix 
that.  It also requires some minimal import of data for each user 
(username/email).  We want to code that requirement out though in the 
future.

On 11/22/2015 9:13 PM, Adam Young wrote:
> Hey guys, just catching up on the discussion.  Let me share  some
> lessons learned from the Last four years on OpenStack Keystone working
> on a very similar problem.
>
> Keystone started off with three concepts: users, (global) roles and
> tenants.   A user was either an admin (based on a role) or assigned to a
> tenant.
>
> Tenants were groups of resources not managed by Keystone;  Virtual
> machines, disk images, and the like.  All access control was managed by
> the user having a token scoped to the project.
>
> Admin was a global role...but at some point, someone decided to make it
> scoped to a tenant.  And things go weird.  But it made sense: within a
> proejct, some resources were more sensitive than others, and needed an
> increased level of security.  But since all of the access control policy
> was written with global roles, things were actually just kind of
> broken.  It lead to one of the oldest bugs in Keystone, and it is still
> assigned to me.  I think we will have it licked this round...but that is
> jumping ahead.
>
> Keystone was written with a plugable backend approach.  THe default was
> Key Value stores (memcache was heavily used) but SQL was very dominant.
> However, we realized that, for users, we needed to be able to pull them
> out of LDAP, as most companies have large, embedded user databases, and
> they want to user them, not copy them.  So, projects in Openstack mapped
> to groups in LDAP, and users had assignments to groups.
>
> It was an uncomfortable fit.  Tenants really were OpenStack
> abstractions, and with them coming from LDAP...which was almost always
> read-only, they were not editable by OpenStack resources. This was a
> restriction that we dealt with for a while.
>
> A couple new abstractions found their way into Keystone:  groups (of
> users) and domains.  Domains were groupings for both users and tenants.
> And this has continued to haunt us, because it confused two things. The
> above situation with LDAP showed that the users needed to be separate
> from the tenants.
>
> Oh, and we also changed the name from  tenants to projects to keep
> consistent with the rest of OpenStack...want to piss off your users?
> Change a key term out from underneath them...
>
>
> It became clear the we needed to manage users and projects in different
> ways.  Users were read only from LDAP, projects were writable from
> OpenStack.  We split the backends along these lines: Identity manages
> users, groups, and user-to-group assignments.  This was due to the4
> expectation that the group information from LDAP was going to be
> required for managing users, which has proven to be of questionable
> worth.  The assignment backend held projects, roles, and role
> assignments.  Domains were in there as well, but it was an awkward fit,
> as domains really spanned both Identity and Assignment.
>
>
> We also changed how the  user to projects mapping was handled:  we use
> role assignments for everything.  Domain *owned* users, in that they
> were records under the domain object, but a user got no permissions due
> to being managed by a specific domain;  only via role assignments.
>
> Things really got funky when we fully integrated Federation in to
> Keystone.  Now, we had two abstractions for managing users:  Domains and
> Identity Providers. Instead of making a hard relationship between the
> two...we sort of let them float.
>
> The most hackish part is the Mapping. This is what takes the values from
> the federation assertion (SAML for the most part) and maps it to
> Keystone Identity objects (users and groups).  While we should limit
> what IdP can map to what domain,  we don't.  What this means is the
> managing the mapping must be done by an admin, and that is a
> cetrnalization I had hoped to avoid.
>
>
> What do end users really need?  They  need a reusable set of role
> assignments that span mulitple (micro)services.  We are almost there,
> and a few more iterations and we can get there.  Keystone handles only
> the core OpenStack services, but it would be much more useful if we
> could open it up to the cloud in general, and make it so people could
> use the Federation mapping defined in there to provide Access control to
> applications running in the cloud.
>
>
> Lessons learned:
>
> Scope roles to your target abstraction from the beginning.  Call this
> Scoped RBAC, as opposed to what NIST does.  NIST is implicitly scoped,
> make KeyCLoack be explicit.  Call it project, tenant, target,
> application, I don't care;  but a user should have a role on
> *something*, otherwise you end up with namespacing inside the role
> names, and a second level of mapping required.
>
>
> Provide rules that allow one to explicitly assign a single role, and the
> target user gets that explicit role and multiple implicit roles.   The
> end product is actually as set, not a tree, so just watch out for
> cycles.  It does not have to be a strict hierarchy, so long as it is a
> Directed Acyclic Graph, you are safe.
>
> Namespacing of roles is a client organization thing; it does not need to
> end up in the roles shipped to the end application, so long as you have
> a global definition of what roles mean what. Regardless, the namespace
> needs to disappear when sending the assertion, or the remote side can;t
> use it.  So, knowing "who" you are getting an assertion for is
> essential.  Two different Wordpress installs mean two different role
> assignments:  admin on one, editor on the other.
>
>
> You don't own the user database.  Assume it is going to be read only.
> Provide a local means to manage groups of users separate from, but on
> top of, the groups that come from the federated source of Identity.
>
>
>
> OK, that is a lot of a brain dump from someone you all don't even know.
> PLease ask me questions about the details.
>
>
> I'm pretty impressed with what I've seen of KeyCloak thus far. Looking
> forward to getting to know it better.
>
>
>
>
>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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