Pentaho metadata provides a Security Information property that allows you to define table or column level security that the Pentaho BI Server can make use of. Before you can use this property, you need to tell the Pentaho Metadata Editor about your Pentaho BI Server, so that the program can retrieve the list of Users, Roles and Access Control Lists needed.

Setting Up the Security Service

The security information used in the business model needs to be retrieved from a Pentaho BI Server, so make sure you have the following information available before you attempt to configure security:

• The base URL to the Pentaho BI Server, as well as the name of the service to execute security information retrieval. In the demo server, the base URL is http://localhost:8080/pentaho, and the default name for the service is ServiceAction. Ask your server administrator if changes were made to this service.
• An admin set of credentials for the server.

Security Service Settings

1. From the main menu, select the Security Service option from the Tools menu.
2. The Security Service dialog displays.
   
   
3. On the Service tab, enter the Service URL for your server. This is a URL combining the base URL and the service name. The demo server's Service URL is http://localhost:8080/pentaho/ServiceAction .
4. Next, select the level of detailed security information you want: All, Users or Roles. If you have hundreds of users in your system, you probably only want to return the roles, and use roles for security information properties. The access control lists are returned with all three options.
5. In the username field, provide an admin level username to authenticate with the server.
6. And last, enter the password for the user specified above.

You can click the Test button to be sure the settings are correct, and your server is accessible. You should see a message similar to the following:

Working Offline

You will at times want to work on your model, and may not have access to your Pentaho BI Server. You can save your security information in a file, and the Pentaho Metadata Editor will be just as happy to retrieve your settings from that file instead of making a trip to the server every time you open this domain.

1. Follow the steps above to configure your security settings.
2. Click the Test button, to show the security information from the server.
3. Copy all of the XML between the <content></content> tags, including content the tags themselves.
4. Paste the XML into your favorite text editor

New instructions for 4.8.x, 5.0.x, and 5.1 - the XML format changed a bit:

1. Remove the tags <users>, </users>, <roles>, and </roles> from the file.
2. Rename "user>" to "users>" and "role>" to "roles>"
3. Save the file as metadata_security.xml, in a location of your choosing.
4. Clear out the server URL field.
5. Switch to the File tab in the Security Service dialog.
6. Browse to the file that you just saved.
7. Click OK when you are done.

An example offline XML document looks like this:

<content>
  <users>pat</users>
  <users>admin</users>
  <users>suzy</users>
  <users>tiffany</users>
  <roles>Anonymous</roles>
  <roles>Business Analyst</roles>
  <roles>Authenticated</roles>
  <roles>Report Author</roles>
  <roles>Power User</roles>
</content>

Modifying Security Constraints

To add security constraints to a specific business table or column, first bring up the properties dialog, and then click the add property button:

Select the Security Information property and click OK

With the security property available, now add the individual role or user permissions to the business model, table, or column.  These permissions will then be enforced within Pentaho's BI Platform after publishing the new metadata model.

Configuring the Pentaho BI Server

• Starting in version 2.0, the Pentaho BI Platform uses a security-aware metadata processor by default.  In previous versions, the metadata processor in the platform was not security aware.  As a consequence, existing metadata model files that do not specify security constraints must now specify security constraints to grant access to roles and/or users.