Modify Group Management Authorization

[davidrkupton]

Jira: https://bostondoit.atlassian.net/browse/DIG-63

Requirement for modified functionality of the GROUPMGMT functions of Access Boston.

[davidrkupton]

Access Boston has a limited capability to manage groups that exist within FID: adding and removing users from the group. This functionality is granted to users based upon the groups that they are a member of at the time they login to Access Boston.

There are 2 levels of groups which apply to Access Boston Apps.

• GroupMgmt Group with cn in format: e.g. SG_AB_GRPMGMT_application
• Application Group with cn in format: e.g. SG_AB_application_text

A GroupMgmt Group has an LDAP like this:

{
   "cn": "SG_AB_GRPMGMT_FHESALESFORCE",
   "dn": "cn=SG_AB_GRPMGMT_FHESALESFORCE,cn=AB_Security_Groups,cn=Groups,dc=boston,dc=cob",
   "ou": "",
   "uniquemember": [
     "cn=102214",
     "cn=134773",
     "cn=40005276",
     "cn=111023"
   ],
   "actualdn": "cn=SG_AB_GRPMGMT_FHESALESFORCE,cn=AB_Security_Groups,cn=Groups,o=cobhdap",
   "entrydn": "cn=SG_AB_GRPMGMT_FHESALESFORCE,cn=AB_Security_Groups,cn=Groups,o=cobhdap",
   "objectclass": [
     "groupOfUniqueNames",
     "top",
     "groupOfURLs"
   ]
 }

An Application Group has an LDAP like this:

{
  "cn": "SG_AB_FHESALESFORCE",
  "dn": "cn=SG_AB_FHESALESFORCE,cn=AB_Security_Groups,cn=groups,dc=boston,dc=cob",
  "ou": "",
  "uniquemember": [
    "cn=40003289",
    "cn=134773",
    "cn=111023"
  ],
  "actualdn": "cn=SG_AB_FHESALESFORCE,cn=AB_Security_Groups,cn=groups,o=cobhdap",
  "entrydn": "cn=SG_AB_FHESALESFORCE,cn=AB_Security_Groups,cn=groups,o=cobhdap",
  "objectclass": [
    "groupOfUniqueNames",
    "top",
    "groupOfURLs"
  ]
}

A cn for a group will have the following format SG_AB_[GRPMGMT]_APPNAME_[APPSUBTYPE] where GRPMGMT and APPSUBTYPE are optional.

• A GroupMgmt Group is identified by having its cn start with "SG_AB_GRPMGMT".
• An Application Group is identified by having its cn start with "SG_AB" and not containing the string GRPMGMT.
• The Application is the part of the cn without "SGAB" (and "GROUPMGMT"),up until the next underscore (). For example in SG_AB_FHESAMESFORCE and SG_AB_FHESALESFORCE_ADMIN the application is FHESALESFORCE.
• Application Groups whose cn contain the APPNAME string (e.g. FHESALESFORCE) are part of the same "App Suite" and can be managed by a user who is a member of the Application's GroupMgmt Group (i.e. "SG_AB_GRPMGMT_APPNAME" group)

Rules: 1: If a user is a member of any GroupMgmt Group, then the Group Management link becomes available to that user on their Access Boston portal. 2: When a user clicks on the Group Management link, they will be able to add and remove users from any Application Group in the App Suites associated with the GroupMgmt Groups they are a member of. Specifically, a user with membership of a GroupMgmt Group may add/remove themselves from an Application Group in the App suite (but not to/from the GroupMgmt group).

3. Being a member of an Application Group controls the availability of the application icon (and/or other functionality) on a users Access Boston Portal.

[davidrkupton]

@g-grozier I think this summarizes things. To keep track, I think maybe you should paste comments as new github comments in this issue and I will edit my original.

One thing as a comment, the method of identifying the relationship between GRPMGMT groups and Application Groups is going to be very prone to errors. I notice that we do not appear use the ou attribute of the FID/LDAP record. For the Access Boston groups, could we consider using that field (or another we add to the dn) to identify all groups that are in the same "App Suite". This would make the solution more transparent, robust and less prone to errors in the future.

[g-grozier]

@davidrkupton looks good to me too. Would need to ask Navan/Peter/Sam what LOE would be to leverage OU attributes in FID. I also want to get the business context here - for app owners who want to be able to manage their own user group (ie. the app isn't birthright) we want them to have that fully self-service functionality via the Access Boston Portal. They can or remove anyone (with an account) at any time with no need to get DoIT involved.

[rachelsater]

Phil said this will be about 2 weeks of work. Gretchen said it's a low priority and Confirm ID (identity verification) is the top priority right now