Security & Data Access
Restrict access to metadata objects ..
Workshop - Securing the Metadata Model
Publishing metadata domains to production environments requires more than just creating business-friendly semantic layers—you must ensure that sensitive data remains protected and that users only access information appropriate to their roles and responsibilities. Pentaho's metadata security framework provides comprehensive protection mechanisms including model-level access controls, column-level field restrictions, and row-level data filtering, all enforced automatically within the metadata layer without requiring complex database views or application-level security logic.
In this hands-on workshop, you'll build the OrdersStarCustomer metadata domain and then systematically apply multiple layers of security constraints to protect sensitive business information. You'll configure the Metadata Editor to communicate with Pentaho Server's security service, implement column-level restrictions to hide financial data from unauthorized users, and create row-level security rules that automatically filter data based on user roles and territories. This comprehensive approach demonstrates how metadata-driven security creates consistent, maintainable data protection across your entire BI platform.
What You'll Accomplish:
Configure the Metadata Editor security service to connect with Pentaho Server's user and role repository
Set up Access Control Lists (ACLs) to retrieve usernames, roles, and security constraints
Apply model-level security to control which roles can access entire metadata domains
Implement column-level security to restrict access to sensitive fields like Credit Limit
Configure row-level security using role-based MQL formulas to filter data by territory
Understand metadata security inheritance from business models to tables and columns
Test security constraints by logging in as different users with varying permissions
Publish secured metadata domains and refresh server caches to apply changes
Validate that security rules properly restrict data visibility based on user roles
By the end of this workshop, you'll understand how Pentaho's metadata security framework provides layered data protection that's both powerful and maintainable. Rather than creating complex database views for each user role or embedding security logic in individual reports, you'll centralize security rules within your metadata layer where they're automatically enforced across all reporting tools and data access methods. You'll see first-hand how administrators view all data while restricted users like Suzy only see information appropriate to their role and territory - all managed through intuitive metadata properties rather than custom SQL or application code.
Prerequisites: Completion of OrdersME and Concepts workshops or access to OrderStarCustomer domain; Pentaho Metadata Editor and Pentaho Server installed and configured; Administrative access to Pentaho Server; Understanding of user roles and security concepts
Estimated Time: 75 minutes
Follow the guide to apply security restrictions:
Access Control List
You must know the base URL for the Pentaho BA Server (the default URL is http://localhost:8080/pentaho as well as the name of the service to execute security information retrieval (the service is ServiceAction).
The Pentaho Metadata Editor must be configured to connect to your BA Server so that it can retrieve usernames, roles, and access control lists. Follow the below directions to set up Metadata Editor.
Go to the Tools menu, then select Security. The Security Service dialogue will appear.
In the Service URL field, type in the base URL for the BA Server plus the security service.
Next, select the level of detailed security information you want:
In the Username and Password fields, type:
Username: admin
Password: password
Click Test. A popup window with the returned XML should appear.
OrderSecurity
For clarity let's rename the current OrderStarModel to OrderSecurity. Remember its the name of the Business Models that is displayed as the Data Source.
Open the OrderStarCustomer.
Right-click on Business Models and select: Edit.
Name the model
OrderSecurityClick OK.
Offline Access
If you want to work on your model and do not have access to the Pentaho Server, you can save your security information in a file. The Pentaho Metadata Editor retrieves your settings from the file instead of accessing the server every time you open your domain.
After you click Test, Copy all the XML between the tags, including content the tags themselves.
Paste the XML code into your favourite text editor, and save the file as metadata_security.xml, in a location of your choice.
Click the File tab in the Security Service dialog box.
Browse to the file that you just saved.
Click OK to exit the dialog box.
Model Access
The ACL provides the server with a list of Users and their Roles that is used to define both the Metadata Security (Model, Table, Column, Row) & Data (None, Global, User/Role - MQL) constraints.
The out-of-the-box default security and data constraints enable only the Authenticated Administrator have access to everything.
Follow the guide to enable Suzy to access the OrderStarCustomer Model.
Set Properties
As we know, the Business Model is comprised of the Business Tables + Business Views. Any Properties that are set at the Business Model level will be inherited by the Business Tables & Columns.
Edit the OrderStarCustomer Model.
Ensure / Add the Metadata Security & Data Constraints Properties are available.
Add Power User Role to Metadata Security.
There should be no Data Constraints - None.
Click: OK.
In Business Views, double-click on Orders Category.
Stop the Metadata Security Override - The Power User Role will appear.
Business Views
Currently there's a minor bug .. The Metadata Security Property set at the Business Model level is not automatically inherited in the Business View. Tou need to Stop the Override to set the inherited property.
Click: OK.
Repeat for the other Categories:
Save & Republish the model.
Grant Users Access to the Domain - Reference Only
Another method is to grant the access by editing the settings.xml.
By default, only users with the Administrator role can access metadata domains. To allow other users (for example, Suzy in the sample environment) to use OrderStarCustomer as a data source, you must adjust data-access permissions.
Stop the Pentaho Server.
Navigate to
/pentaho/server/pentaho-server/pentaho-solutions/system/data-access/and opensettings.xmlin a text editor.Find the following lines:
To allow all authenticated users to access data sources, change them to:
Alternatively, to allow specific users, modify:
Save the file and restart the Pentaho Server.
Wait for the server to fully start before proceeding.
Refresh Models
Obviously .. the published models and reporting data are cached to improve the user reporting experience. Next step is to refresh the caches ..
Log into the Pentaho Server as Administrator:
Select: Tools > Refresh > Reporting Metadata.
Click: Ok - confirm models have reloaded.
Log Out and log back in as Suzy.
Select: Create New > Interactive Report.
Select: OrderStarCustomer Data Source.
Click OK.
Drag & Drop: Customers > Territory onto the reporting canvas.
Column-Level Security
Scenario: Column-Level Security for Sensitive Fields
Let's restrict customer account column - Credit Limit - so that only the Admin (Finance) roles can view them.
This prevents Sales Reps (Power User Suzy) from seeing credit limits unless authorized.
In the left pane, right-click on the Credit Limit column under the CUSTOMER W TER business table.
Select Edit. The Business Column Properties dialog appears.
Override the Metadata Security item.
Click the
next to this field in the Selected Users/Groups field. A list of users and roles appears.
Select Admin from the Available list.
Click the Right Arrow to move Admin to the Assigned list.
Click OK.
Click OK to close the Business Column Properties dialog.
Save & Republish the model.
Log into the Pentaho Server as Suzy.
Create an Interactive Report with OrderStarCustomer as the Data Source.
Row-Level Security
Row-level security filters data results based on the user's role or department. This allows different users to see different rows from the same table.
Goal: Configure security so that user SUZY can only see Customers where Territory = "EMEA". Admin should see all data.
Right-click CUSTOMER W TER Business Table.
x
x
x
x
x
Was this helpful?