IT administrators know this very well: administering access for a few hundreds of accounts is a challenge, doing this for tens of thousands and including group assignments make this an error-prone process, if not a major headache. What if you need to scale this to millions of users in an extended enterprise or a B2B2C business?

This post introduces the GABAC model for access control (Graph with Attributes Based Access Control). This model resolves this daunting task. Sounds like the holy grail? Read further to see how the GABAC model compares to traditional models and how it builds on them.

This post introduces self-service for access control that easily scales to millions of users. While self-service is typically not associated with the domain of access control and authorisation, the GABAC model enables the enterprise to retain control and governance and to delegate the administration to end users. In fact, GABAC meets security requirements of auditability, accountability and the default-deny principle.

Today’s access models

IT administrators and administrators of SharePoint sites know this very well: administering a few hundreds of accounts is a challenge, doing this for tens of thousands and including group assignments make this an error-prone process, if not a major headache.

It is the movements of employees throughout the org chart that may drive access IT and SharePoint administrators crazy: how to deal with the continuous stream of hires, promotions, mutations, leavers, temporary assignments, interns, students, project roles, etc. In today’s world with the extended enterprise and business-to-consumer interactions: can we cope with millions of consumers? A new access paradigm is needed. One that scales. But one that goes beyond the simplistic consumer identity management solutions or the solutions offered by social networks.

Enterprise access control is typically driven by static access rights in terms of permissions, privileges, entitlements, access groups and authorisation roles. Static access rights are assigned to users via an enterprise directory and manual processes of a back office. This administration model is suitable for a user base of tens of thousands but does not scale to millions of end users. This is why the scope of enterprise access management is in practice limited to staff and close business partners only.

As opposed to enterprise access management, consumer identity management is driven by self-service. The administration problem of “assigning access rights” is hereby typically reduced to a binary “is the user authenticated or not”.

Online social networks have refined the access model and empower users to refine access rights by grouping connected users. This enables sharing of content that is administered by end users. Shared access, however, is limited to media content and the authorisation question is limited to “is my friend”.

Can the self-service paradigm be brought to a new level and address the need for scale need for modern enterprise access?

Let’s discuss known access models such as IBAC, DAC, MAC, RBAC, ABAC and GBAC and introduce graph & attribute based access control GABAC. You can skip the former part and jump to GABAC here.

IBAC

Identity based access control (coined in this post as “IBAC”) refers to the access control adopted by most of public web services. This model simply authorises a user as soon as they are authenticated and recognised. This model is applied by most Consumer Identity Management systems (often referred to as “CIAM”) and adopts a rather binary approach: “the user is authenticated or not”. Refinements may include the requirement for two-factor authentication.

Further authorisation may be enforced by the target application itself. For example a media content server may verify whether the authenticated person has a valid subscription. Due to its simplicity, this access model lacks fine-grained authorisation. Root cause is that it focuses entirely on the identity of the user.

Key advantage of this model is the self-service aspect: users register themselves and set credentials for future recognition. But social media have fairly flat relations and focus on the identity of a person.

What if we extend this model? What if we let people make assertions about themselves as consumer, professional and/or employee. This post introduces GABAC and explains how the model allows self-declared assertions to be used in authorisation decisions (and under which conditions).

DAC

Discretionary access control (“DAC”) lets people manage access to content they own. In enterprise access control, this is often achieved by access control lists (“ACL”) that basically enumerates the users who should get access.

A major challenge of this model, however, is to keep the list of users up to date at all times. Many DAC systems allow the grouping of users as a light-weight means to reduce the burden (e.g. the friends-list in social networks). But while users may complain if they do not have access, they typically do not complain if they have access while they shouldn’t.

What if we extend this model? What if we let people declare their relationships. This post explains how the GABAC model allows these self-declared relationships to be used in authorisation decisions (and under which conditions).

MAC

Mandatory access control (“MAC”) doesn’t permit owners to have a say in who gets access. Instead, a central body assigns access rights. This is done by labelling all resources and all users. Before access is granted to a user, all labels of the user must fit with those of the labelled resource.

Since only the central body can assign labels, they however become a bottleneck. Hence, this model administration does not easily scale to millions of users.

What if we extend this model? What if we adopt the central policy aspect, but instead of simply matching labels of users and resources, we rather apply more general rules? This post explains how the GABAC model engages rules that use self-declared assertions and relationships for authorisation decisions.

RBAC

Role-based access control (“RBAC”) takes more of a real-world approach to structuring access control and has been standardised by NIST in [1]. Access under RBAC is theoretically based on a user’s business roles within the enterprise. In practice, however, RBAC assigns permissions to technical roles which are subsequently assigned to users.

Even though the name suggests “role of the user”, roles must be interpreted merely as a set of permissions. Roles may be rolled up into super-roles which may then get a process connotation. Yet, these super-roles basically remain sets of permissions.

Since RBAC-roles combine a number of permissions, they tend to reflect a function of an application rather than the function of a person. As such, this administration model poses a number of challenges, as researched in [2]:

• because roles are static and assigned at registration, the permissions are given to the user forever, until they are revoked explicitly.
• because roles are static, taking environmental aspects (such as country) into account is a challenge. In fact, roles are often duplicated to include each environmental aspect, which leads to so-called ‘role explosion’.
• because roles are assigned at registration and represent permissions, they cannot be self-serviced and their assignment needs to be reviewed regularly and audited.

What if we extend this model? What if we do not simply assign static permissions to a role, but use the human interpretation of role as an attribute of a person? This post explains how the GABAC model goes far beyond static permissions and roles and adopts rules that use self-declared assertions and relationships.

While RBAC focuses on application-roles, we could focus on the role of an individual relative to the enterprise, relative to digital resources and relative to other users. An authorisation decision could then depend on those relationships.

RBAC supports delegation, whereby the resource owner decides which rights can be delegated to another user. The delegator must thereby possess the rights they are delegating. If authorisation decisions depend on relationships, every user in a relational chain is a delegator (even though it does not imply that they themselves have the rights they are delegating).

ABAC

Attribute-Based Access Control (“ABAC”) works on the basis of attribute/value pairs that can be attached to users, resources and the environment, first introduced by [3]. Access decisions in ABAC are reached using decisions rules, conditions or constraints based on the attribute/value pair architecture

To overcome the issue of static roles, Attributed Based Access Control (“ABAC”) has been introduced. ABAC was first researched in [3] and later standardised by NIST in [6]. ABAC grants access to users through the use of policies which combine attributes together. The policies can use attributes of the user, attributes of the resource and attributes of the context. Unlike the pre-defined roles of RBAC that carry a specific set of permissions associated with them, ABAC applies policies that express a complex Boolean rule set to evaluate many different attributes. Note that ABAC may consider roles defined in a RBAC model as just another attribute.

What if we extend this model? What if we adopt the attribute-based policy aspect, but extend it to the attributes of relationships between users and resources and between users and other users? This post explains how the GABAC model not only uses self-declared assertions about users but equally self-declared assertions about relationships.

GBAC

Traditional access models only consider the relation from a person to an application. Fong et al. [13] analysed shortcomings of such models when it comes to emerging application domains such as healthcare and education where a resource owner and another person are in some form of a relation. In fact, traditional access models typically do not manage relationships between things and relationships between people.

Social media did familiarise consumers with digital relationships: both the inter-relationships and the relationships with their own stories, photos and videos. Gates et al. [10] formalised the access model based on interpersonal relationships.

While rule-based access control of ABAC already resolves some of the static aspects of RBAC, digital services that serve an ecosystem of users need to be much more dynamic and take the ever-changing interrelationships into account. Graph-based access control (“GBAC”) introduced by Carminati et al [12] builds on the generic lattice-based access control model introduced by Koch et al [11]. Carminati takes into consideration the number of users involved in a relationship as well a trust ratio involved in a relationship between users.

The model proposed by Carminati et al, is based on so-called ‘directed graphs’ to establish relations. This directed graph has a number of mathematical properties, e.g.

• ‘inverse closure’ that implies that every relation has an equivalent inverse relation. Example: The relation ‘has caring role for’ has an inverse equivalent ‘is patient of’ so that queries can be done in both directions.

• ‘forward chaining’ that implies that groups of users can be formed to share the relations of that group with its members. Example: The model allows to extend doctor-patient relationships and to link relations to a group of users. This way, people belonging to a team share the patients with which the team is related.

Carminati et al infer authorisation decisions using social relationships. In fact, it is the User-to-User (U2U) relation that determines the authorisation of a user to access a thing. Policies typically evaluate the type, depth and strength of the U2U relation between the user and the thing owner. Considering only U2U relations, however, implicitly assumes an “is owner of” relation from a user to the thing. Access rights to a thing are determined by the U2U relation between the user and the owner.

Alshehri and Sandhu [19] demonstrated that U2U relations are not sufficient and that User-to-Thing (U2T) relations need to be considered. The relation between two users of the same thing entry is a 2-hop U2T relationship.

A traditional U2U approach would lead to a vast growth of relation types and policies. Something similar to what we already know as role explosion from RBAC. By combining and building on the transitivity of U2U with U2T relations, the number of policies can be reduced to a single policy. This policy would basically say that a user is allowed to access a thing, if a path of a specific type between the user and the thing exists. Under this model authorisations are derived from graph traversal algorithms.

Yet, deriving access control decisions require policies to be set. In the context of online social networks it is assumed that things are pictures and postings with a simple access policy established by the social network. There are only few relation types (typically ‘friend’) and user groups (e.g. ‘friend lists’ or ‘circles’). With this limitation, few rules are sufficient to define access control to many objects.

What if we generalise these models and make access control much more refined and dependent on an enterprise’s security policy? This post explains how the GABAC model uses an “enterprise policy” with rules that drives workflows and authorisation decisions solely based on self-declared assertions and self-declared relationships.

GABAC

The GABAC model we propose shares the model of directed graphs with Carminati et al. The GABAC model, however, has some significantly differences. Using relationships alone is not sufficient to enforce various security and privacy requirements that meet the expectation of today’s online communities.

The GABAC model builds on the model proposed by Cheng et all [16] and integrates attribute-based policies into relation-based access control. Its access model allows finer-grained controls that are not available in traditional GBAC nor ABAC.

Firstly, the GABAC model extends the GBAC model to include relation type. It hereby builds on the refinements of Fong et al in [13] to introduce a standard taxonomy of relation types specific to the enterprise. For example, an enterprise can define its own relation types, e.g. ‘has caring role for,’ ‘is family member of,’ ‘is primary contact for,’ ‘is employee of,’ etc.

The relation type is an attribute of the relation and is thus fundamentally different from user attributes. Whereas user attributes are intrinsic to the person, e.g. “I’m a qualified doctor” or “I’m dog lover” or “I’m a certified engineer”, the relation type characterises the relation of a person to a group or a digital resource, e.g. “I’m subscribing to magazine xyz” or “I’m the owner of device abc”.

Secondly, the GABAC model extends the GBAC model to include state. The model of state transitions introduces intuitive invitation and approval workflows. For example, a user can invite another user to establish a relation with a shared object, given the relation that he himself already has and given some other attributes of the user. The user can then accept or reject the relation.

The state of the relation can then evolve from pending to accepted or rejected. For example:

• An enterprise can define an invitation workflow where a nurse has a relation ‘has caring role for’ which entitles her to invite the patient’s mother to have a ‘is family member of’ relation with one of her patients.
• An enterprise can also define a workflow in which a patient is entitled to invite her doctor to establish the ‘has caring role for’ relation with her patient. Or a workflow in which a doctor invites his nurse to confirm the ‘is employee of’ relation with the clinic.

Thirdly, the GABAC model enables self-enrolment workflows whereby a user declares to have a relation with a shared object, which must be confirmed/accepted by another user also having a relation with the shared object and some required attributes. For example, an enterprise can define a workflow whereby a nurse enrols herself as employee of a clinic, which is then confirmed by the responsible doctor. Or a workflow where a daughter can enrol as family member of the patient.

The GABAC model also enables self-healing workflows. For example an expiration workflow, whereby a relation has a limited lifetime and a reminder to renew is sent to the related person. It also allows an exclusion workflow, whereby a relation is deactivated for reasons of unpaid bills, misbehaviour or resignation.

The GABAC model even enables self-serviced segregation of duties. Furthermore, the model enables it to be enforced at the digital resource level. It allows rules to be configured that indicate conflicting relation types for updating records. For example, the is-doctor-of relation may be conflicting with the is-patient-of relation so that a person have both relations to a patient record cannot update his own pathology.

The GABAC model goes further and can even enable self-serviced privilege elevation. A user can temporarily obtain (more) privileged authorisation by activating a pre-approved but suspended relation. To this extent, the GABAC model allows a person to be linked with a pre-approved relation with the state ‘suspended’. The person can then autonomously and temporarily activate this suspended relation. This temporary ‘privilege elevation’ is notified to a second person and/or is to be approved by a second person.

The key question for digital disruptive innovations and for monetising digital transformations is: how to implement fine-grained access control that is scalable, well-governed and easy to use? Using self-administration combined with rule-driven authorisation, the GABAC model implement fine-grained access control that is superscalable:

• Rule-driven workflows to validate self-declared assertions and to orchestrate relations
• Rule-driven scoped access to implement fine-grained authorisation in function of relations, roles, qualifications and more.
• Rule-driven consent enforcement to limit read access to personal details.

While the rules are set by the enterprise, the assertions and relations are made by the people. Moreover, the graph traversal algorithms ensure full traceability of authorisation decisions. This enables audits and facilitates support and investigations.

Conclusion

Even though the GABAC authorisation model builds on the best parts of IBAC, DAC, MAC, RBAC, ABAC and GBAC and on the work of Jin et al [5], the GABAC model is also structurally different:

The GABAC model takes the combination of (a) the enterprise policy, (b) the user’s self-declared attributes and relations and (c) the user’s versioned consents into account, and elaborates on the models above to enable scalable fine-grained authorisation.

References

[1]     Sandhu, Ravi & Ferraiolo, David & Kuhn, D. (2000). NIST model for role-based access control: Towards a unified standard. Proceedings of the ACM Workshop on Role-Based Access Control. Pages 47-63.

[2]     Chen Liang & Crampton Jason, (2009), Set covering problems in role-based access control, Journal Proceedings of the 14th European Symposium on Research in Computer Security (ESORICS), Pages 689-704, Springer Berlin/Heidelberg.

[3]     Eric Yuan and Jin Tong. (2005) Attributed based access control (ABAC) for web services. In Web Services, 2005. ICWS 2005. Proceedings. 2005 IEEE International Conference on.

[4]     Kuhn, D & J. Coyne, Edward & R. the GABAC modelil, Timothy. (2010). Adding Attributes to Role-Based Access Control. Computer. Pages 43, 79-81. 10.1109/MC.2010.155.

[5]     Jin X., Krishnan R., Sandhu R. (2012) A Unified Attribute-Based Access Control Model Covering DAC, MAC and RBAC. In: Cuppens-Boulahia N., Cuppens F., Garcia-Alfaro J. (eds) Data and Applications Security and Privacy XXVI. DBSec 2012. Lecture Notes in Computer Science, vol 7371. Springer, Berlin, Heidelberg.

[6]     Hu, Vincent & Ferraiolo, David & Kuhn, D & Schnitzer, A & Sandlin, K & Miller, R & Scarfone, Karen. (2014). Guide to attribute based access control (ABAC) definition and considerations. National Institute of Standards and Technology Special Publication. Pages 162-800.

[10]   Carrie Gates. Access control requirements for Web 2.0 security and privacy. IEEE Web, 2(0), 2007.

[11]   Koch, Manuel & Mancini, Luigi & Parisi Presicce, Francesco. (2005). Graph-based specification of access control policies. Journal of Computer and System Sciences. 71. 1-33. 10.1016/j.jcss.2004.11.002., November 2004.

[12]   Barbara Carminati, Elena Ferrari, Raymond Heatherly, Murat Kantarcioglu, and Bhavani Thurainsingham (2009). A semantic web based framework for social network access control. In Proceedings of the 14th ACM Symposium on Access Control Models and Technologies (SACMAT’09), pages 177–186, Stresa, Italy, June 2009.

[13]   Fong, Philip. (2011). Relationship-based access control: Protection model and policy language. CODASPY’11 – Proceedings of the 1st ACM Conference on Data and Application Security and Privacy. 191-202. 10.1145/1943513.1943539, January 2011.

[14]   Treharne, Aktoudianakis. (2015). Relationship Based Access Control: Set Theory based expression language. Thesis for the degree of Doctor of Philosophy. Secure Systems Group Department of Computer Science Faculty of Engineering and Physical Sciences University of Surrey, December 2015.

[15]   Wahlstrom E., (2018) Session Integrate Identity With Microservice-Based Applications at Gartner Identity & Access Management Summit in London on 5-6 March 2018.

[16]   Cheng, Yuan & Park, Jaehong & Sandhu, Ravi. (2014). Attribute-Aware Relationship-Based Access Control for Online Social Networks. 10.1007/978-3-662-43936-4_19.

[17]   Cheng, Yuan & Bijon, Khalid & Sandhu, Ravi. (2016). Extended ReBAC Administrative Models with Cascading Revocation and Provenance Support. 161-170. 10.1145/2914642.2914655.

[18]   Bhatt, Smriti & Patwa, Farhan & Sandhu, Ravi. (2017). ABAC with Group Attributes and Attribute Hierarchies Utilizing the Policy Machine. 17-28. 10.1145/3041048.3041053.

[19]   Alshehri, Asma & Sandhu, Ravi. (2016). Access Control Models for Cloud-Enabled Internet of Things: A Proposed Architecture and Research Agenda. 530-538. 10.1109/CIC.2016.081.