​IAM / ​Projects / Grouper / Phase 1 Planning

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?
  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.
  Use UA subject ID = ID#, BannerID, typically an 8-digit numeric.

I've met with the statewide AD admin 2012-07-27 and based on his input I'm proposing we use AD as the subject source; we'll search the Enterprise LDAP directory for buildings to create groups based on those users. AD has many more users because it initially loaded the entire history of UA people from our ERP. However, only recent people have uaIdentifier - the unique assigned generally numeric id. I assume that the existence of many records without the key (uaIdentifier) in AD will not interfere with Grouper operations. If people do a name based search, those without that key should be ignored (for example, by including a (uaIdentifier=*) clause in the search).

That attribute - uaIdentifier in AD == BannerID in LDAP may be used as the index or Subject ID in Grouper.

• What attribute will have the users' names? Assuming displayName for now.
  
  • displayName exists in LDAP as (preferred_first_name sn) and in AD as (givenName MI sn) so they are not the same string in the two sources for the same subject.
    cn exists in LDAP as multi-valued based on givenName, sn with and w/o MI; cn in AD appears to be the UA Username; so cn is not the same value in the two sources for the same subject.
    mail is a multi-valued self-service attribute in LDAP and a (single) assigned value in AD, so mail is not always the same value in the two sources for the same subject.
  • givenName and
    sn
    appear parallel in LDAP & AD - i.e., same value for same subject
    

Use givenName and sn for consistent results in LDAP, AD source

• 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 (like "uid=12wynpgyz01,ou=people,dc=alaska,dc=edu"), then
    (2) query for desired attributes in that dn.

• Subject sorting will be based on the displayName attribute.
  
  • displayName is 'PreferredFirstName sn' in LDAP or !givenName MI sn" in AD;
    perhaps sort on sn?

Task details

1. Install and configure Grouper (including relevant components) and integrate with their subject sources.
   Each step documented in detail as source and/or narrative in the IAM wiki.

• 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?
  ePPN is built in the IdP from UA Username; it is already resolved for sending to multiple SPs.
• See ​UA Shibb IdP Config Change for required steps to change configuration (add services) to production IdP cluster.

3. Set up jobs to load data into Grouper from LDAP.
   Each step documented in detail as source and/or narrative in the IAM wiki.

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

May as well generate all building-based groups; standard officeLocation attribute in LDAP is populated with a room number and controlled vocabulary building abbreviation, though there are a small number exceptions generated by individuals entering a building name in the room designator entry field instead of choosing from the pre-populated list of buildings.

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

Need to strip pre-pended room designation; should probably include campus in the group name; list of buildings with short and full name and campus is attached.

• 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 as narrative or outline, and scripts / code / terminal sessions in subversion source repository.