×

IDMWORKS Blog

Federated Identity in the Cloud using Attribute Based Access Control (ABAC)


In the Cloud context, sometimes it is not necessary to have user accounts in both the Identity Provider and the Service Provider. The requesting Identity Provider can categorize users based on groups, roles and other attribute information. So let’s use Attribute Based Access Control (ABAC).

In the Cloud context, sometimes it is not necessary to have user accounts in both the Identity Provider and the Service Provider. The requesting Identity Provider can categorize users based on groups, roles and other attribute information.

Let’s scope this out shall we?

A user has a Purchasing Manager role in the Domain A, which is translated to a role of Customer in the Domain B. In attribute federation, the receiving Identity Provider must be able to read this attribute information from the response sent by the first Identity Provider. This attribute information should then be mapped to authorization information in the receiving end. The attributes that are delivered have a corresponding role or other type of authoritative information in the receiving Identity Provider and this information can create the access control decision.

This is a simple use-case that I hope better defines where and why we used an Attribute Based Access Control (ABAC) method to federate in addition to Role Based Access Control (RBAC).

Questions, comments or concerns? Feel free to reach out to us below, or email us at IDMWORKS to learn more about how you can protect your organization and customers.

Leave a Reply

Your email address will not be published. Required fields are marked *