Skip to end of metadata
Go to start of metadata
Question and Answer |
---|
The Self Help Guides feature in MyGPS *is* visible to anonymous users. |
When running in authenticated mode, MyGPS will require the 'MY_GPS_TOOL' permission. You will receive an error dialog if you try to access MyGPS as an authenticated user without that permission.By default MY_GPS_TOOL is only granted to the following security groups: - SSP_STUDENT
- SSP_ADMINISTRATOR
- SSP_DEVELOPER
To grant it to other groups via the UI: - Sign in as a portal administrator
- Manage Users -> Manage Access -> User Access Management -> Manage Permissions
- Ctrl-F and search for "MY_GPS_TOOL", click it
- Click "Add an Assignment"
- Type "All permissions" as the Target, press Submit
- Click "Choose Principals"
- Click "SSP Roles"
- Click the group to which to grant the permission
- Click the green "plus" icon that will appear next to the selected group's name in the group panel header, this will add the group to the list on the right
- To add more roles, click "SSP Roles" in the breadcrumbs to get back to the list of all SSP security groups
- Click "Submit" when you're done.
- Select "Grant" from the combo-boxes for the groups you just selected (change will be submitted automatically, there is no submit button)
- Sign out
- Sign back in as a user in one of the groups to which you just granted the MY_GPS_TOOL permission and visit the MyGPS URL (http(s)://{domain}/ssp/MyGPS/index.html)
Note that this will only allow authenticated access to MyGPS for members of the selected groups. It will not add a link to MyGPS to their navigation. The latter is driven by group membership rather than permissions. By default, only the SSP_STUDENT group has the MyGPS navigation link. |
How to calculate SSP Security Group Memberships from Multi-Valued User Attributes |
This answer covers two topics related to connecting LDAP groups/attributes to SSP roles. The terms "security group" and "role" interchangeably to mean, from SSP's perspective, "a collection of users associated with a set of permissions". SSP security group assignment - Multi-valued can be used for attributes for security group assignment, albeit with caveats. For example, you could use a groupMembership LDAP attribute where values are DNs, and set up a rule for SSP_COACH group assignment along the lines of (groupMembership=<coach-group-DN>). Technically, you can even implement group assignment via nearly arbitrary attribute matching rules, including multi-attribute rules and regular expressions. Multivalued attributes, attributes with DNs as values, and complex matching rules can cause problems for the SSP coach lookup (more below).
SSP coach lookup - The coach lookup is actually an attribute query (i.e. "find all users where (attributeA=foo)"), as opposed to a SSP role membership query. That attribute query is configurable, but with at least two restrictions:
- SQL-style wildcarding is allowed, but not regular expressions, and not on multi-valued attributes if the underlying attribute source is LDAP (code customization would not fix this), and
- Matching rules cannot be and-ed or or-ed, even if they refer to a single attribute, i.e. supporting "(|(attributeA=foo)(attributeA=bar))" would require code customization.
- To derive SSP group membership from a multi-valued LDAP attribute containing DNs, the following problems exist:
- You cannot map multiple DNs to the SSP_COACH role. I.e. DN 'or-ing' (wildcarding being a subset of that) is not supported for coach lookup.
- You cannot require membership in multiple DNs for assignment to the SSP_COACH role. I.e. DN 'and-ing' is not supported for coach lookup
- Restrictions 'i' and 'ii' do not apply to other roles because SSP does not perform the same sort of member lookups on non-coach roles.
|