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: Nathan Kopp <>
  • To: "" <>
  • Subject: RE: [grouper-users] enterprise data-driven groups
  • Date: Mon, 12 Dec 2011 14:04:34 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

At CCCI we are in the process of integrating Grouper to become a key
component of our enterprise identity management system.

We are separating our groups into two categories:
1) IT roles
2) Enterprise roles

IT roles will correspond directly to roles defined by technologies, such as
AD groups, roles for the CMS, lists of users with accounts on a Linux server,
etc. Some IT roles are composite groups, others are normal groups, but
almost all IT roles are derived in some way from Enterprise roles.

Enterprise roles are higher-level conceptual roles, such as "staff members,"
"volunteers," or even "people who can access the staff intranet." Most
Enterprise roles can be managed manually, but some are also (or sometimes
exclusively) managed by web services.

Grouper is integrated with our SOA (service oriented architecture) through
custom web services and powered by the JBoss Drools rules engine. When new
data is entered into an enterprise system, such as our HR system, that data
triggers processes in our SOA. The custom identity-related web services tap
into that data flow and run the data through the Drools rules engine to
determine if any new groups should be assigned or if any groups should be
unassigned. (Drools is great for this job since rulesets can be defined in
Excel spreadsheets, which work very well for easily declaring which staff
members should be granted which roles.)

The results from the drools rules engine are then used to make changes to
group membership through the Grouper API. Grouper Web Services could be used
instead, but use the raw API since we want to read some fine-grained
information. Primary, we want to determine who is responsible for creating a
"membership" (a.k.a. "attestation") when deciding whether or not to
automatically remove group membership. (i.e. We want to see whether the
ruleset was responsible for an existing role assignment or whether the role
assignment was done by a human, since we use that to help decide if the
ruleset should remove the assignment or let it stand.)

Usually the automated system makes modifications to Enterprise roles (instead
of IT roles), which in turn impacts the effective membership of IT roles. We
use some custom ChangeLog listeners to watch for membership changes in IT
roles and push (a.k.a. "provision") those changes to external systems such as
AD and LDAP.


>-----Original Message-----
> [
> On Behalf Of Keith Hazelton
>Sent: 29 November 2011 19:00
>Cc: Mike Roszkowski; Paul Donahue
>Subject: [grouper-users] enterprise data-driven groups
>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?
>On the flip side, how much of what Grouper knows gets pushed out into
>your person registry? your LDAP? Other places?
>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?
>Thanks for help on these newbie issues.
> --Keith Hazelton

Archive powered by MHonArc 2.6.16.

Top of Page