Beginning in July 2018, we have started offering an attribute that will pass Wolftech AD group memberships to our Service Provider (SP) clients that request them.
This attribute uses the standard LDAP name and OID:
|AttributeID||SAML2 Name||Suggested ENV Name|
This is a multi-valued attribute which can list many groups for some users. For example, one OIT employee currently has 19 group memberships.
Group names are returned in their fully-qualified distinguished name (DN) format. For example:
CN=WT-NCSU-All Staff,OU=Managed Groups,OU=NCSU,DC=wolftech,DC=ad,DC=ncsu,DC=edu
We can do filtering on the group list. This will allow us to only release a subset of the full list of groups that is relevant to your application. For example, a request for "CN=OIT-.*" would only return the groups that begin with the OIT department in their name. You may also request specific groups by listing their full DN names.
Groups are only provided by our primary Unity Identity Provider (IdP), shib.ncsu.edu.
Groups are only queried from Wolftech AD. Users with partially disabled Unity accounts are moved to another AD server and will not have groups.
Groups are only evaluated one-level deep. For example, if user01 member of smallgroup02, and smallgroup02 is a member of biggroup03; then shibboleth will report membership in smallgroup02 only. AD requires a special connection setup to evaluate nested groups that Shibboleth does not support. 1
Requesting This Attribute
SP owners must request isMemberOf as one of their attributes when filling out the access request form go.ncsu.edu/shib-access-request, in section 1. This will not be released except upon request.
SP's that are already registered may request this attribute be added by sending an email to firstname.lastname@example.org. Be sure to include your SP entityID that needs to receive the attribute.
In either case, please include details on how you plan to use the attribute. Also consider whether you need the full list of all groups, or a subset that we can filter before passing along.
Using the Attribute
If you have an existing SP that will add this attribute, you will need to make sure you have added an entry for it in your Attribute Map file. Sites that are using our suggested mappings can simply download the updated file from sample30-attribute-map.xml and replace the copy found on your server at /etc/shibboleth/attribute-map.xml .
If you want to manually add the mapping, edit your /etc/shibboleth/attribute-map.xml file and add an entry like this to it:
<Attribute name="urn:oid:126.96.36.199.4.1.59188.8.131.52.1" id="SHIB_MEMBEROF" />
If you are not using our suggested mappings, you can change the id="SHIB_MEMBEROF" entry above to a name of your choice. The SP will return that name as an environment variable to your programs.
After you have updated your map file, restart shibd and test to verify the new attribute is being passed in the environment.
Each group in the list will be separated by a semicolon when the list is passed through the environment. For example, when testing with PHP you might see:
[SHIB_MEMBEROF] => CN=WT-OIT-Shared Services,OU=Managed Groups,OU=NCSU,DC=wolftech,DC=ad,DC=ncsu,DC=edu;CN=WT-NCSU-All Staff,OU=Managed Groups,OU=NCSU,DC=wolftech,DC=ad,DC=ncsu,DC=edu;...
In Htaccess Files
Here's a simple example of how to write an .htaccess file entry to require users that are members of one of three AD groups.
AuthType shibboleth ShibRequestSetting requireSession true require shib-attr SHIB_MEMBEROF "CN=NCSU-B-Unity Users,OU=Managed Groups,OU=NCSU,DC=wolftech,DC=ad,DC=ncsu,DC=edu" require shib-attr SHIB_MEMBEROF "CN=NCSU-D-Unity Users,OU=Managed Groups,OU=NCSU,DC=wolftech,DC=ad,DC=ncsu,DC=edu" require shib-attr SHIB_MEMBEROF "CN=NCSU-J-Unity Users,OU=Managed Groups,OU=NCSU,DC=wolftech,DC=ad,DC=ncsu,DC=edu"