In a recent project, funded and supported by IoT-NGIN, we sought to provide an access control solution for IoT digital twins. To achieve this, we had to face two important challenges:
- Support for transitive authorizations: For example: If Company A is allowed to access Smart Home 1 and Smart Lamp 1 is in Smart Home 1 then Company A can also access Smart Lamp 1.
- Support for authorization chains: For example: If Company A is allowed to access Smart Home 1 and employee Alice is authorized by Company A then, employee Alice can access Smart Home 1.
From the description of the challenges, it appears that Relationship-Based Access Control (ReBAC) is suitable for formulating the above relationships.
Relationship-Based Access Control
The term Relationship-Based Access Control (ReBAC) was initially coined by Dr. Carrie E. Gates in a 2007 article and it was later formalized by many research efforts. In our system we relied on Google’s Zanzibar and its open-source implementation OpenFGA.
In ReBAC authorization rules are expressed as relations between users and objects. Then, access control decisions are implemented as queries of the form “is user X related to object Y with relation R?”. Accordingly, OpenFGA allows the creation of authorization models that include types and relations supported for each type. For each relation a name and the allowed users are defined. A user can be a predefined type, or a set of users that have a specific relation with another object, or a set of users inherited by another relationship of this object, or combinations of all these. For example our system defines the following model:
Let’s focus on the type resource that represents all digital twins and the can_access relation that represents all users that can access a digital twin. The semantics of this relation definition are: an object of type resource can be accessed by
- a user of type company, or
- a user that has authorized relation with an object of type company, or
- a user that has can_access relation with another object that has parent relation with the object.
As a next step, this model is populated with tuples of the form [type:user, relation, type:object_id], where user can be either a user_id or a set of users that have a relation with an object, defined by object_id#relation_id. For example, these are two valid tuples that can be inserted in our model
[“employee:Alice”, “authorized”, “company:Acme”]
[“company:Acme#authorized”, “can_access”, “resource:Camera1” ]
From this point on, the model can be used to respond to queries. For example, if we query our model “is employee:Alice related to resource:Camera1 as can_access?” we will receive a positive answer. Our example model can be found in OpenFGA playground here (enter any store name and press CREATE).
However, maintaining a complete and always up-to-date authorization model at a single, centralized point is neither secure nor scalable. Imagine for example if all companies had to keep up-to-date lists of authorized employees in multiple locations. In order to overcome this issue, we created a system where users maintain their relations in the form of Verifiable Credentials; users wishing to get authorized include the appropriate Verifiable Credentials in a structure known as Verifiable Presentation. Then, a Policy Decision Point validates the provided presentation, extracts user relationship, constructs an authorization model, and makes an access control decision.
Verifiable Credentials
Verifiable Credentials (VCs) are a W3C recommendation that allow an issuer to assert some attributes about an entity referred to as the VC subject. A VC includes information about the issuer, the subject, the asserted attributes, as well as possible constraints (e.g., an expiration date). A VC is usually stored in a secure enclave, referred to as the wallet. Then, a VC holder (usually, the VC subject itself) can prove to a verifier that it owns one or more VCs with certain properties. This is usually achieved by including in the VC an identifier that enables the holder to generate a Verifiable Presentation (VP) of the VC(s), i.e., an object that includes the desired VC(s), signed in a way that can be verified using the subject identifier of the included VC(s). VP verification does not require communication with the issuer. The VC data model allows different VC types, which define the attributes a VC should include. This provides great flexibility, since VC integrators can define their own types that fit the purposes of their systems.
In our system, we are using Decentralized Identifiers as subject identifiers, also a W3C recommendation. A Decentralized Identifier (DID) is a new type of self-administered, globally unique identifier, which is resolvable and cryptographically verifiable. These properties are achieved by associating a DID with a DID document, which includes public keys and auxiliary information that can be used to securely link the DID to its owner. Additionally, we define a new type of Verifiable Credential, which we referred to as RelationsCredentials. This type includes relations that the credential subject has with objects.
VC-based authorization
In order for users to get access to protected resources they have to create a Verifiable Presentation (VP) that contains the appropriate Verifiable Credentials (VCs). This VP is handled by a verifier module, which validates it, extracts the included relations, and makes the authorization decision. For example, in the following figure Employee Alice wishes to access resource Camera1. She creates a VP that includes:
- A VC that defines that Company A is related to Camera 1 with can_access relationship
- A VC that defines that Alice is related to Company A with authorized relationship
The verifier needs to perform (among others) the following verifications:
- Verify that the first VC is issued by the owner of Camera 1
- Verify that the second VC has been issued by the same Company included in the relationship (highlighted in yellow)
- Verify that the VP is signed by the subject of the second VC (i.e., employee Alice, highlighted in green)
If all verifications succeed the user is considered authorized.
Final thoughts
This was a high-level description of our system. Our completed solution includes a Web-based wallet, where users can store their Decentralized Identifiers and Verifiable Credentials, as well as Issuing and Verification components that implement OpenID for Verifiable Credentials specifications. Here are some key takeaways:
- ReBAC is a powerful paradigm. The fact that the object of a relationship is defined, removes ambiguities and results in simpler and more secure Policy Decision Points. Furthermore, Zanzibar’s authorization model enables modeling of transitive and delegated authorizations in a straightforward way.
- OpenFGA is an easy to use tool that facilitates the development of ReBAC-based systems. Our system relied on contextual-based queries for perfoming authorization queries using the relationships included in the provided Verifiable Credentials. That enabled fast and secure model queries.
- Verifiable Credentials can be used for expressing relationships. A powerful feature of the Verifiable Credentials data model is that the issuer is not involved in the verification process. This, not only allows the issuer to be offline or unreachable during the verification process and provides privacy for the holder with respect to the issuer, but also enables use cases where a user should collect multiple credentials from multiple issuers and use all of them for getting verified.
- The Verifiable Credentials data model does not specify how a Verifiable Presentation is validated by a verifier. As a consequence, systems that are using advanced forms of Verifiable Presentations (like our system) need to implement their own ad-hoc validation protocol.
