| Wiki Markup | ||||
|---|---|---|---|---|
| Div | ||||
| }[||||
| Home]{div} h3. Description {excerpt} The Authorization Service manages the maintenance, auditing, and checking of authorizations.{excerpt} The authorization will support process based security |
Description
| Excerpt |
|---|
The Authorization Service manages the maintenance, auditing, and checking of authorizations. |
...
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.
...
| Note | ||||||
|---|---|---|---|---|---|---|
| =
| }|||||
CollectionSpace may not need to support process based security as described above. {note} h3. Assumptions * 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] {color:#00cc00}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.{color} * 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. *Authorization* * 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* * 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. *Qualifiers and Qualifier Hierarchies* * The combination of qualifierId and qualifierType is assumed to be unique enough to disallow collisions between qualifiers. * Qualifiers will have one to many parent qualifiers; the parent can be of the same or different qualifier type. * The root of one qualifier hierarchy can be registered as the child in another hierarchy. * Linking a qualifier does not include any child nodes that have been registered in other hierarchies. * Qualifier types can be restricted to disallow updates to associated qualifiers. * The same qualifier hierarchy may supply the context for multiple permissions and roles. ** Ex. A hierarchy of class is a child of department is a child of institution may support both viewing the roster as well as submitting grades. h3. Key Concepts h3. |
Assumptions
- 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 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.
Authorization
- 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
#delegating
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.
Qualifiers and Qualifier Hierarchies
- The combination of qualifierId and qualifierType is assumed to be unique enough to disallow collisions between qualifiers.
- Qualifiers will have one to many parent qualifiers; the parent can be of the same or different qualifier type.
- The root of one qualifier hierarchy can be registered as the child in another hierarchy.
- Linking a qualifier does not include any child nodes that have been registered in other hierarchies.
- Qualifier types can be restricted to disallow updates to associated qualifiers.
- The same qualifier hierarchy may supply the context for multiple permissions and roles.
- Ex. A hierarchy of class is a child of department is a child of institution may support both viewing the roster as well as submitting grades.