Naming folders and groups in Grouper

ua - Primary location for UA groups.

etc - Internal Grouper folders and groups.

ua:inst - Institutionally managed groups.

ua:inst:buildings - Building locations

ua:inst:buildings:<building name> - Groups for each building.

ua:app - Application specific folders

ua:app:vpn - Groups for UA VPN access.

ua:app:vpn:vpn_access - Ad-hoc group for UA VPN access.

Subject source configuration

• What should we use as the subject ID in Grouper? Assuming the uid attribute for now.

UID is opaque and unique to LDAP; standard unique identifiers are UA Username in UASystemID in LDAP which is name based but may change as names change; and UA ID# or BannerID in LDAP which unchanging numeric ID.

• What attribute will have the users' names? Assuming displayName for now.

displayName in LDAP, but cn in AD; cn is multi-valued in LDAP

• LDAP searches will be based on the uid and displayName attributes.

Why displayName? UID is opaque and not generally suitable except in two-step process (1) search on name, or known unique identifier to obtain dn, then (2) query for desired attributes in that dn.

• Subject sorting will be based on the displayName attribute.

displayName is 'PreferredFirstName sn'; perhaps sort on sn?

Task details

1. Install and configure Grouper (including relevant components) and integrate with their subject sources.

• Install the Grouper API and Grouper UI components.
• Disable default grant read/view access on new group creations. This is generally good practice so that read/view access has to be explicitly given.
• Enable wheel group to allow a group of admin users.
• Enable include/exclude and requireGroup configurations. This allows easier creation of composite groups.
• Enable the Grouper Report to run daily. What email address should the report be sent to?
• Enable membership import and export in the Grouper admin UI.
• Configure the subject API to query subjects from the production LDAP.

2. Integrate Grouper UI with their SAML environment.

• Install and configure Shibboleth SP if not already installed by UA.
• IdP should release the uid or eppn attribute to the SP. If releasing eppn, is that attribute available in the production LDAP?

3. Set up jobs to load data into Grouper from LDAP.

• Set up the Grouper Loader to load buildings into Grouper under ua:inst:buildings using data from the production LDAP.
• What attribute contains the user's building? Is the attribute multi-valued? Are all buildings being populated into Grouper or a subset?
• Are the values of the attribute the exact name to use as the Grouper groups? Or does there need to be some mapping or parsing done?
• How often should the job run? Hourly? Daily? Probably depends on how long it takes to run the LDAP query and how many users there are.

4. Create an ad-hoc group for VPN access.

• Create the group ua:app:vpn:vpn_access.
• This could be turned into a composite group if UA wants to see that functionality demonstrated.

5. Set up provisioning from Grouper to LDAP.

• Set up the PSP to provision Grouper objects to a test LDAP and a test AD using the bushy structure (as opposed to the flat structure where all groups are created directly under one OU).
• What is the base DN for groups and people in both test environments?
• Do the two test environments (test LDAP and test AD) have all production users? If not, is there a large enough sample of users for the provisioning test to be useful?
• For both test environments, currently assuming that the member attribute for group objects will be populated.
• Group and folder descriptions will also be populated in LDAP/AD.
• Incremental provisioning to LDAP will run through the Grouper Daemon. Bulk provisioning will run once a day.

6. Documentation

• All configuration changes will be documented.