In the last article, the most powerful Permission system design Guide (PART 1), basic concepts, RBAC and ABAC model, we have introduced basic concepts and models. In this article, we will talk about ABAC design from a practical perspective, as well as our team’s practice in the field of permission control of complex business.

1. ABAC classic design case analysis

Let’s start with a classic design case that will give you a better understanding of ABAC’s capabilities

In fact, this case is in the final reference article, you can also read, I am combined with my understanding here

AWS IAM permission policy design

Let’s start with a JSON

// It doesn't matter if you don't understand, {"Action":["EditUser", "GetUser"], "Resource":"user:1, 2, 3, 4", "Condition":{ "DateLessThan":{ "acs:CurrentTime":"2021-03-22T17:00:00+08:00" } } }Copy the code

We said in the previous article, the nature of access control is to control an access entities can do, RBAC role through polymerization, very easy to do this, but do a permissions system knows, most of the time and some other conditions, the influence of and the limitation of this person can access any data, if you want to do this, Adding attributes to roles or permissions and then filtering them based on criteria increases complexity exponentially and is not universal. If you look at the JSON above, you can think of it as an access policy, which is called a policy in ABAC. In this policy, the Action element is a collection of API codes, and the Resource element is a collection of accessible resources. The condition element refers to additional conditions, so what this JSON means is that the person bound to the policy can perform the edit and view operation (corresponding to EditUser and GetUser) on four users with ids 1, 2, 3, and 4 before March 22, 2021. You can add conditions and restrict access to data.

This is the design of IAM access policy for AWS. It is only a very simple example, but it is also a very classic design case. Its design idea is derived from XMACL, and the XMACL document is in the end (not recommended for ABAC students, it is too complicated).

In fact, there are many elements in this policy of amazon, far more than a few, and each element is more complex than the one in my example. For example, the following policy represents the permission to obtain all the resources of AlexaForBusiness and the permission to AWS related to it:

{"Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Action": [ "a4b:*", "kms:DescribeKey" ], "Resource": "*" }, { "Action": [ "iam:CreateServiceLinkedRole" ], "Effect": "Allow", "Resource": "*", "Condition": { "StringLike": { "iam:AWSServiceName": [ "*a4b.amazonaws.com" ] } } }, { "Effect": "Allow", "Action": [ "iam:DeleteServiceLinkedRole", "iam:GetServiceLinkedRoleDeletionStatus" ], "Resource": "arn:aws-cn:iam::*:role/aws-service-role/*a4b.amazonaws.com/AWSServiceRoleForAlexaForBusiness*" }, { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DeleteSecret", "secretsmanager:UpdateSecret" ], "Resource": "arn:aws-cn:secretsmanager:*:*:secret:A4B*" }, { "Effect": "Allow", "Action": "secretsmanager:CreateSecret", "Resource": "*", "Condition": { "StringLike": { "secretsmanager:Name": "A4B*" } } } ] }Copy the code

Again, don’t get confused by the JSON. The reason why this strategy contains so many things is usually only known by the designer, but we need to understand how to design it.

2. Permission system design scheme

1. ABAC design essence

As we can see from the previous article, ABAC is designed to satisfy the ability to control whether the requester has a certain operation (API) on the request data under certain conditions. Currently, there is no standard modeling of ABAC (policy is not composed of entities), but generally is the syntax design of policy. This refers to the use of json or XML to describe a policy that is bound to a user or other entity, so that the user or entity has the ability to manipulate certain data under certain conditions.

Why is there no standard modeling for ABAC? The author's experience is that ABAC is mainly a syntactic design, so it can be very flexible. Such flexible relationship is not suitable to be expressed by model and constraint relationship between models. Therefore, at present, the classical design is to use XML or JSON to represent a policy.Copy the code

2. Overview of business background and analysis of design difficulties

The business scenario now is to do a series of SaaS services provide access control permissions system, including the ability to control each user rendering menu at the same time, the requirements, we must be general enough permissions system, and also can be in various complex business scenarios for access control (that is, the authentication service).

Finally there is a very difficult point in this sentence is authentication, because we know that the different business, at the time of authentication tend to be affected by the business characteristics, but our permission system cannot integrate all these business characteristics, on the one hand to do this permission system, it is not common, and on the other hand, if you do, Each time a business is connected, it must adapt to the business logic of the new business, and the complexity increases exponentially over time, making the system almost impossible to maintain with multiple parties.

This is where our ABAC comes in handy.

3. Design ideas of ABAC

Faced with such a scenario, how should we design ABAC? Let’s look at our syntax design:

{
    "effect":"Allow",
    "actions":[
        "getUser",
        "updateUser",
        "get*"
    ],
    "resources":[
        "contextField:contextValue:resourceField:resourceValue"
    ],
    "condition":[
        {
            "operation-name":{
                "condition-key":[
                    "condition value"
                ]
            }
        }
    ]
}
Copy the code

Among them, the action part is API, the resource is mainly the constraint of various business conditions and business data, and the condition part is mainly the constraint of various time and geographical location at present. We can see that the condition part can be closed loop by the permission system itself. The resource section is business-dependent, so let’s focus on the syntax of the resource section:

In case you get confused, let me explain why the condition partial permission system can be closed loop by itself. This is because the condition part of our permission system is designed as some common conditions, such as time. If the current request can only be accessed from 8 am to 9 PM, you can obtain the current time of the request and compare it with the condition Value in the policy. Here is a json constraint for time:  { "effect":"Allow", "actions":[ "getOrder" ], "resources":[ "contextField:contextValue:resourceField:resourceValue" ], "Condition ":[{"DateLessThan":{"CurrentTime":["2021-03-30 17:00:00" // Must be less than 2021-03-30 17:00:00]}}]} "condition":[{"DateLessThan":{"CurrentTime":["2021-03-30 17:00:00" // Must be less than 2021-03-30 17:00:00]}}Copy the code

Then we look at the grammar of the resource design, here I’ll throw a business scenario, now have a customer service SaaS system, USES a tenant mode, there are a lot of businesses, under each tenant every businessman have a lot of the personnel of the service, which means that each tenant has a main business, some things are only the main businesses are in the system can do. How can we design our JSON? Let’s look at the following example:

{"effect":"Allow", "actions":["getOrder"], "resources":["isMain:1:orderId:12345" // must be the main merchant, And only access order with orderId 123456], "Condition ":[{"DateLessThan":{"CurrentTime":["2021-03-30 17:00:00" // Must be less than 2021-03-30 17:00:00]}}]} "condition":[{"DateLessThan":{"CurrentTime":["2021-03-30 17:00:00" // Must be less than 2021-03-30 17:00:00]}}Copy the code

So let’s focus on the resource, “isMain:1:orderId:12345”, so isMain is a business field, and it means whether or not the main merchant, 1 means the main merchant, So this JSON means that the merchant where the user is located must be the main merchant and the access time must be earlier than 2021-03-30 17:00:00 to obtain the order with ID 12345 (getOrder means to obtain the order). After the user is bound to our policy, the user can be authenticated in this way.

But you’re smart enough to notice that how does the permission system know if the current visitor’s business is the master business? This is a super important question, there are a lot of access systems that go into a pit, what is the pit? We cannot rely on the business system for permission control, otherwise we have to develop every time a business system is connected. In addition, the complexity will increase exponentially with the increase of business systems, which is unacceptable. So what did we do? We observed, general this class is important attribute, is in the front page before initiating, has looked at the merchant’s information, then make a business system front-end bring these business attribute in the policy is in the request header, permissions system can according to these data and the policy to do at this time, so as to complete the authentication, and, In this way, the amount of business system modification is very small.

You must have found some common design technique but didn't know what it was, right? I am generous to tell you again that policy is just like the agreement we made with the permission system. The resource part is to tell the permission system that I will use these business fields for authentication, and then I will bring these values when I request, and the permission system can calculate themCopy the code

4. Advantages and disadvantages of RBAC and ABAC

As we said in the previous article, RBAC can struggle with complex scenarios, but is there any benefit to it? The answer is, of course, the benefits of obvious is simple and easy to understand, it is easy to imagine, generally not the developer of the user to create a role how easy it is, but if you let him to write a strategy of json, he even want to ‘criticisms, because ordinary people simply don’t know why the json is, so could not be written json.

The advantage of ABAC is the disadvantage of RBAC. It can be used for authentication in complex scenarios, but have you noticed the absence of menu information in JSON? To be more specific, if your system is using a pure ABAC permission model, then, Is your system does not have the user the ability to render the menu, then sure, some say, I can a person’s binding by strategy (ABAC policy are generally assigned to a person) to calculate the he can access all of the API and API is bound to render the menu, this idea is wrong, on the one hand, Is dynamic because of the policy in some conditions, such as time, if purely by calculation, so this moment and the moment to see the menu is likely to be different, because of time may also be a kind of condition), on the other hand is that the API and the menu is often not one-to-one correspondence relationship, that is, API may bind multiple menu above, This is where granularity comes in.

5. RBAC and ABAC selection and combination

Combined with the above business, we will analyze our requirements. What we need to do is as follows:

  • To provide a unified authentication service to meet the requirements of various services
  • Controls menu rendering capabilities of business systems
  • Do not show too much complexity to users
  • The cost of business transformation is low enough to allow the original business system to use our authority system
  • Do not interact too much with the business system

In order to meet the above requirements at the same time, we combined RBAC and ABAC capabilities, roughly modeled as follows:

Note that this is not database modeling, but a DDD modeling, I can not explain the specific, and then explain it involves trade secrets, you can refer to this design, you can also ask me for further communication.

Reference article:

1. ABAC – Access control solution in complex Scenarios

2. Amazon Cloud AWS permission policy document

3. Aliyun RAM permission policy document

4. Some guiding thoughts of NIST on ABAC design

5. AWS senior engineer explains ABAC

6. Some guiding thoughts of NIST on NGAC

7. An implementation case of NGAC

Xacml (IBM’s implementation of ABAC) documentation

9. RABAC’s model idea