Pentaho Academy Beta site ..
Start your 30-day Pentaho Enterprise Evaluation ..

AW Roles & Attributes

Keycloak custom Roles & Attributes ..

Keycloak Custom Roles

Custom roles in Keycloak provide the identity federation layer that supports PDC's data governance framework. By creating Adventure Works specific roles in Keycloak, we establish the foundation for audit trails, regulatory compliance, and business-aligned data access controls that meet GDPR, CCPA, and SOX requirements.

Keycloak custom role attributes are powerful metadata fields that enable sophisticated authorization logic and fine-grained access control.

  1. Log into Keycloak:

https://pdc.pentaho.lab/keycloak/adminpdc.pentaho.lab
Link to Keycloak Admin

Username: admin

Password: admin

Ensure you select the Pentaho Data Catalog Realm.

  1. Select: Realm Roles:

  2. Enter the following:

Role name: aw-system-administrator

Description: Adventure Works enterprise data governance with full compliance oversight.

Role: aw-system-administrator

  1. Click Save.

  2. Click on Attributes.

Add attributes

  1. Add the following attributes:

aw-system-administrator

Key
Value

business_function

data_governance_administration

compliance_scope

gdpr,ccpa,lgpd,sox

data_access_level

governance_oversight

audit_category

administrative

retention_policy

permanent_governance_records

Keycloak Role Attributes in PDC

Role attributes are metadata key-value pairs attached to Keycloak roles that enable sophisticated, policy-driven authorization beyond simple role names. Instead of just checking "does user have data-steward role?", PDC can now ask "does this data steward have authority for confidential data in North America during business hours?"

Role attributes transform static permissions into intelligent, context-aware policies. They allow PDC to enforce complex business rules like data classification levels, geographic restrictions, time-based access, approval workflows, and compliance requirements—all without hardcoding logic into the application.

Adventure Works Example

Consider Sarah Johnson, a Sales Manager at Adventure Works:

{
  "name": "adventureworks-sales-manager",
  "attributes": {
    "data_classification_access": ["public", "internal", "confidential"],
    "geographic_scope": ["north-america"],
    "department_access": ["sales", "marketing"],
    "business_hours_only": ["true"],
    "approval_authority_level": ["2"],
    "can_modify_business_terms": ["true"]
  }
}

When Sarah logs into PDC, these attributes automatically determine that she can:

  • Access confidential customer data (but not restricted financial projections)

  • View sales and marketing data sources in North America only

  • Curate business glossary terms for her department

  • Approve data access requests up to level 2

  • Only access the system during business hours (9-5 EST)

The JWT token carries these attributes, enabling PDC to make real-time authorization decisions: "Can Sarah access the European customer database at 10 PM?" → No (geographic scope + time restrictions). "Can she approve a contractor's request for internal sales data?" → Yes (approval authority level 2, internal classification).

This approach eliminates complex authorization code, centralizes business rules in Keycloak, enables compliance automation, and scales effortlessly as Adventure Works grows across regions and departments.

aw-system-administrator attributes

  1. Click: Save

PDC can read these attributes from JWT tokens to make fine-grained authorization decisions. The compliance_scope attribute enables jurisdiction-specific access controls, while audit_category supports automated compliance reporting.

  1. Repeat to create the roles and add the attributes:

AW Data Steward

x

  1. Click: Create role

  2. Enter: Role name: aw-data-steward

  3. Description: Adventure Works cross-domain data quality and governance oversight

Key
Value

business_function

data_stewardship

compliance_scope

gdpr,ccpa,data_quality

data_access_level

metadata_governance

audit_category

stewardship

retention_policy

7_years_governance

Quick recap: We've now created our AW Groups that map to the structure of the business units.

Created Custom Roles with Attributes, so for example - once we've completed the next activity - when Sarah joins as a Sales Analyst, we just add her to the Sales_Analysts group and she automatically gets all the necessary permissions.

No individual role management needed.

Adventure Works Groups & Roles

Role Attribute Suggestions:

So what's missing?

  • HR_Managers

  • Sales_Managers

You should assign appropriate roles to HR_Managers and Sales_Managers groups to complete your role structure.

aw-sales-manager (new role):

{
  "compliance_scope": ["gdpr_legitimate_interest", "ccpa_business_purpose"],
  "data_domains": ["sales", "customer", "product_catalog", "revenue_analytics"],
  "data_access_level": ["sales_management_oversight"],
  "retention_policy": ["7_years_customer_relationship"],
  "business_function": ["sales_management"],
  "audit_category": ["management_analytics"],
  "special_permissions": ["team_performance", "revenue_forecasting"]
}

aw-hr-manager (new role):

{
  "compliance_scope": ["gdpr_employment_data", "employment_law"],
  "data_domains": ["human_resources", "employee_personal_data", "performance_data"],
  "data_access_level": ["hr_management_oversight"],
  "retention_policy": ["30_years_employment_law"],
  "business_function": ["human_resources_management"],
  "audit_category": ["employee_management"],
  "special_permissions": ["performance_reviews", "compensation_management"]
}
PreviousAW GroupsNextAW Roles to Groups

Last updated

Was this helpful?