...
- 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
- The caller is assumed to know at the minimum
Anchor | ||||
---|---|---|---|---|
|
Delegating Authorizations
- When allowed, authorizations can be delegated to another principal within the constraints of the initial authorization. In other words, you shouldn't be able to delegate more authority than you actually possess (this is a different concept than having authority to grant authorizations in general).
- Ex. An instructor is heading out of town for a week or two and needs to allow his TA to submit grades for his courses.
- Ex. If the "primary" authorization has an end date of 9/1/2008, the delegated authorization can't have an end date beyond 9/1/2008.
- Authorizations can be delegated repeatedly.
...