I think it is true that an organization is kind of a special case of a Œgroup¹. We had specific requirements for the concept of what amounted to a single group just to bind a few shared attributes between related relying parties (clients). We decided to deliberately push a group concept for Œlater¹ because there are a bunch of complicating factors with groups. One is that groups are often defined in people¹s IdPs (esp. with Active Directory), and the policy for mapping or merging those defs dragged in more complexity than we wanted to do right away. Another is that groups often want to be nested and that¹s again more complexity than we were willing to bite off for so simple a function as an org. To answer your specific question about the specific common set of attributes - if I¹m following your question, we reluctantly call this ¹schema¹ in that it¹s a known, predefined set of attribute keys which can have arbitrary values (and that new attribute keys are not normally added by userland code). We have expectation that defining attributes as enforceable ³schema" (including validation for values) is a feature that will be required for orgs and users but our first cut doesn¹t go that far. So I think that while organizations *could* be implemented as a group with special constraints, it would stretch the abstraction a little too far. Normally, I¹m a Œturtles-all-the-way-down¹ kind of guy, but in this case, I think that org (or tenants) is a valuable concept to exist separate from the idea of a group. In fact, it might come down to an implementation style - from the API/UX perspective, presentation of Œorgs¹ might just be sugar on top of more general graph-style group implementation. On 7/30/15, 3:28 PM, "Bill Burke" <bburke(a)redhat.com&gt; wrote:

Comments below... One of the main attractions for doing federation for us was to help move away from the definition of groups inside AD which is a common occurrence in the world -- even though it doesn't belong in AD in a brokered or federated model. Our main concern was about reconciliation and propagation of IdP-defined groups into a federated model. If people have already defined groups such that the claims returned contained group definitions, then the broker would have to introduce more mapping to make sure all the groups expressed properly in the final claimset. This isn't particularly difficult, but supporting it was going to drag in more code than we wanted to write just to support an entity where we could hang some shared attributes. Engineery heh, yes. I think the implementation probably doesn't require a separate model (group vs. organization), and it's probably enough just to use 'group' as opposed to 'composite' - an org is would be just another group with a tag to enable 'organization' semantics, whatever that works out to be. Could be rendered in the UI slightly differently, but, under the hood, it's groups. Here's a possible summary: Groups: * have names * can contain other groups * can carry a 'schema' which represent available attributes (more generally, claims) * support mapping and aggregation from IdP-defined groups * can be assigned roles So user in a group gets that group's attributes, role associations, sub-group's role associations, sub-group's attributes. A client in a Dell 'org' is just a client which would receive attributes defined at the org level. The motivation was to support two (or n) cooperating SaaS applications, each with their own tenancy model. For example: App A creates a 'tenant/custoemr' in its own representation, App B creates its own tenant. Dell has a subscription model so a customer gets access to A and B via subscription with id "2057". The identity broker (DIB/KC) establishes an organization for subscription 2057 with trusted set of IdPs and any user who authenticates through the broker in that org gets the subscription id 2057 in his claimset. We sort of expect mapping to be widely variable - some will need lots of mapping between the broker and IdP and others, less. Agreed on all counts - having an entity to represent a 'group' construct is robust enough to present to users via UI as groups, and then also surface it as an organization construct so it's easy to see how to collect cooperating clients.

Hi Bill et al, comments below... That's true - I mean both things are true :) I believe, in order to properly normalize things like group names in the authoritative location (where KC is the authority), then the group name must be defined in KC and IdPs would map to that name as part of IdP mapping definitions. Of course, one could also *not* introduce mapping and just let each IdP pass through its own group definitions and let RPs sort it out themselves. I partially agree with moving client roles to groups, but I think that the pattern that keeps appearing in the authZ department (role-based access control or RBAC) is to have this structure (including slightly different names and semantics): * there are users * users can be in groups * groups can be in groups * users and groups can be assigned roles * roles can be assigned permissions (aka claims in this context) * so a given user has a group, the group has n roles, and each role has m permissions attached to it -- an authenticated user has that little graph attached so an RP can interpret it to establish authZ decisions. * a user can be assigned roles without using a group I think your migration thinking is correct - and it opens up the chance to represent good granularity if it's needed, and basically ignored when it's overkill. I'm advocating for a permissions collection associated with a role, but there is an argument to say that having 'permissions' is nutty, since one can model simple authZ with a single-role-per-permission like KC roles do now. E.g., once authenticated, I might have a group 'Aliso Viejo R&D' and a set of roles which assert things like can-edit-bamboo-config, can-run-bamboo-build, etc. and I think that overloads the conventional meaning of a 'role' and that it's modeled a bit more tidily by having roles which act as named collections of permissions. Finally, where you said above "We have a few users that want to share a set of roles between different clients" then I think that's where the 'organization' type group comes into play. Clients A, B, C are in an 'org' (ok, group :) called 'tenant-20' which has a role called 'tenant-20-role' associated with it. This role, in turn, has claims/permissions. So any user authenticated by KC into A, B, or C gets the claims expressed in the tenant-20-role. Further, only one of those users might be in an 'admin' group which has additional claims beyond those in the tenant-20-role. - scott r