Grouper Users - Open Discussion List

[Colin Hudler <>]

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 
> Grouper?
>    

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.

<snip>