Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] enterprise data-driven groups

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] enterprise data-driven groups

Chronological Thread 
  • From: Colin Hudler <>
  • To: Keith Hazelton <>
  • Cc: , Mike Roszkowski <>, Paul Donahue <>
  • Subject: Re: [grouper-users] enterprise data-driven groups
  • Date: Wed, 30 Nov 2011 10:03:38 -0600

Big question, deep topic. At The University of Chicago, we've been using grouper in production about 4 years. Most of our work has been focused on the data flow into and out of, and not as much focus on group delegation and distributed management/responsibility. Despite this, we have a fair number of independently managed groups from departments throughout the institution.

My answers to your questions are inline

On 11/29/2011 01:00 PM, Keith Hazelton wrote:
We're going with Grouper for our group/privilege management system. The
project is launched.

I'd appreciate hearing how folks have handled the management of groups whose
membership is defined by some enterprise data. Do you load all of them into

We have loaded only data that has obvious use. In the early days, we speculatively loaded tens-of-thousands of groups from institutional sources (Enterprise Data?), but lately have taken a more conservative approach. The groups turned out to not be useful and cluttered up our space *and* our collective ability to plan and think clearly about the system's direction. However, it was still useful for us to exercise and experiment in our nascent time.

Nowadays, we are used to thinking about how grouper fits into the big picture. When we aren't sure about some institutional data, we scout and gather one or two use-cases, and then see how some candidate group-structures are able to attack those problems. This kind of work is probably already familiar to you in other areas, such as database design and SoA.

I have found that most nontrivial data can be represented in a number of ways in grouper. Since only one structure is likely to be created, it is important to know we've chosen one that is balanced enough to efficiently answer the intended use and have some longevity when the questions change. We use intuition and grouper sandbox systems to plan and test different structures. Most often we are thinking about the questions the consumer of the groups needs to ask, or how the groups will be reflected *outside* of grouper. We need to know the point-of-view of the client (are they interested in a single membership, or all the members? the groups related to each-other, or the stems and their structure? Maybe it just wants a boolean for authz?)

We have divided the groups registry into Reference data and "all other". Reference data (it is actually a top-level stem) is institutional information that is automatically maintained in grouper. At UC, it is the purview of Identity Management. The groups are maintained by Grouper-loader, and/or custom loaders, using the API. The data comes from many sources, such as Student Systems, HR/Payroll, Financial Systems, etc. Sometimes the data results in only a pair of groups whose memberships pivot on a couple of data points, such as "Current Account" and "Closed Account". Other times, the loaders are creating thousands of groups based on hundreds of data points, such as Financial Systems, Student Statuses, and other truly Enterprise systems.

The Reference groups are rarely used directly and rarely reflected to another system. They are used as a base to build other groups. These other groups are where actual access-decisions are made, and comprise at least 1/3 of our space. This allows us to make some semi-complex access decisions, like "must be staff member who forwards email but not if they are a contractor". Note, I use that example, but our most mileage comes from simplicity.

As you can imagine, many of the Reference groups have tens-of-thousands of members.

On the flip side, how much of what Grouper knows gets pushed out into your
person registry? your LDAP? Other places?

A few hundred. A small slice of the total. Most of our groups are building blocks leading up to the access groups which are specific to one application. We write groups to LDAP and ActiveDirectory. Each group is selected manually for synchronization (using group-attributes and entirely custom ldappc's). Whomever is selecting the group for provisioning already has a use in mind. Applications that already understand LDAP and AD groups have been easy for to integrate this way. We haven't yet tackled many of the hard problems, like per-group read/access permissions (in LDAP/AD). FERPA protection and other issues. We've gotten pretty far just doing access and permissions for other applications. On the other hand, UC didn't already have a system like that before grouper came along. Currently, sensitive and protected data must be accessed directly through the grouper webservice. We have a few applications that do this using custom WS clients.

In LDAP, we write static groups and dynamic groups. When the group is selected for provisioning, the static destination OU must be chosen. Our DSA (ODSEE 6.x) maintains the "member" attribute which is the DN of the static group. Besides the member attribute, the provisioner also writes to the member entry a "ucismemberof" attribute, which is our own. Many many applications rely on that attribute because it only contains the group-name, so is easy to test against, for example, an apache require directive.

In AD, we only write the static groups. AD maintains the member attributes. Groups that are provisioned to LDAP are not always written to AD, or the reverse. Our applications seem to never need them in both places. The environments are logically distinct, although the user population is identical.

How have you configured Shib IdP (if you have one) to pull in group
information about a specific person for inclusion in a SAML attribut
assertion? What attributes do you use?

We use ucIsMemberof (our own attribute), which is also the attribute name in LDAP, and also how the IdP obtains it. All of these attributes are made available to an SP which has that release (it isn't in our default attribute-release). The SP must request the group-data, but it is quite a common thing. We also release eduPersonEntitlement, which is calculated based on the group attributes.

As mentioned, some groups and memberships are sensitive and cannot make their way into AD or LDAP. For shibbolized apps that already have approval, we plan to give them the data by integrating the IdP directly with grouper. We're still in the planning phase of that.


Archive powered by MHonArc 2.6.16.

Top of Page