First published October 2003
Role-based security is a means of implementing an authorization mechanism which has the potential to substantially reduce administrative cost and reduce vulnerability. Enterprise Role-based security addresses the problem of maintaining authorizations within large IT environments; it is perhaps more accurately described as ‘Role-Based Access Control,’ or RBAC.
Authorization is the process through which a person is granted permission to invoke behavior, see, create, delete or update data, for one or more systems. The system is responsible for enforcing the permissions granted in the authorization process, and consequently, systems use a variety of techniques to support the authorization process. The most basic approach is to represent people in the system as ‘users,’ and then to enforce which users can perform what functions in the code.
So we end up with logic which looks like: ‘if user is Simon then deny…,’ and so on. The problem with this approach is that the ‘user’ concept really becomes a proxy for whichever employee is performing the function, and not an actually person. The user, in other words, is shared, with a corresponding security risk. Additionally, what the user can do is hard coded in the system, and difficult to change.
At the application level, role-based security addresses this problem by accepting that the ‘shared user,’ is really a role in the enterprise which multiple employees will perform. So, for example, a role might be ‘sales person,’ or ‘accountant.’ With roles made explicit in this manner we can then use the idea of a ‘User’ to be a proxy for an individual, with security information such as passwords specified for that person. The authorization process now becomes a matter of assigning one or more roles to a given user.
If the person that user represents is replaced by a different employee, then we delete the original user – or remove his or her roles – and create a new user for the new person. Many implementations of role-based security will choose to express in the system’s code the authority which has been granted to a specific role. This approach is supported directly in Microsoft’s .NET framework, where metadata can be used to flag functions with the required roles. This approach has the downside of being quite inflexible. Once the system has been created it is no longer a cheap proposition to change what your sales person role is permitted to see or do, which, given a dynamic business process, is not ideal.
The alternative to this approach is to represent the results of the authorization process as data in the system. This data is known as authorizations, permissions, entitlements, or provisions. A user can now perform a function if he possesses the required permission, through his role memberships. With this approach we have the ability to dynamically redefine the semantics of role membership as our business evolves.
Although application level role-based security is certainly a useful technique, the full benefit of this concept only appears in the enterprise-wide context. As things stand today most systems – whether they implement a role-based approach or not – contain their users’ authorizations in their own table structures, and have their own user interfaces for creating and removing users, and for defining authorizations. Consequently setting up new users and assigning them their authorizations is a system by system administrative task.
This is clearly a problem as the number of systems and users becomes large, or the turnover in users becomes high. Furthermore, there is an inherent security risk in this approach; since the authorizations for a given user are dispersed across multiple systems it becomes difficult to determine which authorizations a given user actually has. Diagrammatically, the current situation looks as depicted in figure 1, where we have three users in four systems, each with multiple entitlements (not drawn). If we wish, for example, to prevent our accountants from authorizing payments we would have to remove that entitlement in each system for each user, giving a total of 12 changes. Imagine a more representative environment of 50-100 systems with thousands of users. And if we miss one of those changes we have a security failure.
Enterprise Role-Based Authorization
Enterprise Role-based security is a solution to this problem. It introduces the idea of an ‘enterprise role,’ which, like the application role, represents a responsibility an employee might have in an enterprise, or, more broadly, a relationship a person has with the enterprise. A position in the organization’s hierarchy will have some set of responsibilities, and can consequently be described with a collection of enterprise roles. Defining the roles in an organization is an exercise in analysis which we call ‘Role Engineering,’ and is perhaps the most significant aspect of implementing rolebased security. Once we have the enterprise roles defined we can then associate our users with their roles, and the roles with authorizations, as depicted in Figure 2. Conceptually this approach allows us to add and remove authorizations from users with much more rigor; we no longer make security changes to individuals but to roles. By doing so we can be clear as to what people can do across our systems by virtue of their membership in certain roles. We would prefer not to associate authorizations with users directly, which should be considered an exception mechanism which complicates our overall gestalt of our granted authorizations.
Role-Based Security and the Enterprise Architecture
The structure described here can be implemented centrally and interfaced to the systems in the environment using, for example, a messaging infrastructure. This approach creates a true enterprise-wide role-based security implementation, and creates tremendous savings in administrative effort. Now, using our previous Accountant example, the revocation of an authorization requires a single change to one role, rather than 12 changes across four systems. Similarly, hiring employees is a simple matter of associating a new user with the roles defined for the job position, and firing employees is a matter of deleting a user. We now have a single, explicit definition of what a user can do in our systems; there is no longer redundant administration and consequently the possibility for security failures in this area is reduced. When we have an enterprise role based security service, as described here, we have to interface that service to the systems which are going to use it. The client systems should ideally receive from the service an abstract description of the authorizations a user has. The natural means of doing this is to create a model for authentications, and express that model using a standard XML dialect. Alternately, the service can provide the client systems with the users’ roles. The system will then maintain the authorizations for that role. This is clearly a less useful approach, since changing the authorizations for a given role can now no longer be done centrally.
Once we have rationalized our authentications through the introduction of roles we are in a position to enforce a ‘least privilege’ policy, in which roles are granted only sufficient authorizations to perform their function. Similarly, we can now identify and enforce ‘separation of incompatible duties,’ where a user should not be a member of two roles simultaneously. A single user should not, for example, have the role for authorizing a payment and the role for submission of a payment. An elegant role-based security service will provide a means of expressing constraints on role membership, and allow roles to be described hierarchically, such that new roles can be created by the extension or restriction of existing roles. An interesting consequence of expressing entitlements as data – rather than as static rules to be coded for each role – is the idea of delegation. Delegation is the process through which a user transfers his or her entitlements to another user. Delegation of responsibility – and thus entitlement – is quite common in business; people routinely delegate their authority to legal representatives, for example. Delegation is quite simple in a role-based authorization system, although a consequence of this is that the applications receiving entitlements have to expect dynamically changing entitlement sets for any user, and create user interfaces accordingly. The role constraint mechanism also allows us to address a problem in delegation, where we want the person to be able to delegate an entitlement but not to posses that entitlement themselves. This can occur where we want a supervisor to grant entitlements to his subordinates but not to perform the function themselves for separation of duties concerns.
Role-based security, when implemented for the enterprise, is a means of reducing administrative cost while at the same time enhancing security by removing uncontrolled redundancy and enforcing role membership constraints. For a detailed discussion of the potential cost savings of enterprise role-based security see “The Economic Impact of Role-Based Access Control,” NIST, U.S. Department of Commerce.