# Communities

{% hint style="success" %}

#### 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

{% endhint %}

{% hint style="info" %}

#### **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.
{% endhint %}

***

{% hint style="info" %}

#### 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. 
{% endhint %}

{% tabs %}
{% tab title="Business Users" %}
{% hint style="info" %}

#### 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.
{% endhint %}

<table><thead><tr><th width="145">Role</th><th>Permissions</th></tr></thead><tbody><tr><td><strong>Business User</strong></td><td><p>Can view business glossaries and policies.</p><p>Cannot view data sources.</p></td></tr><tr><td><strong>Data User</strong></td><td>Can view applications, business glossaries, business intelligence, data sources (view, add content, delete content, view dashboard), and policies.</td></tr></tbody></table>
{% endtab %}

{% tab title="Expert Users" %}
{% hint style="info" %}

#### Expert Users

{% endhint %}

<table><thead><tr><th width="158">Role</th><th>Permissions</th></tr></thead><tbody><tr><td><strong>Admin</strong></td><td><p>Can view and modify administration.</p><p>Can view applications, business glossaries, business intelligence, data sources, domain assets, MDM data sources, match &#x26; merge (metadata) rules, and policies.</p><p>Can view, modify, export, apply rules, approve records, and run engine for domain assets.</p></td></tr><tr><td><strong>Data Storage Administrator</strong></td><td>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.</td></tr><tr><td><strong>Data Developer</strong></td><td><p>Can view applications, business glossaries, business intelligence, data sources, domain assets, MDM data sources, match &#x26; merge (metadata) rules, and policies.</p><p>Can view, create, update, delete, import, and export business rules.</p><p>Can view, modify, export, apply rules, approve records, and run engine for domain assets.</p></td></tr><tr><td><strong>Business Steward</strong></td><td>Can view applications, business glossaries (view, create, update, delete, import, export), business intelligence, data sources (view), and policies (view, create, update, delete, import, export).</td></tr><tr><td><strong>Data Steward</strong></td><td><p>Can view, create, update, delete, import, and export applications.</p><p>Can view business glossaries and business intelligence.</p><p>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.</p><p>Can view, create, update, delete, import, and export business rules, data identification methods, and reference data.</p><p>Can view, apply rules, and approve records for domain assets.</p><p>Can view and modify match &#x26; merge (metadata) rules.</p><p>Can view policies.</p></td></tr></tbody></table>
{% endtab %}
{% endtabs %}

{% hint style="warning" %}
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].&#x20;

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:
{% endhint %}

<figure><img src="/files/ydzyfHhNbPu2yzdyynEs" alt=""><figcaption><p>JWT - David Park - Compliance Officier</p></figcaption></figure>

<details>

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

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.

</details>

***

{% hint style="info" %}

#### 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.
{% endhint %}

<table><thead><tr><th width="358">Community</th><th width="107">Schema</th><th width="165">PDC Default Role</th><th width="308">Description</th><th width="149">Users</th></tr></thead><tbody><tr><td>AdventureWorks_Data_Governance_Council</td><td>All</td><td>Data Steward </td><td>Cross-domain data stewardship and governance oversight.</td><td>elena.rodriguez</td></tr><tr><td>AdventureWorks_System_Administrators</td><td>All</td><td><strong>All the Roles</strong></td><td>Full Data Catalog administrative capabilities for system management.</td><td>james.lock</td></tr><tr><td>AdventureWorks_Datasource_Administrators</td><td>All</td><td>Data Storage Administrator</td><td>Adventure Works data source administrators.</td><td>hugo.reilly david.park</td></tr><tr><td>AdventureWorks_Sales_Analytics</td><td>Sales + Person</td><td>Data User</td><td>Sales team data analysis and customer insights.</td><td>sarah.johnson</td></tr><tr><td>AdventureWorks_Compliance_Officers</td><td>All</td><td>Business Steward</td><td>Regulatory compliance monitoring and audit management.</td><td>david.park</td></tr><tr><td>AdventureWorks_HR_Specialist</td><td>HumanResources</td><td>Business User</td><td>HR Specialist</td><td>michael.chen</td></tr></tbody></table>

1. Log into PDC:

{% embed url="<https://pdc.pentaho.lab>" %}

Username: <admin@hv.com>

Password: Welcome123!

2. Go to: Management > Users & Communities
3. Click: Add New > Add Community

<figure><img src="/files/Iy2HRDeEAtkNA1IvOFlL" alt=""><figcaption><p>Add Communities</p></figcaption></figure>

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

<figure><img src="/files/rLN99GNMwedQcgEQXXHw" alt=""><figcaption></figcaption></figure>

5. Click: Add Users.

<figure><img src="/files/u56CnIAnsBSSeoROyonP" alt=""><figcaption></figcaption></figure>

6. Add: sarah.johnson

<figure><img src="/files/2pGmV81u1CrPWGOFr2oS" alt=""><figcaption><p>Select user</p></figcaption></figure>

7. Click: Done.
8. Repeat to create the rest of the Communities ..

<figure><img src="/files/u402DExtBQAQw8dCxLZH" alt=""><figcaption><p>AW Communities</p></figcaption></figure>

{% hint style="warning" %}
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.
{% endhint %}

***

#### Users with multiple PDC Roles

1. Click on the Pen to edit the User

<figure><img src="/files/QCcinbheNavk7UqVgJha" alt=""><figcaption><p>Edit the User</p></figcaption></figure>

2. Click: Add Roles

<figure><img src="/files/Oy6hHMDXP5AdBbXLIHOC" alt=""><figcaption><p>Add Roles</p></figcaption></figure>

3. Select the required Roles > Done - Save.

<figure><img src="/files/pCuDXNb4UdQSOxe6hnBA" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
**Note:** The initial Data Catalog mapped role isn't displayed ..
{% endhint %}

***

{% hint style="info" %}

#### Test AW Login

It's going to need fine tuning ..  with Permissions & Scope
{% endhint %}

1. Log into PDC:

{% embed url="<https://pdc.pentaho.lab>" %}

Username: <michael.chen@adventureworks.com>

Password:  Welcome123!

<figure><img src="/files/BhYwVhWAVEbZOBIJlEPX" alt=""><figcaption><p>Test Data Catlog role mapping</p></figcaption></figure>

{% hint style="info" %}
The role has restricted access & permissions to the aw-hr-specialist role, which is mapped to the Data catlog Business User Role.
{% endhint %}

***


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://academy.pentaho.com/pentaho-data-catalog-en/data-catalog/aw-organization/communities.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.