RBAC to ABAC: From Roles to Attributes

01Lab Metadata

02Lab Title and Description

RBAC to ABAC: From Roles to Attributes

For most of its history Northgate Financial has controlled access with roles. A user is a member of finance-team or it-admins, a role grants a fixed set of permissions, and access is decided by asking a single question: does this user have this role? Role-Based Access Control is simple, auditable and widely understood, and for a stable organisation it works well. Then Northgate acquired Harborview Wealth, and the model began to strain. Harborview had its own departments, its own seniority tiers, and rules that depend on things a role cannot capture: a wealth adviser may view a client portfolio only if it belongs to their own book, only during market hours, and only up to their approval limit. Expressing that with roles alone means inventing a new role for every combination, and the number of roles began to grow faster than anyone could govern.

This is role explosion, and it is the classic signal that an organisation has outgrown pure RBAC. The answer is Attribute-Based Access Control (ABAC), described in NIST SP 800-162. Instead of asking only "what role does the user have", ABAC evaluates a policy over attributes of the subject (department, clearance, book of business), the resource (owner, classification, value), the action, and the environment (time of day, network, risk score from Lab 08). One policy can then replace dozens of narrow roles.

In this lab you first model Northgate's access in RBAC and watch the role count balloon as you try to honour the Harborview rules. Then you rebuild the same decisions using Keycloak Authorization Services, defining resources with attributes, and policies over user attributes and time, combined with aggregate logic. Finally you evaluate authorization decisions for two users who hold the same role but get different answers, because their attributes and context differ, the decision RBAC cannot express. You will also see clearly where Keycloak's built-in policies stop and why a dedicated policy engine, the subject of Lab 14, is the next step.

Estimated completion time: 4 to 5 hours, including RBAC modelling, Authorization Services configuration, and decision testing.

03Prerequisites

Completed Prior Labs

System Requirements

Required Tools

sudo apt update
sudo apt install -y python3.11 jq curl

mkdir -p ~/ib-labs/ib-abac
cd ~/ib-labs/ib-abac

python3.11 --version   # Expect: Python 3.11.x
jq --version            # Expect: jq-1.7 or later
docker --version        # Expect: Docker version 25.x or later

brew install python@3.11 jq
mkdir -p ~/ib-labs/ib-abac && cd ~/ib-labs/ib-abac
python3.11 --version
jq --version

# Run inside your WSL2 Ubuntu distribution, not PowerShell
wsl --install -d Ubuntu-22.04
# Then follow the Ubuntu/Debian instructions above.

04Real World Problem Statement

Pure role-based access forces every access rule to be expressed as membership in a group. When rules depend on context, ownership or thresholds, the only way to encode them in roles is to multiply roles until the model becomes ungovernable. ABAC replaces that combinatorial growth with policies that read attributes directly.

Concrete scenario: After absorbing Harborview Wealth, Northgate needed to express: a wealth adviser may read a client portfolio only if the portfolio's owning desk matches the adviser's own desk, and only during UK market hours. In RBAC this became a proliferation of roles like wealth-adviser-desk-a-markethours, one per desk and context combination. In this lab you build that RBAC model, count the roles it demands, then replace it with a single attribute and time policy in Keycloak Authorization Services, and prove two advisers on different desks get different answers for the same portfolio.

05Skills Mapped to Production Solutions

06Architecture Overview

Component Breakdown

Data Flow

1. The enforcement point receives a request to act on a resource and asks Keycloak for a decision using the UMA 2.0 ticket grant, presenting the user's access token.
   Why: delegating the decision to a central PDP means the rule lives in one governed place, not scattered through application code where it drifts out of sync.
2. Keycloak gathers the relevant attributes, the user's attributes from the token and directory, the resource's attributes, and the current time.
   Why: an attribute decision is only as good as its inputs; the PDP must pull from authoritative attribute sources rather than trusting the caller to supply them.
3. Keycloak evaluates the permission's policies, combining an attribute policy and a time policy with aggregate logic, and returns permit or deny.
   Why: combining policies lets one permission express a compound rule ("right desk AND market hours") that would need many roles to approximate.
4. The enforcement point honours the decision. On permit it returns a Requesting Party Token listing the granted permissions; on deny it refuses the request.
   Why: the token gives the resource server a verifiable statement of exactly what was granted, which it can log for audit alongside the decision.

Security Considerations

07Step by Step Implementation

# The Harborview rule: an adviser may read portfolios for their own desk,
# and the permitted action differs in and out of market hours. RBAC forces
# one role per combination. With 4 desks and 2 time contexts that is 8 roles
# for this ONE rule; add an approval-limit tier (3 bands) and it is 24.
for desk in desk-a desk-b desk-c desk-d; do
  for ctx in markethours afterhours; do
    docker exec -it ib-keycloak-1 /opt/keycloak/bin/kcadm.sh create roles \
      -r northgate -s name="wealth-adviser-${desk}-${ctx}"
  done
done

# Count how many roles now exist that encode this single business rule.
docker exec -it ib-keycloak-1 /opt/keycloak/bin/kcadm.sh get roles -r northgate \
  --fields name | jq '[.[] | select(.name | startswith("wealth-adviser-"))] | length'

# Two advisers on different desks. In ABAC these two attributes, plus the
# resource's own desk, express what eight-plus roles tried to encode.
AID=$(docker exec -it ib-keycloak-1 /opt/keycloak/bin/kcadm.sh get users \
  -r northgate -q username=asmith --fields id | jq -r '.[0].id')
JID=$(docker exec -it ib-keycloak-1 /opt/keycloak/bin/kcadm.sh get users \
  -r northgate -q username=jpatel --fields id | jq -r '.[0].id')

docker exec -it ib-keycloak-1 /opt/keycloak/bin/kcadm.sh update users/$AID \
  -r northgate -s 'attributes.desk=["desk-a"]' \
  -s 'attributes.approval_limit=["500000"]'

docker exec -it ib-keycloak-1 /opt/keycloak/bin/kcadm.sh update users/$JID \
  -r northgate -s 'attributes.desk=["desk-b"]' \
  -s 'attributes.approval_limit=["100000"]'

# For a policy to read the desk, it must appear as a token claim. Add a
# user-attribute protocol mapper on a client scope (or the client) so that
# 'desk' is included in the access token.
docker exec -it ib-keycloak-1 /opt/keycloak/bin/kcadm.sh create \
  clients/RESOURCE_CLIENT_UUID/protocol-mappers/models -r northgate \
  -s name=desk-mapper \
  -s protocol=openid-connect \
  -s protocolMapper=oidc-usermodel-attribute-mapper \
  -s 'config."user.attribute"=desk' \
  -s 'config."claim.name"=desk' \
  -s 'config."access.token.claim"=true' \
  -s 'config."jsonType.label"=String'

docker exec -it ib-keycloak-1 /opt/keycloak/bin/kcadm.sh create clients \
  -r northgate \
  -s clientId=portfolio-api \
  -s enabled=true \
  -s protocol=openid-connect \
  -s publicClient=false \
  -s serviceAccountsEnabled=true \
  -s authorizationServicesEnabled=true \
  -s 'redirectUris=["http://localhost:8082/*"]'

# Capture the client UUID (RESOURCE_CLIENT_UUID used elsewhere).
docker exec -it ib-keycloak-1 /opt/keycloak/bin/kcadm.sh get \
  clients?clientId=portfolio-api -r northgate --fields id | jq -r '.[0].id'

# In the Admin Console, Clients, portfolio-api, Authorization tab:
#
# 1) Resources: create "portfolio-desk-a"
#      Type: urn:portfolio:resource:portfolio
#      Scopes: portfolio:read
#      Attributes: desk = desk-a   (the resource's owning desk)
#
# 2) Scopes: confirm "portfolio:read" exists.
#
# 3) Policies: create a Time policy "market-hours"
#      Not Before / Not On or After, or the hour range fields, set to
#      represent UK market hours (for example 08:00 to 16:30). The exact
#      field layout differs by version; the Console shows the current fields.
#
# 4) Policies: create a Regex policy "desk-matches-desk-a"
#      Target claim: desk
#      Pattern: ^desk-a$
#      This permits when the user's desk claim equals desk-a.
#
#      NOTE: a Regex policy compares a claim to a fixed pattern. Comparing
#      the SUBJECT's desk to the RESOURCE's desk dynamically (desk == desk)
#      is beyond built-in policies; that gap is addressed in Step 2.4 and is
#      exactly why Lab 14 introduces an external policy engine.
echo "Author resources and policies in the Authorization tab as described."

# Still in the Authorization tab:
#
# 5) Policies: create an Aggregate policy "adviser-may-read-desk-a"
#      Apply Policy: desk-matches-desk-a AND market-hours
#      Decision strategy: Unanimous (all must permit)
#
# 6) Permissions: create a Scope permission "read-portfolio-desk-a"
#      Resource: portfolio-desk-a
#      Scope: portfolio:read
#      Apply Policy: adviser-may-read-desk-a
#      Decision strategy: Unanimous
echo "Combine policies into a unanimous scope permission as described."

# Get asmith's access token (direct grant for lab convenience).
ASMITH_TOKEN=$(curl -sk -X POST \
  "https://localhost:8443/realms/northgate/protocol/openid-connect/token" \
  -d "client_id=portfolio-api" -d "client_secret=REPLACE_WITH_PORTFOLIO_SECRET" \
  -d "grant_type=password" -d "username=asmith" \
  -d "password=REPLACE_WITH_ASMITH_PASSWORD" -d "scope=openid" | jq -r '.access_token')

# Ask Keycloak for a decision on portfolio:read for the desk-a resource.
curl -sk -X POST \
  "https://localhost:8443/realms/northgate/protocol/openid-connect/token" \
  -H "Authorization: Bearer $ASMITH_TOKEN" \
  -d "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
  -d "audience=portfolio-api" \
  -d "permission=portfolio-desk-a#portfolio:read" \
  -d "response_mode=decision" | jq

JPATEL_TOKEN=$(curl -sk -X POST \
  "https://localhost:8443/realms/northgate/protocol/openid-connect/token" \
  -d "client_id=portfolio-api" -d "client_secret=REPLACE_WITH_PORTFOLIO_SECRET" \
  -d "grant_type=password" -d "username=jpatel" \
  -d "password=REPLACE_WITH_JPATEL_PASSWORD" -d "scope=openid" | jq -r '.access_token')

curl -sk -X POST \
  "https://localhost:8443/realms/northgate/protocol/openid-connect/token" \
  -H "Authorization: Bearer $JPATEL_TOKEN" \
  -d "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
  -d "audience=portfolio-api" \
  -d "permission=portfolio-desk-a#portfolio:read" \
  -d "response_mode=decision" | jq

# If it is currently outside your configured market-hours window, re-run the
# asmith decision from Step 3.1 and observe it now returns false. If it is
# inside the window, temporarily narrow the market-hours time policy in the
# Admin Console to a range that excludes the current time, re-run, then
# restore the correct window.
#
# Alternatively use the Evaluate tool and set a custom evaluation time.
echo "Re-run the asmith decision outside market hours; expect result: false."

08Testing and Validation

End-to-End Test Scenarios

Negative Tests

Common Failure Modes

09Security Analysis

What Makes This Implementation Secure

• Permissions default to deny, so any resource or scope not explicitly permitted is refused, which fails safe when policy coverage has gaps.
• Attributes that drive decisions are surfaced as verifiable token claims issued by Keycloak, not values the requesting client can assert for itself.
• The compound rule uses unanimous aggregate logic, so a decision requires every condition to be met, not merely one.
• Centralising the decision in a PDP means the rule is defined and governed in one place, rather than duplicated and drifting across application code.

What Is Intentionally Simplified for the Lab

• The desk match is hard-coded per resource rather than compared relationally to the subject's desk; true relational comparison needs script policies or an external engine, which Lab 14 provides.
• The direct grant is used to obtain tokens quickly; production uses the authorization code with PKCE flow from Lab 04.
• TLS certificate verification is disabled against ib-lb because it presents a self-signed certificate.
• Resource attributes are set manually in the Console; a production system synchronises resource attributes from the systems that own the data.

Production Hardening Recommendations

10Cleanup

# Delete the combinatorial roles; they existed only to illustrate the problem.
for desk in desk-a desk-b desk-c desk-d; do
  for ctx in markethours afterhours; do
    docker exec -it ib-keycloak-1 /opt/keycloak/bin/kcadm.sh delete \
      roles/wealth-adviser-${desk}-${ctx} -r northgate 2>/dev/null || true
  done
done

# Keep portfolio-api if you intend to reuse it as the enforcement target in
# Lab 14 or Lab 16; otherwise remove it and its resources/policies in one go.
docker exec -it ib-keycloak-1 /opt/keycloak/bin/kcadm.sh delete \
  clients/RESOURCE_CLIENT_UUID -r northgate

12Portfolio Publishing Guide

Sanitise Before Publishing

This lab handles a client secret and user tokens. Confirm none reach your repository.

grep -R "REPLACE_WITH" . --include="*.sh" --include="*.md" || echo "Clean"

cat >> .gitignore <<'EOF'
*.token
.env
EOF

git status

README for the Repository

# IB-SIA-13: RBAC to ABAC

Demonstrates role explosion in a pure RBAC model, then rebuilds the same
access rule as attribute and time based policies using Keycloak
Authorization Services, and evaluates live permit/deny decisions via the
UMA 2.0 grant.

## Stack
Keycloak 24.x (Authorization Services), Python 3.11, curl, jq

## What it demonstrates
- Role explosion: one rule, many combinatorial roles
- ABAC: one policy over subject, resource and environment attributes
- Same role, different decision, driven by attributes and context
- The boundary where built-in policies end and an external engine begins

## Part of the Identity Bytes Senior IAM Architect Track
Lab 13 of 36. See identity-bytes.com for the full curriculum.

Git Commands

git add README.md .gitignore *.sh
git commit -m "IB-SIA-13: RBAC to ABAC with Keycloak Authorization Services"
git push origin main

Track Index Line

Add the following line to your master portfolio index:

IB-SIA-13 | RBAC to ABAC | Intermediate | Role explosion, attribute policies, PEP/PDP/PIP, Keycloak Authorization Services

LinkedIn Draft