Attribute-based Access Control (ABAC) Enhancements in Cloud Pak for Data

Authors: Yanni Zhang, Sachin Prasad, Kevin Stumph

A user’s location, which device type they are accessing with, and other attributes may change from login to login. For instance, an employee based in Europe, who may normally have access to data stored in a European data center, may be disallowed by regulations from accessing that same data if they are traveling abroad. Calculating access based on such dynamic properties have been difficult for organizations to involve in access control logic, partly because Identity Providers tend to contain only static attributes in user and group records and because applications tend
not to offer any dynamic alternatives. We are pleased to announce that IBM Cloud Pak for Data includes major enhancements to the platform access control capabilities, attribute-based access control (ABAC), which will enable customers to leverage dynamic attributes as well as a much expanded support for involving Identity Provider defined attributes in CPD access control logic. This document will provide a refresher on ABAC and how it is used in Cloud Pak for Data and will explain the new features in detail through the use of an example.

Quick Summary

Cloud Pak for Data supports the following features:
1. Any attribute from an Identity Provider may be involved in ABAC rules.
2. Custom attributes can be defined as part of the rule assessment for access control.
3. Values from any external custom attribute provider can be used in the rule assessment for access control.

What is ABAC?

ABAC is an access control model that uses attributes as the basis for making access control decisions. Unlike traditional models such as Role-Based Access Control (RBAC) or Mandatory Access Control (MAC) that require roles to be defined to specific users, ABAC takes a more dynamic approach. With ABAC, access policies can adapt on the fly to changing conditions.

In Cloud Pak for Data, ABAC involves several components that work together to determine and enforce access to resources.

Access control policy

Access control policies include a set of dynamic groups that define what actions users can perform on resources in Cloud Pak for Data environment. Unlike static user groups, dynamic groups are formed based on specific attribute conditions. These conditions are evaluated in real-time, and users meeting the criteria are dynamically added to the group. Each dynamic group contains a set of conditions to define access control rules. Rules evaluate attributes associated with a user or entity and determine whether access should be granted or denied. Rules can be based on various attributes, such as user roles, department, time of access, and more.

Attribute source

Attribute sources can be enterprise LDAP servers, or IAM solutions such as IBM Verify, Okta, etc. These identity providers support open standards such as LDAP, OpenID connect, SAML or SCIM. They use open standard APIs to store and retrieve user attributes. A custom attribute provider may also be used to expose attributes from programs or applications, such as HRMS systems. In the latter scenario the HRMS system is serving as the attribute source.

Identity management

Identity Management is a common service in Cloud Pak for Data that provides integration with enterprise identity providers using open standards such as LDAP, Open ID connect, SAML, and SCIM. It uses SCIM interface to provide attribute information to access decision engine.

Custom attribute provider

A custom attribute provider is a REST API server or service defined by the customer that can append attributes that are not part of your primary identity provider (IdP) to a user’s Cloud Pak for Data user profile. Cloud Pak for Data will check with the custom attribute provider on every login, which enables customers to expose attributes defined by their own logic to address dynamic scenarios, such as the country of last login.

Access decision

The ABAC access decision engine evaluates the rules and attributes associated with the user to make a decision on whether to grant or deny access to a particular resource. It considers the conditions defined in the rules, attributes retrieved from the attribute source through identity management, and any additional attributes provided by custom attribute provider. If the attributes satisfy the policies, access is granted. Otherwise, access is denied.

Access enforcement

Once the access decision is made, the access enforcement mechanism ensures that the user can access the desired resources and perform actions that are permitted based on the granted access policies, or the user is given the access denied message for denied access decision.

An ABAC Example

Let’s take a healthcare system data access as a use case. Access to healthcare data is typically governed by strict security and privacy regulations such as HIPAA in US. Data engineers and data scientists may be involved in patient data processing. Access to sensitive patient data may be subject to additional restrictions such as location of the user or device to ensure compliance with access policies and reduce the risk of data breaches or unauthorized access.

User roles/attributes:
— Job role: “Data Engineer”
— Seniority level: “level 1”, “level 2”, “level 3”, “level 4”
— Security and privacy certification: “Complete”, “Incomplete”
— Project assignment: “Genomic Medicine and Treatment”, “Predictive Analytics for Cardiovascular Diseases Prevention”
— Vacation: “true”, “false”

Access control policies:
— Rule 1: if user.job_role equals “Data Engineer”, and if user.project equals “Genomic Medicine and Treatment”, allow access to the project source code.
— Rule 2: if user.job_role equals “Data Engineer”, and if user. security_and_privacy_certification equals “Complete”, give access to de-identified datasets.
— Rule 3: If user.security_and_privacy_certification equals “Complete”, and if user.job_role equals “Data Engineer”, and if user.seniority_level not lower than “level 3”, and if user.project equals “Genomic Medicine and Treatment”, and if user.vacation equals “false”, provide access to patient data.

Scenario steps:

1. User authentication:
   Data engineer Susan logs onto Cloud Pak for Data using MFA.
2. Attribute retrieval:
   The ABAC access decision engine retrieves attributes associated with Susan from Active Directory:
   — Job role: “Data Engineer”
   — Seniority level: “level 4”
   — Security and privacy certification: “complete”
   — Project assignment: “Genomic Medicine and Treatment”
   ABAC retrieves the vacation attribute associated with Susan from the custom attribute provider:
   — Vacation: “false”
3. Policy evaluation:
   ABAC evaluates the policies based on Susan’s attributes:
   — Rule 1 grants access to project “Genomic Medicine and Treatment” repository.
   — Rule 2 grants access to de-identified datasets.
   — Rule 3 grants access to patient data before de-identified.
4. Access decision:
   Susan is granted access to project repository, patient data, and de-identified datasets for Genomic Medicine and Treatment project.

Defining the custom attribute provider

In the example scenario our sample user, Susan, is allowed access to patient data in Rule 3 if and only if she is not on vacation. The thinking in the scenario is that if Susan is on vacation there is a chance that she may outside of the country, which could trigger a HIPAA violation if she accessed patient data outside of the USA.

Susan’s company likely does not save her current vacation status inside the company’s Identity Provider, but that information likely does reside inside the company’s human resources management system or HRMS; the system where Susan inputs her vacation days. To expose her vacation days to Cloud Pak for Data Susan’s company may write a wrapper API around their HRMS system, which can check if she or anyone else in her company is currently on vacation. The wrapper API server that can access the HRMS system is the custom attribute provider. The signature of such a _custom attribute provider_ may look like the one below:

You can see from the image that the custom attribute provider contains an endpoint, /v1/external/usermgmt/attributes, which accepts a parameter for username. The server should have the logic to lookup the username passed in against the HRMS system to determine the current vacation status fo the user. The response must return an attribute map in the form of a JSON object of key / value pairs. In this case only one attribute for Vacation is being returned, but in the general case a server with any logic and even returning several dynamic values could be constructed.

Requirements for the _custom attribute provider_ are the following:

1. A custom attribute provider must provide a GET /v1/external/usermgmt/attributes?username=${username} API.
2. Successful lookup of a user by username must return an HTTP 200 with a JSON object of the attributes CPD should merge into the user record obtained from the Identity Provider.
3. Unsuccessful lookup should still return HTTP 200 with an empty JSON object.
4. The custom attribute provider should provide a token that Cloud Pak for Data can use to authenticate back to the custom attribute provider via the Authorization header as a Bearer token.
5. The custom attribute provider should be protected by a TLS Certificate and that Certificate should be made available to Cloud Pak for Data for authentication.

Cloud Pak for Data may be configured to communicate with the custom attribute provider by defining two objects: a ConfigMap defining an attribute_provider extension point and a Secret named zen-ext-attribute-provider-secret containing the sensitive data of the custom attribute provider token and TLS Certificate.

An example of how to define the attribute_provider extension point is below:

And an example of how to define the zen-ext-attribute-provider-secret Secret is below:

By simply defining these two objects of an attribute_provider extension point and a Secret named zen-ext-attribute-provider-secret, followed by a restart of the usermgmt service pods, Cloud Pak for Data will be fully configured to check with the custom attribute provider on each user login to obtain additional dynamic attributes.

For complete information about defining and configuring a custom attribute provider see the Knowledge Center topic: https://www.ibm.com/docs/SSQNUZ_latest/cpd/admin/manage-attribute-provider.html

Defining dynamic Identity Provider attributes

1. Define SCIM attributes and the mapping to LDAP attributes
You need to follow Adding custom SCIM attributes to add the four attribute types “jobRole”, “seniorityLevel”, “certification”, and “project”.

Once the attribute types are added, they show up in the attribute type drop-down in the SCIM configuration for LDAP connection. Then you define the mapping to the corresponding LDAP attribute type on Identity Provider page and save the change.

2. Edit attributes-configmap configmap to add the defined attributes, restart usermgmt pod to pick up the updated entries in the configmap.

3. On Access Control page, create dynamic user group by following the wizard. In Membership rule panel, create the membership rule. Then in the roles panel, add the corresponding permission to the dynamic group.

Repeat step 3 to create dynamic groups for the other two rules.

Conclusion

This use case illustrates how Cloud Pak for Data provides extensible and user-friendly interface to configure ABAC, and how ABAC could be implemented to control access to sensitive patient data based on a combination of attributes including job role, certification, project assignment, seniority level, and location.

The dynamic nature of ABAC allows for fine-grained access control by considering various attributes of users when making authorization decision, and it also allows flexibility in adjusting access based on changing user attributes and project requirements. ABAC feature in Cloud Pak for Data provides organizations to enhance their access management capabilities and strengthen their overall security posture.