...
- Resource inheritance means that subjects which are assigned an action on a resource have other implied resources for that action (and inherited actions). An institution's organization chart or course structure could be modeled as privilege resources. Instructors could be granted privileges on individual courses, and deans could be granted privilege actions on entire departments or schools. Sometime a resource which implies other resources is referred to as a role, however, it might be that the bundle of resources qualifies a role instead of defines a new role.
Access Control Decisions (groups, roles, privileges, and external authorization)
Overview
Applications have various access control needs to control which subjects have access to what. This is generally for applications which require authentication, though the authorization could also apply to anonymous subjects (who would get privileges from an anonymous role).
...
- groups vs roles
- roles vs privileges vs hybrid
- hard-coded privileges vs externalized authorization
- for externalized authorization: centralized or not
- caching
Groups vs Roles
When applications protect resources by checking if the authenticated user is in a group, they are essentially using a group as if it were a role. For example, if the application code checks if the authenticated user is in the institution's "student" group, in order for them to see the main screen of the application, then there is an implicit hard-coded privilege resource of "main-screen", and action "view", assigned to the role "studentUser", which is assigned to the group "student". Though it is referred to as security by group, it is actually a role.
Roles vs Privileges vs Hybrid
Generally an application will have a handful or up to a couple of dozen roles. These roles are generally mapped to job function or affiliation. For example there could be roles for student, staff, instructor, admin, billingAdmin, anonymousUser, etc. Note that set of roles varies across applications as needed. Roles are used as a security template that multiple subjects can be assigned to for common access.
...
If the authorization system supports applications with subjects that select one role at a time to use the application, then individual privileges should be able to be assigned in context of one role. The subject will not need to have elevated privileges at all times, and thus will be less likely to accidentally perform tasks that only the elevated role can perform.
Hard-coded Privileges
If there is no access control framework or central system, then hard-coding the privileges in the application might be the easiest way to code an application.
...
External or centralized authorization gives the application run-time flexibility for changes in access control policy and authorization reporting.
Advantages of Centralized Authorization
Centralized authorization systems can show subject's privileges across applications and can ease revocation. Certainly as auditing requirements increase, and sharing of access control policies across multiple applications, centralized authorization is required. If there is a common on-boarding workflow application, then centralized authorization can make the architecture more homogeneous.
Caching Considerations
When using externalized privileges, there are caching considerations. Caching can improve the performance of the application and reduce the dependencies of middleware components. If there are not real-time updates from the authorization system, then the privileges can become stale. When there are a lot of privilege resources and assignments which need to be checked, it is a good idea to cache the application's privileges for the entire user population, or for one user when the authenticate. If there are reports or queries which need to join available data with the allowed record types, the authorization information might need to be cached directly in the application's database. If there are limits on the authorizations, then it is more complicated then just a list of allowed action/resource pairs.
...