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: Richard James <>
  • To: Keith Hazelton <>, "" <>
  • Cc: Mike Roszkowski <>, Paul Donahue <>
  • Subject: RE: [grouper-users] enterprise data-driven groups
  • Date: Tue, 6 Dec 2011 14:00:41 +0000
  • Accept-language: en-US, en-GB
  • Acceptlanguage: en-US, en-GB


1) At Newcastle University we have a large number of groups where memberships
are based upon our student and HR(SAP) systems. We have a institutional data
feed service which has a centralised data warehouse which brings all this
data together. With this warehouse we are easily able to extract data about
staff/students using a data integration tool (Talend), carry out the
necessary transformation of this data and port it into the Grouper database.
Some of the data we store in the grouper db includes, staff to department
relationships (creation of Org structure in Grouper), student course
enrolments, student modules enrolments, and lecturers to modules (used for
the management of reading lists for modules).

2) We use this data on a use case basis, for example if an academic requests
a group to be setup with all students on a particular course we will set this
group up. We have chosen to do it this way so that we do not load numerous
redundant groups into Grouper. By default we did choose to load in the
organisational hierarchy for staff and module enrolments for students due to
the interest expressed in making use of these types of groups. All of these
groups are created within a corporate data stem and are non editable by
users. The groups can be used to populate memberships in "Application"
groups, but are not used directly to manage access to resources. We only push
application access groups into the Active directory, with the corporate data
groups being referenced indirectly through being members of the application
groups. Currently for an application group to be provisioned into the AD, a
user must set a provision attribute on the group.

3) Our Shibboleth IDP's are configured to query the grouper database for a
users application group memberships. We have a grouper_groups attribute set
in shib which presents all application groups a user is a member of. We are
working towards having all application groups provisioned into the AD by
default, and then configuring Shib to query a users group memberships
directly from the AD (hopefully at the start of 2012). This should provide a
more resilient approach and reduces the potential of a point of failure if
the Grouper DB was temporarily unavailable.

I hope the above is of some help and makes sense and if you would like any
further info please feel free to give us a shout.


Richard James
Infrastructure Systems Administrator
ISS Systems Architecture
Newcastle University (UK)

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