Communities

Fine tune authorization to assets ..

Data Catalog Communities

In this hands-on workshop, you'll learn how to create and configure PDC Communities that provide fine-grained, business-aligned data access control beyond standard roles. We'll walk through establishing Adventure Works-specific communities that mirror your organizational structure and demonstrate how Communities work with Keycloak roles to create comprehensive data governance authorization—completing the "WHAT" component of your WHO + WHAT identity federation architecture.

By the end of this workshop, you will be able to:

• Create business-domain Communities in PDC that mirror organizational structure

• Configure Community permissions using PDC default roles (Business User, Data User, Data Steward, etc.)

• Assign users to Communities based on their business function and data access needs

• Understand how Communities provide business-context-specific access control within PDC

• Map organizational roles to appropriate PDC permission levels

• Create layered security where Keycloak handles authentication and PDC Communities control data access

• Configure multi-role users who need access across different business domains

Workshop Community Structure: You'll create four key Adventure Works Communities:

• AdventureWorks_Sales_Analytics - Data User role for sales team analysis and customer insights

• AdventureWorks_Data_Governance_Council - Data Steward role for cross-domain governance oversight

• AdventureWorks_Compliance_Officers - Business Steward role for regulatory monitoring and audits

• AdventureWorks_System_Administrators - All Roles for complete administrative capabilities

Authorization Model

This workshop demonstrates how PDC uses your JWT tokens from Keycloak for authentication, then applies Community-based authorization to control access to specific data assets, glossaries, and actions. Users automatically receive their Adventure Works custom roles (like aw-sales-analyst) plus default PDC baseline permissions, with Communities providing the business-context layer that determines exactly what data they can access within their domain.

---

Data Catalog Default Roles

Data Catalog provides default user roles with role-based permissions that enable administrators to control access as necessary across Data Catalog. These permissions are distributed across two tiers of licensed users: Business Users, and Expert Users, as needed.

Administrators can also fine-tune access by creating communities of users to which they assign permissions, such as access to specific data source types or business glossaries.

A Community is a custom role used to fine-tune access to specific actions or Data Catalog assets. For example, you can use a Community to restrict access for a group of users to a subset of glossaries and data sources.

At least one role or Community must be assigned to a user when the user is created. Multiple roles or Communities can be assigned to a user, if the permissions granted are mutually exclusive and are not derived from the same default role.

Your software license determines user-based entitlement.

Business Users

Business Users

The first tier of licensed users is Business Users, including two roles with differing permissions.

The following table shows the default access permitted for a user with the Business User or Data User role. For example, a user with the Business User role can view business glossaries but cannot view data sources. The Data User role has all the access of a Business User, plus access to data associated with the user's specific line of business.

The data can be masked when deemed sensitive or confidential.

Role	Permissions
Business User	Can view business glossaries and policies. Cannot view data sources.
Data User	Can view applications, business glossaries, business intelligence, data sources (view, add content, delete content, view dashboard), and policies.

Expert Users

Expert Users

Role	Permissions
Admin	Can view and modify administration. Can view applications, business glossaries, business intelligence, data sources, domain assets, MDM data sources, match & merge (metadata) rules, and policies. Can view, modify, export, apply rules, approve records, and run engine for domain assets.
Data Storage Administrator	Can view applications, business glossaries, business intelligence, business rules, data identification methods, data sources (view, create, view samples, update, run jobs, apply rules, assign relationships, delete, import, export, add content, delete content, view dashboard, view storage reports), and policies.
Data Developer	Can view applications, business glossaries, business intelligence, data sources, domain assets, MDM data sources, match & merge (metadata) rules, and policies. Can view, create, update, delete, import, and export business rules. Can view, modify, export, apply rules, approve records, and run engine for domain assets.
Business Steward	Can view applications, business glossaries (view, create, update, delete, import, export), business intelligence, data sources (view), and policies (view, create, update, delete, import, export).
Data Steward	Can view, create, update, delete, import, and export applications. Can view business glossaries and business intelligence. Can view, create, update, delete, import, export, add content, apply rules, delete content, assign relationships, run jobs, view dashboard, and view samples for data sources. Can view, create, update, delete, import, and export business rules, data identification methods, and reference data. Can view, apply rules, and approve records for domain assets. Can view and modify match & merge (metadata) rules. Can view policies.

As soon as log in all the AW Users will be added to PDC. These users will have a JWT Token which will have their AW Role [aw-sales-analyst] + Default PDC Role [default-roles-pdc].

The default-roles-pdc functions similarly to a guest role, but it's actually a composite role that provides basic authenticated user access. Looking at your realm configuration, default-roles-pdc includes offline_access, uma_authorization, and basic client roles like view-users, manage-account, and view-profile. This gives authenticated users minimal baseline permissions - more than a true guest but far from privileged access.

If we take a look at the JWT Token for David Park:

JWT - David Park - Compliance Officier

If every user in the PDC is assigned default-roles-pdc, why bother creating AW custom roles?

You raise an excellent point ..!

The custom roles provide governance and compliance metadata that Communities alone cannot deliver. Your Adventure Works roles contain rich compliance attributes like compliance_scope: ["gdpr", "ccpa"], data_domains: ["sales", "customer"], and retention_policy: ["7_years"]. These attributes can be used by other systems, audit tools, and compliance reporting - not just PDC. Communities are PDC-specific containers, while Keycloak roles can be consumed by multiple applications.

Custom roles enable consistent authorization across your entire ecosystem. If Adventure Works users need to access other applications beyond PDC (reporting tools, databases, APIs), the Keycloak roles provide a consistent identity that travels with the user. Communities only work within PDC, so you'd need separate authorization mechanisms for each additional system.

The approach you're suggesting could work for a PDC-only environment: Users get default-roles-pdc → Join appropriate PDC Communities → Get domain-specific access through Community membership. This would be simpler to manage and reduces the number of moving parts.

However, the hybrid approach (Keycloak roles + PDC Communities) provides maximum flexibility and governance. You get fine-grained business domain control (Communities), compliance metadata (custom roles), functional permissions (PDC roles), and extensibility to other systems. The trade-off is increased complexity.

---

Adventure Works Communities

Communities in Pentaho Data Catalog are custom organizational containers that provide fine-grained access control beyond standard roles. A community is a custom role that is used to fine-tune access to specific actions or Data Catalog assets. For example, you can use a community to restrict access for a group of users to a subset of glossaries and data sources. They enable business-aligned data governance by organizing users around specific business domains or organizational units.

Communities allow you to create logical boundaries that mirror your business structure. You can create named communities, such as US Business Users or Commercial Lending Business Users to fine-tune the actions users can perform, as well as to allow access to a subset of glossaries and data sources. In your Adventure Works context, you might create communities like "Adventure Works Sales Community" or "Adventure Works HR Community," where each has access to specific data sources and business glossaries relevant to their domain.

Communities work alongside your Keycloak roles to provide layered security. Your Keycloak roles handle authentication and basic permissions, while PDC Communities provide business-context-specific access control within the data catalog itself. At least one role or community must be assigned to a user when the user is created. Multiple roles or communities can be assigned to a user, if the permissions granted are mutually exclusive. This creates a comprehensive security model where users get both functional access (via Keycloak roles) and domain-specific data access (via Communities).

PDC uses Keycloak for authentication. Once authenticated PDC, based on your role, authorizes access to the PDC assets and actions. The only way to grant this authorization is through the combination of Communities + mapped to PDC Default Roles.

Community	Schema	PDC Default Role	Description	Users
AdventureWorks_Data_Governance_Council	All	Data Steward	Cross-domain data stewardship and governance oversight.	elena.rodriguez
AdventureWorks_System_Administrators	All	All the Roles	Full Data Catalog administrative capabilities for system management.	james.lock
AdventureWorks_Datasource_Administrators	All	Data Storage Administrator	Adventure Works data source administrators.	hugo.reilly david.park
AdventureWorks_Sales_Analytics	Sales + Person	Data User	Sales team data analysis and customer insights.	sarah.johnson
AdventureWorks_Compliance_Officers	All	Business Steward	Regulatory compliance monitoring and audit management.	david.park
AdventureWorks_HR_Specialist	HumanResources	Business User	HR Specialist	michael.chen

1. Log into PDC:

https://pdc.pentaho.labpdc.pentaho.lab

Username: [email protected]

Password: Welcome123!

1. Go to: Management > Users & Communities

2. Click: Add New > Add Community

Add Communities

1. Based on the table above, enter the following details - refer to the table above:

1. Click: Add Users.

1. Add: sarah.johnson

Select user

1. Click: Done.

2. Repeat to create the rest of the Communities ..

AW Communities

The Community names in PDC must exactly match what you expect in your JWT tokens. If you plan to use the group path for Community assignment, PDC needs to understand the mapping.

---

Users with multiple PDC Roles

1. Click on the Pen to edit the User

Edit the User

1. Click: Add Roles

Add Roles

1. Select the required Roles > Done - Save.

Note: The initial Data Catalog mapped role isn't displayed ..

---

Test AW Login

It's going to need fine tuning .. with Permissions & Scope

1. Log into PDC:

https://pdc.pentaho.labpdc.pentaho.lab

Username: [email protected]

Password: Welcome123!

Test Data Catlog role mapping

The role has restricted access & permissions to the aw-hr-specialist role, which is mapped to the Data catlog Business User Role.

---