Use cases for roles & entitlements
chris phillips
Hi all,
Darran and I have assembled the supporting use cases for roles and entitlements for the call later today and have included them below.
Use cases regarding use of roles and entitlements:
There are generally three main elements of a digital persona that are used to determine access control: groups, roles and entitlements. The decision about access control is opaque to the actual protocol but the elements need distinct representation to permit transit to the end point(s) desiring to consume the attributes and/or store their content to perform an access control decision.
It is important to allow these attributes to remain intact in their form and not be translated into another form (e.g. force entitlements into groups, or groups into roles, or roles into groups). It would cause additional and unnecessary work.
Groups, Roles and Entitlements are proposed as separate attributes on the assumption that “Groups are things you belong to”, “Roles are things you are” and “Entitlements are things you have”
Groups are things you belong to
A group is a named collection of identities.- Group Use Case #1
- A CSP provides storage to users who must log in via shell accounts. An identity has been provisioned with group memberships in the group ‘SysAdminDocumentAuthors’. A file system directory called ‘documentation’ exists and has unix group permissions set to allow the group ‘SysAdminDocumentAuthors’ read/write access. Said user signs in and navigates to the directory in question and because the permissions on the directory permit access, the user is able to created and edit documents.
- Group Use Case #2 for Group based access control
- A CSP based identity that has been provisioned with group membership of ‘WebAppAdmin’. The CSP hosts a web application that the user signs into and requires membership in the group to permit access. The web app queries the local user info for group membership and finds a match and permits access.
Roles are things you are
A Role is a label or string used to imply the assignment of a collection of entitlements related to a given business or technical function. For example, the role ‘Student’ maps to the collection of entitlements regularly assigned to a student:
- permitted to sign into wireless
- permitted web proxy access
- permitted acess to portal as student
Another role, called ‘Faculty’ maps to this collection of entitlements:
- permitted to sign into wireless
- permitted web proxy access
- permitted access to portal as faculty
- permitted to upload marks
- Role Use Case #1
- A CSP provides a web portal for an institution. An identity has been provisioned with the role designation ‘Student’. Due to this role being present in the persona, the portal experience is tailored to that of a student.
- Role Use Case #2
- A CSP provides a web portal for an institution. An identity has been provisioned with the role designation ‘Faculty’. Due to this role being present in the persona, the portal experience is tailored to that of a faculty member. Also, the persona has the additional privilege of uploading marks.
Entitlements are things you have
An entitlement is a multivalued attribute that can have zero or more string values . The values of the attribute are indicators of an additional right to a thing, object, or service. The vocabulary of the string is not constrained. Users may choose to adopt strategies that can encode information in the string in order to refine the meaning of the entitlement. An encoding scheme is used to encapsulate sufficient information so that the entitlement accurately and without ambiguity represents what the user has access to. An entitlement is something that frequently depends on other elements in the users account schema (e.g. their role in the org), so it should appear with the entitlement encoding model. It may be also be useful to provide a scoping model so that entitlements can be guaranteed to be universally unique.
Entitlement examples:
- Permit to sign in to wireless:
- urn:mace:example.com:service:wireless:allow:all
- Permit to sign into wireless in Engineering Building:
- urn:mace:example.com:service:wireless:allow:Engineering:Building123
- Permit access to peoplesoft production administration instance (non scoped)
- OPERID123:EMPLID345:PROD:ADMIN
- Permit student access to lms:
- urn:mace:example.com:service:LMS:student:allow
- Permit faculty acces to lms:
- urn:mace:example.com:service:LMS:faculty:allow
- Permit admin access to lms to see home address field
- urn:mace:example.com:service:LMS:admin:field:read:address
- Entitlement Use Case #1
-
A CSP provides an LDAP authentication service to wireless access points. The ACI rule in the LDAP directory filters search results for the privileged user that the access point binds as to require the entitlement ‘urn:mace:example.com:service:wireless:allow:all’.
As a result, the only success logins to the wireless access points are those with a valid userid and password and the entitlement ‘urn:mace:example.com:service:wireless:allow:all’. The entitlement is the service limiter in this case - Entitlement Use Case #2
- A CSP provides an learning management system web platform. Only specific individuals are allowed seeing the address field in the application. This logic is applied by interrogating the persona of the logged in user and reading the entitlement looking for an exact string match for ‘urn:mace:example.com:service:LMS:admin:field:read:address’. Once found, the logged in user is permitted to see the content for that field.