Page Comparison

...

1. Plan.
   You must plan out your security before telling Pentaho how to use it. For example, you must also have the appropriate security back-ends (e.g. LDAP) in place.
   1. Determine your roles.  Role names are case-sensitive in the Pentaho BI Platform.
      What roles (out of potentially many) will have meaning in the Pentaho BI Platform?  For example, you might have roles (or groups) that are used by other applications in your enterprise. You could reuse those roles or define new ones for use with the Pentaho BI Platform.  If you already have a BI_USER role, you could tell Pentaho to use that existing role.
   2. Determine which roles should have access to particular URLs.
      This is web resource authorization. Example question: What role will be considered the Pentaho administrator? Note that Pentaho has default web resource authorization settings.  You probably won't need to change the URLs that are protected.  What you will have to change are the roles that are allow to access each URL.
   3. Determine which roles should have which permissions to particular action sequences in the solution repository.
      This is domain object authorization. Example question: Will role A be allowed to execute action sequences in folder X?
2. If you'd like to use a role prefix, define one. (By default, there is no role prefix.)Enable action sequence security.
3. Define the Pentaho administrator role.
4. Take the domain object authorization rules (from the earlier planning step) and define them in the IAclPublisher section of pentaho.xml.
5. Apply the ACLs. ^*
6. Take the web resource authorization rules (from the earlier planning step) and define them in the filterInvocationInterceptor bean in applicationContext-acegi-security.xml.Optionally, customize the login page.

^* This step is a batch operation and will remove any custom permissions created via the Admin Permissions UI or Pentaho User Console!