Page Comparison

...

• 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
Delegating Authorizations

...