== [[https://iam.alaska.edu/|IAM]] / [[https://iam.alaska.edu/projects|Projects]] / [[https://iam.alaska.edu/grouper|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: - 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? [[br]] ''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.''[[br]]Use UA subject ID = ID#, BannerID, typically an 8-digit numeric. * What attribute will have the users' names? Assuming displayName for now.[[br]] * ''__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. [[br]]__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.[[br]] __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[[br]]__sn__[[br]]appear parallel in LDAP & AD - i.e., same value for same subject'' [[br]] Use givenName and sn for consistent results in LDAP, AD source * LDAP searches will be based on the uid and displayName attributes.[[br]] * ''Why displayName? UID is opaque and not generally suitable except in two-step process:[[br]] (1) search on name, or known unique identifier to obtain dn (like "uid=12wynpgyz01,ou=people,dc=alaska,dc=edu"), then [[br]](2) query for desired attributes in that dn.'' * Subject sorting will be based on the displayName attribute.[[br]] * ''displayName is '!PreferredFirstName sn' in LDAP or !givenName MI sn" in AD; [[br]]perhaps sort on sn?'' '''Task details''' 1. Install and configure Grouper (including relevant components) and integrate with their subject sources.[[br]] ''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.[[br]] 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?[[br]] ''ePPN is built in the IdP from UA Username'' * ''See [[https://iam.alaska.edu/shib/wiki/TestIdPConfig|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.[[br]] ''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 [[https://iam.alaska.edu/grouper/raw-attachment/wiki/Phase1Planning/buildingcodesnamescampus.xlsx|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.''