Authorization — at Walmart Scale!
Large organizations such as Walmart have various applications needing different degrees of access control ranging from simple role based access control to fine-grained attribute level authorization.
As an example consider the employee contact information database of Walmart. For this database to be accessible by an employee it suffices if the user has been associated with employee role in Walmart’s user database. By virtue of having this role every employee is able to read the contact information of any other employee. Now consider another use case — this time a complex one involving an application running in Pharmacy in Walmart stores. This application has a requirement that the employee dispensing medicines at the counter be above 18 years of age, be on-the-clock while billing the medicines and be trained in Pharmacy.
Additionally, for prescription drugs, the customer purchasing the medicines should be registered in the Walmart database, be above 18 years and have a valid prescription. Adding to the complexity are different rules for different medicines varying across different states. For a sale to be authorized in the pharmacy, all of these rules have to be verified by the application before a valid bill can be generated. These decisions have to be made quickly and millions of such decisions need to be made each day for Walmart’s business to be successful.
The Identity and Access Management (IAM) platform team located out of India Development Center (IDC), Bangalore has been working on developing the next generation of authorization solutions for Walmart. For simple access control requirements we support role-based access control (RBAC). Users in the database or in active directory servers can be linked to roles. Then during login, these roles can be fetched from IAM and based on them a decision of PERMIT or DENY can be inferred by the invoking application. For the complex use cases we support Attribute-based access control (ABAC). The ABAC decision engine implemented by IAM is based on xacml 2.0 standards. Since the xacml 2.0 schema is quite complex, the team has made every effort to simplify it and expose it in the form of REST APIs.
The xacml schema prescribes the following four entities which are linked to form a policy:
1) Subject — the actor performing the operation. Usually this is the role identifier and represents the role the user is linked to.
2) Resource — the resource being accessed such as the file or the url.
3) Action — the operation being attempted on the resource such as read, write or execute.
4) Environment — the environmental constraints in which the user operates. Could be time, temperature, deviceType etc.
Each entity can have multiple attributes. Policies consisting of the above 4 entities are created by an administrator in the IAM database. Each service or application can decide upon the attributes that are significant to it based on its domain. For example a photo sharing application will have image as its resource and add, remove, view, edit and share as its actions. An image might have time, camera, format, geolocation etc. as attributes. A user who added the image will have policies to remove or edit it whereas other users to whom the image is shared will only have policy to view the image.
When a user logs in and attempts to perform some operation the application invokes the decision engine, which then evaluates the policies applicable to the user against the action being performed on the resource. The decision engine’s result should be honored by the application.
IAM team has converted the complex xml policy schema into a json payload. A local Java client which has decision engine and policy cache embedded has been made available for fast decision-making. Since not all clients are on Java we also provided a remote API to invoke the authorization evaluation check. In this case the decision engine will run on IAM server but will perform the decision-making based on the context information about the user passed by the application. The policies have been flattened to allow them to be stored in relational database. Due to this, we have lost some flexibility such as the ability to query policies by any attribute. But we have gained in reliability, availability and scalability that come from using an RDBMS.
In my next blog post I will walk you through a complex authorization use case involving multiple teams collaborating to achieve a customer-centric goal.
