Description
| Excerpt |
|---|
The Authorization Service manages the maintenance, auditing, and checking of authorizations. |
The authorization will support process based security (e.g. ability to force add a student to a restricted section) and value based security (e.g. access to students in the Bachelor of Arts program) for individual principals and groups of principals. Access may be granted for specific periods of time.
...
- A principal can be a person, but it can also be a non-human entity such as an application.
- Some references are not updatable through this service, since the "core" information should poke through from the service of record.
- All authorizations are explicit.
- All authorizations are positive.
- Finding all permissions delegated by a principal is handled through a search operation.
- ~abucior Unlicensed user This may need to be restated. There's an expectation that you'll be able to determine the principal who granted the authorization, but since connections between authorizations aren't explicitly visible through the service (at the moment), you may not be able to directly distinguish a "grant" from a "delegate" operation.
- Set up of roles, with associated permissions, etc. are handled in configuration.
- Set up of role categories and qualifier types are handled in configuration.
- Set up of qualifier hierarchies, including creation of "root" qualifier nodes, are handled in configuration.
...
- An authorization is the composite of the roleId, qualifierId, qualifierType, and principalId/azGroupId.
- While permissions could be thought of as meta-data describing the functional role, authorization checks will be handled at the permission level; however, granting authorizations will occur at the role level.
- Most authorizations are scoped to a particular context. Very few entities can perform the same function in all cases.
- Ex. An instructor can view the roster for a class. A department administrator can see the rosters for the classes taught by the department. A person in the Registrar's office can see the rosters for all classes taught at the university.
- There are dominant pieces of information in the context which control authorization. These dominant pieces can be arranged in a tree form to allow inherited permissions.
- Ex. An instructor can view the roster for a class (qualifier = class). A department administrator can see the rosters for the classes taught by the department (qualifier = department). A person in the Registrar's office can see the rosters for all classes taught at the university (qualifier = institution).
- The caller checking an authorization shouldn't need to know necessarily how an authorization was granted, just that the principal has the appropriate authorization.
- The caller should be able to check authorizations in a consistent way with a minimum amount of secondary lookups.
- The caller is assumed to know at the minimum
- "who or what is attempting to perform the action" = principal
- "what action is being requested" = permission (could also be the role depending on approach/naming)
- "in what context is the action being performed" = qualifier - this usually maps to the object id being worked on
| Anchor |
|---|
| delegateddelegatingdelegated |
|---|
| delegating |
|---|
|
Delegating Authorizations
...