Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Be Careful: In Pentaho security, role name case is important! A role named ADMIN is not the same as a role named Admin. For example, using the role named ADMIN when editing access control lists will not match a user who has been granted a role named Admin.

By default, the platform defines an administrative role called Admin. Use the steps below to change this value. For the examples below, assume that the new administrative role is called "NewAdmin."

pentaho.xml

In pentaho.xml, update the admin-role element within the acl-voter element.

<pentaho-system>
  <acl-voter>
    <admin-role>NewAdmin</admin-role>
    ...

Additionally, replace any references to the old administrative role within the default-acls element within the acl-publisher element.

<pentaho-system>
  <acl-publisher>
    <default-acls>
      <acl-entry role="NewAdmin" acl="ADMIN_ALL" />
      ...

Warning: If you modify the acl-publisher element, you'll probably need to re-apply the default ACLs. Please see Re-Applying Default ACL. Be careful though as re-applying default ACLs will reset any ACLs created through the Admin Permissions interface.

applicationContext-acegi-security.xml

Using the Acegi Security documentation (section 21.3) as your guide, modify the objectDefinitionSource property of the filterInvocationInterceptor bean to match the new admin group.

Warning: While the example below only shows a single url to role mapping, multiple lines in objectDefinitionSource refer to the administrative role and therefore must be changed too.

<property name="objectDefinitionSource">
  <value>
    <![CDATA[
    CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
    ...
    \A/admin.*\Z=NewAdmin
    ...
  ]]>
  </value>
</property>
  • No labels