| Wiki Markup |
|---|
{scrollbar} ---- O3 gives you the chance to specify a common repository where the security definitions for the different components are stored. In this way a good number of security definitions are shared and access permits are defined in the same framework. |
...
The access to scorecards control mechanism is enabled for remote scorecards, that is, scorecards that have been published in O3 Server. |
...
You may find more information about O3 security mechanisms and Role and Users definition in the O3 Server Reference Manual |
...
- Launch O3 Server Administrator and log on to O3 Server. (You need to do this through a user with administration rights)
- In the definitions tree, choose the node labeled "Security" from the "Services" branch and specify the access permits to work with the scorecard as detailed in the following section
- Apply changes made with the "Apply" button.
...
- Scorecard: It indicates the name of the scorecard over which permissions are defined.
- Read: It indicates if they have permission to view the scorecard.
- Write: It indicates if they have permission to generate a scorecard in the server.
- List: It defines if the list of remote scorecards can be seen. This column is only used when general permissions are defined, that is, the permissions in the Repository.
Values for each type of permit are:
| Allow | It lets you perform the operation indicated in the column for the selected role. For instance drilling the corresponding scorecard is enabled if you give this value to the "Read "column. |
| Denied | It prevents the operation indicated in the column for the role. For instance, it does not let you update the corresponding scorecard if you give this value to the "Write" column. |
| Inherit | It takes the same specified value for the Repository in the corresponding column (that is, the value given in the first row). If the Repository value is "Inherit", then the permit for the current scorecard is equivalent to "Denied". |
...
{anchor:_Hlt122149620}{anchor:_Hlt122149650}{anchor:_Toc183601823}{*}Remote Scorecard Access Setup*{anchor:_Hlt122149646}
The following procedure describes how to establish different types of accesses to scorecards, assuming that the necessary roles and users have been created.
To define access control to a scorecard you need to:
# Launch O3 Server Administrator and log on to O3 Server. (You need to do this through a user with administration rights)
# In the definitions tree, choose the node labeled "Security" from the "Services" branch and specify the access permits to work with the scorecard as detailed in the following section
# Apply changes made with the "Apply" button.
!worddavfb9a8b6a8bda9e8f8e58af475ada3a2d.png|height=356,width=575!
Picture 36: O3 Server Administrator Interface to define permits for scorecards
It is important to point out that the "Refresh" button lets you see the scorecards that have been published, in order to keep the list of published scorecards updated during the administration process.
{anchor:_Hlt122149656}{anchor:_Toc183601824}{*}Defining Security for Scorecards*
This section describes the tab named "Permissions" where the type of access to each scorecard is defined. Details of the other tabs are of no interest in this section. They can be seen in the O3 Server Reference Manual.
You may see that on the left area of the tab, the list of existing roles is displayed, and on the right a table with one row for each scorecard published in the server.
First of all the "scorecards" option must be selected for the field named "Component", to enable the viewing of permissions for them.
Then you must select the role for which you wish to specify access controls to the different scorecards.
The permissions table contains a first row where general permissions are specified. These are associated to a generic name "Repository". The remaining rows let you define the permissions for each scorecard published in the server.
The permissions table displays the following columns:
* Scorecard: It indicates the name of the scorecard over which permissions are defined.
* Read: It indicates if they have permission to view the scorecard.
* Write: It indicates if they have permission to generate a scorecard in the server.
* List: It defines if the list of remote scorecards can be seen. This column is only used when general permissions are defined, that is, the permissions in the Repository.
Values for each type of permit are:
|!worddavf9884dc2f590349802e605f8bd61ee85.png|height=36,width=36! |Allow|It lets you perform the operation indicated in the column for the selected role. For instance drilling the corresponding scorecard is enabled if you give this value to the "Read "column.|
|!worddav8ef2c488b17da21d55eafa45c2ead6e2.png|height=36,width=36! |Denied|It prevents the operation indicated in the column for the role. For instance, it does not let you update the corresponding scorecard if you give this value to the "Write" column.|
| |Inherit|It takes the same specified value for the Repository in the corresponding column (that is, the value given in the first row). If the Repository value is "Inherit", then the permit for the current scorecard is equivalent to "Denied".|
\\
Following you can see different examples of combinations of permits that can be defined for the scorecards.
+Consulting scorecard{+}: For users in a given role to be able to open and drill a dashboard, the role must have the "Allow" value in the List in the Repository option and "Allow" value too in the "Read" option for the scorecard being considered.
+Updating a scorecard and defining new ones:+ for users in a given role to be able to generate a scorecard to update its contents or to define new scorecards in the server, the role must have the "Allow" value in the List in the Repository option and "Allow" value too in both of the options "Read" and "Write" for the scorecard being considered.
----
{scrollbar}
----
{children}
|