Setting Up Security
DeepSee has a formal mechanism for managing access to functionality and DeepSee items. This mechanism is based on the underlying Caché security framework. This chapter discusses the following topics:
This chapter assumes that you are familiar with Caché security as described in the Caché Security Administration Guide. In particular, it assumes that you understand the relationships between resources, roles, and users.
For information on security for Visual Reporting options, see Using DeepSee Visual Reporting.
If you install Caché with the Minimal Security option (and if you do not tighten security after that), the user UnknownUser belongs to the %All role and has access to all parts of DeepSee. In this case, ignore this chapter.
Also note that you use DeepSee from within a web application. By default, a web application can access a subset of InterSystems classes, which does not include the %DeepSee classes. To use DeepSee in your web application, you must explicitly enable access to the %DeepSee classes. For details, see “CSP Application Settings” in Using Caché Server Pages (CSP); see the subsection “Special Case: DeepSee.”
This access is enabled by default for the /csp/samples and /csp/ensdemo web applications.
Overview of Security
The following table summarizes how elements in DeepSee are secured:
|DeepSee User Portal||%DeepSee_Portal and %DeepSee_PortalEdit resources|
|DeepSee Analyzer||%DeepSee_Portal, %DeepSee_Analyzer, and %DeepSee_AnalyzerEdit resources|
|DeepSee Architect||%DeepSee_Portal, %DeepSee_Architect and %DeepSee_ArchitectEdit resources|
|Folder Manager and Cube Manager||%DeepSee_Portal and %DeepSee_Admin resources|
|Query Tool and Settings pages||%DeepSee_Portal, %DeepSee_Admin, and %Development resources|
|Term List Manager and Quality Measure Manager pages||%DeepSee_Portal and %DeepSee_PortalEdit resources|
|Listing Group Manager||%DeepSee_ListingGroup, %DeepSee_ListingGroupEdit, and %DeepSee_ListingGroupSQL resources|
|Cubes, subject areas, listings, listing fields, listing groups, KPIs, folders, and folder items (such as dashboards and pivot tables)||Custom resources (optional)|
|Quality measures||Accessible only to users of any cubes to which the quality measures are published; no additional security|
|Term lists||No security options|
For details, see “Requirements for Common DeepSee Tasks,” later in this chapter.
For a user to use DeepSee, the following must be true, in addition to the other requirements listed in the rest of this chapter:
The user must have access to the database or databases in which DeepSee is used.
By default, when you create a database, Caché does the following:
Creates a resource with a name based on the database name (%DB_database_name).
Establishes that this resource controls access to the new database.
Creates a role with the same name as the resource. This role has read and write privileges on the resource.
You can specify whether the read and write privileges are public. These privileges are not public by default.
For example, suppose that you create a database called MyApp for use with DeepSee, and you let Caché create the resource and role as described here, and suppose that the read and write privileges are not public. In this case, a DeepSee user must belong to the %DB_MyApp role, which has read and write privileges on the %DB_MyApp resource.
Note that the SAMPLES database is treated specially; in order to use this database, it is not necessary to belong to the %DB_SAMPLES role.
If the ^DeepSee globals are mapped from another database, the user must also have access to the database that contains these globals.
Requirements for Common DeepSee Tasks
The following table lists the security requirements for common tasks, in addition to the items in the previous section.
|Task||Privileges That the User Must Have for This Task*|
|Viewing the User Portal (apart from the Analyzer or the mini Analyzer) with no ability to create dashboards||USE permission for the %DeepSee_Portal resource|
|Viewing the User Portal (apart from the Analyzer or the mini Analyzer) with the ability to create new dashboards||
|Viewing a dashboard (including exporting to Excel and printing to PDF)||
|Read-only access to the Analyzer or Mini Analyzer||
|Full access to the Analyzer or Mini Analyzer||
|Viewing a listing||
|Modifying an existing pivot table in the Analyzer||
|Creating a new dashboard||
|Modifying an existing dashboard||
|Read-only access to the Architect||
|Creating a new cube or subject area in the Architect||
|Modifying an existing cube or subject area in the Architect||
|Listing Group Manager (read only access)||USE permission for the %DeepSee_ListingGroup resource|
|Listing Group Manager (edit access, except for custom SQL query options)||USE permission for the %DeepSee_ListingGroupEdit resource|
|Listing Group Manager (edit access, including custom SQL query options)||
*Also see the previous section. Note that in your resource definitions, some of the permissions might be public. For example, in a minimal security installation, by default, the USE permission is public for all the DeepSee resources.
**If a cube contains relationships to other cubes, those cubes are secured separately. A user must have USE permission for all of them in order to use the relationships. Similarly, a compound cube consists of multiple cubes, which are secured separately.
Adding Security for Model Elements
To add security for a cube, subject area, KPI, pivot table, dashboard, listing, or listing field:
Create a resource in the Management Portal. Use the Resources page (select System Administration > Security > Resources).
Create a role in the Management Portal. Use the Roles page (select System Administration > Security > Roles). This role should have USE and WRITE permissions on the resource you just created.
Or you could create one role with USE and WRITE permissions and another role with only USE permission.
Associate the resource with the DeepSee item as follows:
For a dashboard or pivot table, when you save the item, type the name of the applicable resource into the Access Resource field.
See also “Specifying the Resource for a Dashboard or Pivot Table.”
To save a dashboard or pivot table, you must also have the USE and WRITE privileges for the appropriate DeepSee user interface component, as described in the previous heading.
For a cube, subject area, or listing field, use the Architect to specify the resource that secures that item.
For a listing defined in a cube definition, use the Architect to specify the resource that secures that item.
For a listing group or for a listing defined in a listing group, use the Listing Group Manager to specify the resource that secures that item.
For a KPI, edit the class definition in Studio. Use the name of the applicable resource as the value of the RESOURCE class parameter.
Assign users to roles as needed.
Specifying the Resource for a Dashboard or Pivot Table
To specify the resource for a dashboard or pivot table, specify the Access Resource field when you save the item. You can do this in any of the following cases:
The item has no owner (specified as the Owner field).
You are the owner of the item.
You have USE permission on the %DeepSee_Admin resource.
Specifying the Resource for a Folder
To specify the resource for a folder:
Click the InterSystems Launcher and then click Management Portal.
Depending on your security, you may be prompted to log in with a Caché username and password.
Switch to the appropriate namespace as follows:
Click the namespace.
Click DeepSee > Admin > Folder Manager.
Click the check box next to a folder.
In the left area, click the Details tab.
Type the name of the resource.
Click Save Folder.