IT:AD:Design:Investigations:Security:Authorisation:RBAC

No Owner: an important disctinction between an RBAC and an DAC is that Authorisation does not take into account whom is the Object's Owner.
Usage: The Authorisation is simply verified on the Operation, not on the Object.
- Often applied as an Attribute (see MVC), and not in the code within the operation.
A user can be a member of n Roles.
- But just because one could use a RBAC system that way, Roles are not to be confused with Permissions/Operations.

Pros:

Cons:

Too Gross: the issue is one ends up with only gross generalities (ACCOUNTANT, MARKETING, HR, ADMIN etc.) without the fine grain control of an Operations/Permission based Authorisation Control system.
Inflexible: no Role Hierarchy.
No means of excluding one or more of a role's sub operations. An example would be that you want those working in the Accountants office to belong to a role called ACCOUNTANTs…except that you want everybody in the dept except the dept head to not be able to Approve Expenses…
- RBAC's solution is to create two roles (ACCOUNTANT and ACCOUNTANT.ASSISTANCE), but in a non-trivial app, the number of roles becomes impossible to manage.
Poor Maintainability: it has been my professional experience that there is always some scenario that is not envisioned during design time, that usually gets fixed using a hack in the Application layer to get around the limitiations of the Role based authentication.

**Conclusion:**

A

void using a Role Based Authentication Control system in all except the most trivial applications.

[Subject]<>→[Role]

Notes