| Include Page | ||||
|---|---|---|---|---|
|
Note: Instructions for ACL Management have changed. This document reflects recent changes to the interface.
Protecting Action Sequences
...
| Panel | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Solution Repository ObjectsOnce you have a container for an ACL, how is it associated with objects in the solution repository? That is where the interface PersistenceThe Pentaho BI Platform uses Hibernate for reading and writing to the db-based repository. The
|
FILE_ID | PARENT | FILENAME | FULLPATH | DATA | DIRECTORY | LASTMODIFIED |
FILE_ID is the primary key. PARENT is a reference (by file id) to the object's parent. DIRECTORY is a boolean that is true if this object is a directory and false if this object is a file.
PRO_ACLS_LIST Table
ACL_ID | ACL_MASK | RECIPIENT |
Technically, rows in this table represent ACL entries, not ACLs. An ACL for an object can be created by querying for all rows sharing the same ACL_ID. ACL_ID is a foreign key that references PRO_FILES.FILE_ID. ACL_MASK is the decimal representation of the bit mask that represents the permissions in this ACL entry. And RECIPIENT is the username or granted authority that is the recipient of this ACL entry.
Voters
For every domain object, there is exactly one access control list. Add to that a user that wants to perform some operation on that object and that adds up to three inputs: a recipient, an operation, and an ACL. But what makes the "access granted" or "access denied" decision given these three pieces of information? The answer to that question is an IAclVoter. An instance of IAclVoter contains an all-important hasAccess method. It takes the three aforementioned inputs and returns a boolean result: true meaning access granted and false meaning access denied. An ACL voter is a singleton; there is only one instance per Java virtual machine. It is specified in pentaho.xml.
One might ask: How many ways can a voter arrive at a decision? Assume that user sally has the following granted authorities: ROLE_DEV and ROLE_MGR. Also assume that the ACL for a particular object contains the following entries: (sally, read), (ROLE_DEV, readwrite). Both ACL entries are applicable to sally since the first specifies sally (and she is sally) and the second specifies ROLE_DEV (and she has been granted the ROLE_DEV authority). Should the voter grant or deny a request to write to the object associated with this ACL? This is where extensibility of the voting system comes in. The Pentaho BI Platform provides multiple implementations of IAclVoter that each make different decisions in this situation! As the user of the platform, you decide how access decisions are made through your choice of IAclVoter. For more information about IAclVoter implementations, see 12. IAclVoter Node.
| Panel | ||||
|---|---|---|---|---|
| ||||
| Panel |
|---|
| Panel |
|---|
| Panel | |||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
ACL Management
Administrators can manage ACLs using a graphical interface available through the Admin menu. Once inside Admin, click Permissions to start the manager. To access the Permissions Editor, you must be logged in as an administrator to the platform. Also, ACLs are available only if you are using the RDBMS solution repository. This feature is not available for the file-based solution repository implementation. Existing Repositories Behavior With the New PermissionsBefore changes were introduced, the Admin Permissions UI exposed a set of permissions, allowing the administrator to set these permissions for individual domain objects. Note that there were three options: Execute, Subscribe and Write. How those three options map to the actual permissions in the platform is demonstrated below:
Now that the share action sequence (xaction) feature has been implemented, changes have been made to the Admin Permissions UI related to what permissions are "exposed" and how they are set. The new Permissions UI has the following set of permissions:
Any domain object / user that was previously assigned the Write permission now has the Create, Update, Delete, Subscribe, and Execute permissions assigned. This effectively is the same access level they had previously, only displayed separately rather than through the combined permission of "Write." By default, on startup of an existing repository with a platform that supports the share feature, no one will have Grant Permissions, so no one will be able to share. The Administrator must go through the Admin Permissions UI to grant the ability to share.
|
| Panel |
|---|
In the sample page above, the tree on the left represents all of the solution repository objects in your solution repository. You can set permissions on any level in the solution repository object tree. Setting permissions on lower level objects in the tree overrides permission settings higher in the tree. Conversely, if you set a permission on a solution repository object that has children, and the children do not have specific permissions set, they inherit the permissions settings from their parent. So, for example, if you set Execute permissions for JoeUser on the analysis object, then the query1.xaction object inherits that Execute permission; however, if you then set Create and Execute permission on the query1.xaction for JoeUser, these permissions are honored for that object, but other children of the analysis object would still only have their parent's (analysis) Execute permission.
...