Implement devolved permissions
On completion of this story, users would be assigned roles on login according to what is sent across in the SAML Response. These roles would be sourced from a central authority outside of Aspire.
Running in this mode, Aspire would no longer have control or responsibility over how roles are assigned to users, and would be merely taking a lead from information passed in the response. The process for a user assuming a role would occur outside the system boundary.
We have now completed this story
Adminchrisc (Admin, Talis) commented
We've been working out the specification of the devolved permissions story in preparation to commencing development next week.
I want to share with you the specification of how we expect the permissions to be passed in the eduPersonEntitlement attribute prior to us starting work.
The specification we have come up with is for customers to pass us 0, 1 or many URIs in the eduPersonEntitlement attribute in the following form:
aspirebaseurl = the domain name of your aspire tenancy, e.g. liblists.sussex.ac.uk
There are a number of assumptions implicit in this:
You must specify at least one role - the role parameter is mandatory. Otherwise the devolved permission is ignored by the application. In debug mode a HTTP 401 is returned (see below).
Scopes are optional. Where scopes are specified, any roles specified apply to only to the scopes specified.
You can specify many roles and many scopes in the same URI - this means all of the roles apply to all of the scopes.
If no scope is specified then the role is constrained to the whole tenancy - i.e. the user assumes the permissions the role grants over all data in the tenancy
If one or more of the scopes specified does not resolve to a AIISO code in Aspire, that scope is ignored. This means you can pass over AIISO codes that Aspire does not know about yet and they will be safely ignored for now. We could consider logging and reporting on these somewhere. This is also a hook later for automatic update of Aspire heirarchy.
If none of the scopes specified resolve to AIISO codes in the store the whole devolved permission is ignored (i.e. behavoiur is different from step 3 where no scopes defined gives permission at whole tenancy scope).
NB. AIISO codes are the module codes you sent us over in your hierarchy conversion, e.g. http://aspirebaseurl/modules/prba24212 has an AIISO code of prba24212.
Grant list publisher role constrained to module with code ABF203:
Grant list publisher and node editor role, both constrained to module with code ABF203 and PHY101:
Grant list publisher role to all data in the tenancy
Some other useful aspects of the design:
* You can choose which role codes map to what specific roles in Aspire, so the role codes are your language and not Talis'. You could for example have us configure "module-leader" to map to the list publisher role in Aspire. This might mean there is less need to pre-process at your end.
* For debugging, prior to implementing the spec in your IDP, you can enter any of these URIs in your browser and they will echo some RDF which interprets the URI. This is useful so you can see if Aspire understands the URL in the same way you thought it would. Also this will return a HTTP 401 Bad Request if you ask for role codes that don't exist or otherwise format a URI that doesn't make sense.
Any questions or discussion points let us know,
Richard Cross commented
This is obviously a cornerstone - without SAML attribute management so many other things are not possible.