Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] using shibboleth with groups provisioned into the AD

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] using shibboleth with groups provisioned into the AD

Chronological Thread 
  • From: Jim Fox <>
  • To: Chris Franks <>
  • Cc: "''" <>
  • Subject: Re: [grouper-users] using shibboleth with groups provisioned into the AD
  • Date: Tue, 1 Mar 2011 08:01:53 -0800 (PST)

We used to do something like this, but we searched the groups OU,
not the person OU. Each of our group entries had a "cn" attribute
that was the name, e.g. Applications:Org_Groups:Auto_All_Staff,
and one or more member attributes. That way the ldap search


gave back 'cn' attributes we could use directly.


On Tue, 1 Mar 2011, Chris Franks wrote:

Date: Tue, 1 Mar 2011 06:15:19 -0800
From: Chris Franks

Subject: [grouper-users] using shibboleth with groups provisioned into the AD


Here at Newcastle, we've been using group membership as a Shibboleth
attribute by querying the Grouper database but, recently, we had an outage on
our Grouper database server and this caused problems with Shibboleth not
being able to retrieve its attributes. As the Active Directory (AD) has to
be up for Shibboleth login to be successful, and is clustered and resilient,
we're thinking of using the groups provisioned into the AD rather than
directly from the database as Shibboleth attributes. Doing this reduces the
number of dependencies our Shibboleth server has, and means we can make group
membership data more reliable.

We're already provisioning groups/memberships into the Active Directory here
and so I've had a go at rewriting the DataConnector using an LDAP query and
the AttributeDefinition using JavaScript to reformat the results to read the
same as the group names from the database (for continuous service).

For example, one of our grouper groups looks like:


Whereas the AD group name returned for this would look like:


The translation/attribute definition I've written looks like:

<resolver:AttributeDefinition xsi:type="Script"
<resolver:Dependency ref="nclLDAP" />
<resolver:AttributeEncoder xsi:type="enc:SAML1String"
name="urn:mace:dir:attribute-def:adgroups" />

adgroups = new BasicAttribute("adgroups");
// if there are some groups returned
if (typeof memberof != "undefined" && memberof != null)
// for each group
for (i=0; i<memberof.getValues().size(); i++)
// assign the value to a variable
var value = memberof.getValues().get(i);
// if the group has come from grouper (this depends on your
ad/group structure)
if (value.indexOf("GrouperGroups") != -1 &&
value.indexOf("Applications") != -1)
// reformat the string to match grouper db groupname
var broken=value.split(",");
var attr=broken[6].replace("OU=", "");
for (j=7; j<=broken.length-1; j++)
attr += ":" + broken[j].replace("OU=", "");
attr = attr.replace("CN=", "");
// write the attribute out

<resolver:DataConnector id="nclLDAP" xsi:type="dc:LDAPDirectory"
<resolver:Dependency ref="campusid" />
<!-- just get the "memberof" attribute for this user -->

This seems to be returning the right results for us so far (returning
Applications:Org_Groups:Auto_All_Staff, in this case).

Hopefully this might be useful for anyone else who's thinking of using
GrouperGroups in Shibboleth from the AD (and/or wants to maintain the same
group name-formatting as grouper has in its database).


ISS, Newcastle University

Archive powered by MHonArc 2.6.16.

Top of Page