Skip to Content.
Sympa Menu

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

Subject: Grouper Users - Open Discussion List

List archive

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


Chronological Thread 
  • From: Chris Franks <>
  • To: "''" <>
  • Subject: [grouper-users] using shibboleth with groups provisioned into the AD
  • Date: Tue, 1 Mar 2011 14:15:19 +0000
  • Accept-language: en-GB
  • Acceptlanguage: en-GB

Hi,

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:

Applications:Org_Groups:Auto_All_Staff

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

CN=Auto_All_Staff,OU=Org_Groups,OU=Applications,OU=GrouperGroups,OU=Campus
Administration,DC=campus,DC=ncl,DC=ac,DC=uk

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

<resolver:AttributeDefinition xsi:type="Script"
xmlns="urn:mace:shibboleth:2.0:resolver:ad"
id="adgroups"
sourceAttributeID="memberof">
<resolver:Dependency ref="nclLDAP" />
<resolver:AttributeEncoder xsi:type="enc:SAML1String"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
name="urn:mace:dir:attribute-def:adgroups" />
<Script><![CDATA[

importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
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(",");
broken=broken.reverse();
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
adgroups.getValues().add(attr);
}
}
}
]]></Script>
</resolver:AttributeDefinition>

<resolver:DataConnector id="nclLDAP" xsi:type="dc:LDAPDirectory"
ldapURL="ldap://<ldapserver>:3268"
baseDN="DC=campus,DC=ncl,DC=ac,DC=uk"
principal="<principalName>"
principalCredential="<principlePassword>"
lowercaseAttributeNames="true">
<resolver:Dependency ref="campusid" />
<dc:FilterTemplate>
<![CDATA[
(cn=$username})
]]>
</dc:FilterTemplate>
<!-- just get the "memberof" attribute for this user -->
<dc:ReturnAttributes>memberof</dc:ReturnAttributes>
</resolver:DataConnector>

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

Best,

Chris
ISS, Newcastle University



Archive powered by MHonArc 2.6.16.

Top of Page