Today, more than ever, companies are dependent on agile applications and systems if they wish to meet and master a never-ending stream of new challenges and exploit fresh opportunities. IT departments in companies are tasked with providing IT resources quickly and seamlessly as soon as these are required by the users concerned. This wish for agility, however, has to be set against real security problems, whose number has increased significantly in recent years.
Organisations in every order of magnitude utilize highly disparate approaches and systems for identity management and provision over the entire lifecycle of digital identities. Traditionally, companies approach this process from an internal viewpoint. Due to the rapid increase of (self-service) portals, remote and home-office workplaces, plus BYOD concepts, more and more companies are being called upon to provide access to internal systems and applications for external users and devices as well. Experience has shown that the number of identities to be managed rapidly increases, which leads to a dilemma: is the present infrastructure for managing internal identities able to cope with the interactions required for registering and maintaining external identities? And: are the established role and rights concepts sufficiently flexible for meeting these rising expectations?
DAC, MAC, RBAC, and ABAC: what is best suited for whom?
The increasingly complex interrelationships between identities and resources radically redefine the concept of security, compelling us to think about access management in an entirely different way. Security begins with a subject (an employee or a program) receiving access to a resource (an application, a system or a file) through access control rules. These access control rules are restrictions on the system level which ensure that only the right identities have the right access to the resources defined.
Most identity and access management products offer a multiplicity of methods for implementing and monitoring access control, with different terminologies being used for describing these methods. All forms of access control, however, can ultimately be reduced to one of four classical models:
- Discretionary Access Control (DAC)
- Mandatory Access Control (MAC)
- Role Based Access Control (RBAC)
- Attribute Based Access Control (ABAC)
Even though this article concentrates primarily on the RBAC and ABAC models, we should like for completeness’ sake to briefly describe the first two as well.
DAC – Discretionary Access Control
DAC is a security concept for IT systems in which the decision as to whether a resource may be accessed is based solely on the identity of the protagonist concerned. In other words, the access rights for resources are specified for each identity. For example, an administrator can at his/her own discretion manually grant a different user access to a file or application.
MAC – Mandatory Access Control
MAC describes a rule-based access control arrangement where the decisions on access authorizations are taken not only on the basis of the user identity and resource involved but also by reason of additional rules and characteristics.
Given the swiftly rising number of users, the two above-mentioned methods for directly giving user rights and access to resources had rapidly proved to be too complex and therefore susceptible to error. Role-based access control is designed to impose abstraction on the management of access rights, with concomitant simplification.
RBAC – Role Based Access Control
RBAC controls access on the basis of roles that users have within the system and the rules that specify what access is permitted for which users in defined roles. In modern-day IAM solutions, “a role” is typical “a group” as well. A role is a logical grouping of one or more users with shared affiliations, such as the same department, class, age, physical location or user type.
The great advantage of RBAC in comparison to DAC and MAC is that by using the roles/rights concept (group) rights can very easily be assigned to individual identities.
The disadvantage of this flexibility is obvious: a role will typically have 1 to n group affiliations linked to it. For example, a Group Leader in the Human Resources Department will be a member of the following groupings: “Human Resources”, “Group Leader”, “Facility xyz”, “Specialist Application Human Resources”, etc.
In practice, each user is a member of several different groups. If a company has 20 departments, each with 15 organizational roles per department, then with the RBAC approach 20 x 15 = 300 groups have to be set up and maintained. This example illustrates how quickly the number of groups will grow even in mid-tier companies.
The consequence: access control using RBAC can quickly become unmanageable, particularly in the case of sizeable companies. What exacerbates the situation is that with this approach both the users and resources and the administrators, need access to the same directory service, in which the identities are managed. This is a significant restriction in an increasingly Cloud-oriented world, which differs from the service providers in the way in which it organizes the users.
ABAC – Attribute Based Access Control
With ABAC, access to a resource is controlled using attributes of the identity, the resource, the status of the system environment, and other attributes.
First of all, the identity is validated and authenticated with an Identity and Access Management System. Next, the client is provided with the corresponding attributes, which are certified by means of a digital signature. When an identity wishes to access a resource, then both the signature and identities provided are checked. If these are valid, the system checks whether access to the resource concerned is permissible under the rules applying to the attributes.
One example for ABAC would be that only users who are type=employee and have a department=HR will possess access to the HR/payroll system, only during business hours within the same time zone as the company.
Basically, ABAC enables fine-grained access control to be provided that incorporates significantly more parameters/attributes in an access control decision. Each available attribute in the directory can be used either alone or in conjunction with another one in order to define the right access to a resource.
ABAC is not only the most flexible and performatively efficacious of the four access control models but also the most complex. Attribute-based access control is used particularly with new processes like OAuth and OpenID.
RBAC vs. ABAC
1. ABAC is better suited for fine-grained access control
If you can do without fine-grained access control, then RBAC is a good choice. For example, if you want to grant all employees access to Google or all contractual partners access to emails.
If you require more granularity, ABAC is the better choice. For example, if you want to grant access to Google only to employees in a particular location and only at particular times of the day. A role attribute contains the name of a role, the assignment information, plus one (or more) optional parameters. The result is a fine-grained definition of access rights, preventing an explosion of roles, as in the above-cited example.
2. ABAC scales better
An LDAP server is frequently used as a directory service in which the identities are stored. When a user accesses a resource using the RBAC principle, the LDAP server has to parse the access controls in all groups in which the user concerned is a member. In the case of sizeable organizations with numerous users and groups, this may have an adverse effect on performance.
3. Less is more
If you are creating numerous very complex RBAC and/or ABAC filters, then you’re probably doing something wrong. An IAM strategy can help you to structure your directory data in such a way that the necessity of developing complex filters/queries is minimized.
4. Divider and conquer
You can use RBAC and ABAC together in a hierarchical approach. For example, by means of RBAC, you can control who can ever access which applications. With ABAC, you can implement fine-grained control for authorizations inside the application concerned.
Agiles Rollenmanagement mit SecuRole®
SecuRole® is based on ABAC and is an innovative approach to overcoming the limitations of RBAC and making agile role management possible.
SecuRole® – Role management in 4 Steps
- A role is defined by an attribute in a user object. This means user objects can be processed very much more simply and rapidly than long member lists in many different groups. SecuRole® is faster and scales better.
- A role attribute contains the name of a role, the assignment information, and optional parameters. SecuRole® significantly simplifies the specification of fine-grained access rights.
- Each role attribute is defined as a JSON object and can be very easily supplemented, e.g. by the validity date or the approver of a role. SecuRole® is based on standard JSON objects and is easy to implement.
- Each JSON object is digitally signed and can be used as a JSON web token. This makes possible a very high level of security because the role information is trustworthy. Everyone who trusts the signature will also trust the assignment. SecuRole® enhances security.
You will find further information on SecuRole® HERE.