Previous Page | Next Page

Managing SAS Web Report Studio Content and Users

Managing Access to Reports


Overview of Managing Access to Reports

The following table summarizes the basic security considerations for reports.

Report Security Considerations
Item Action to Secure the Item
Report definitions Metadata objects that are associated with the reports

Physical storage location of the report definitions

Underlying report data Metadata objects that are associated with the report data

Physical storage location of the report data

Information maps that reference the report data

Stored processes that reference the report data

Report definition (if the report includes embedded data)

Generated report (if the report is a batch report)

Different types of reports require different security measures. For example, if there is no embedded data of a sensitive nature in a report definition, then the report definition can be considered secure if the report's underlying data, information maps, stored processes, and output are secure. However, pre-generated reports (and some reports that are created through ODS) can include embedded data, so these reports must be protected with access controls that parallel the access controls on the underlying information maps and stored processes.

CAUTION:
Do not rely on restricting access to the underlying information maps or stored processes to ensure that batch reports are viewed only by the appropriate users.   [cautionend]

Access to a report can be affected by multiple layers of controls. For example, the following figure depicts the authorization layers that affect access to reports in a deployment that is using a SAS content server with the SAS document store located in a directory in the file system.

Authorization Layers That Affect Access to Reports

[Authorization Layers That Affect Access to Reports]

In the figure, the requesting user's access to reports is subject to controls in the metadata, SAS Content Server, and file system authorization layers. However, the only layer in which the requesting user's permissions matter is the metadata layer, because this is the only layer in which the requesting user's identity is known. In the metadata layer, each user's access to reports is based on the user's individual identity and group memberships. When you work with metadata access controls for reports, consider these points:

As the preceding figure depicts, SAS Web Report Studio uses only one account to connect to the external storage location, so you cannot make access distinctions between individual users by setting operating system access controls on specific items within the external storage location. However, you should set operating system controls that allow only the identity under which the SAS Content Server process is running (local system in this example) to access this physical file location.

Similarly, SAS Web Report Studio uses only one account, the trusted user sastrust, to communicate with the WebDAV content server, so you cannot make access distinctions between individual users by setting access controls in the SAS Content Server. However, you should use this layer to protect your SAS report content. For information about how to set permissions by using the SAS Content Server admin console, see Using the SAS Content Server Administration Console.

For more information about access controls and access management, see "Access Management Tasks" in the SAS Management Console: Guide to Users and Permissions.


Change Access to Reports

Each new report subfolder that you create in metadata inherits the effective access controls of its parent folder. For information about how to limit access to each subfolder or the items within the subfolders, see "Access Management Tasks" in the SAS Management Console: Guide to Users and Permissions.


Enable Permissions in Restrictive Policy File for Publishing Reports to Channels

When a SAS Web Report Studio report is saved as a pre-generated report in PDF format, the output is published to a channel. The Web application server must have explicit policy permissions granted to allow read and write access to this directory.

An express or typical installation completed with the SAS Deployment Wizard creates a SAS environment that does not use restrictive policy files. By default, the sas.all.permissions.policy is used to allow access to SAS Web applications. As a result, SAS Web applications can access the necessary content.

If you implement restrictive policies at your site for JBoss or IBM WebSphere application servers, you must ensure that read and write access is granted to the directory where pre-generated reports are published to channels.

CAUTION:
SAS strongly discourages the use of restrictive policy files on SAS middle-tier applications because they provide no end-user security, they are difficult to maintain, and they can be very detrimental to application performance.   [cautionend]

For more information about restrictive policy files, see Configuring and Deploying Restrictive Policy Files.


Security Considerations for Pre-generated Reports

When a pre-generated report is created, the content of the report reflects the access that the generating user ID has to objects such as data sources and stored processes. For example, if a pre-generated report is configured to use an identity named SalesMgr1, then the report can include anything that SalesMgr1 is able to access. Regardless of who actually views the report, the report content is always based on the access controls that apply to SalesMgr1. This means that any user who has ReadMetadata permission for a pre-generated report can view that report, even if other metadata access controls deny the user access to the report's underlying components (such as data sources and stored processes). For this reason, you must give careful consideration to the identity that each pre-generated report uses for generation, and you must secure the pre-generated reports that you create. Pre-generated reports are saved and open to anyone who has permissions to the Operating System (OS) location.

Note:   When a user refreshes the report data while viewing the report in SAS Web Report Studio, that user sees only the content that he or she has permission to see.  [cautionend]


Considerations for Row-level Security

If you implement BI row-level access to data, it is recommended that you configure a pooled workspace server that is dedicated for use by SAS Web Report Studio. For BI row-level access to data, you need a pooled workspace server to prevent the workspace server processes from running under the accounts of requesting users. Pooled workspace servers run under one or more designated accounts that are called puddle accounts or puddle logins. You need a dedicated workspace server to isolate the row-level security puddle account from applications that do not fully enforce row-level security.

In a dedicated deployment of SAS Web Report Studio, a client-side pooled workspace server is required.

For information about pooled workspace servers, see the SAS Intelligence Platform: Application Server Administration Guide.

In addition, if you implement BI row-level security, users should generally not be given the capability Allow Direct Access to Tables. By default, this capability is not assigned to any roles. For more information, see Predefined Roles and Capabilities for SAS Web Report Studio.

For more information about row-level security, see "BI Row-Level Permissions" in the SAS Intelligence Platform: Security Administration Guide.


Protect Report Content in the WebDAV Server

On a publicly accessible WebDAV server, the area where SAS report content is stored should be protected against access by components that do not enforce SAS metadata permissions. For example, applications from other vendors and the DAV navigator portlet should not be able to access content in this area.

The sasfolders  folder in the SAS Content Server can be configured for WebDAV content mapping and should be accessed only by trusted or unrestricted users. These users are recognized as unrestricted administrators for the SAS Content Server and do not require the Access Control List (ACL) to grant them access to this directory. If other types of users attempt to access this location, their permissions are verified before they are granted any access. Applications that are not aware of SAS metadata do not have access to the sastrust user ID and password, so these applications cannot access the area of the content server.


Configure Content Mapping with a WebDAV Location

Content Mapping associates a location where report content is stored with a tree of folders and objects in a metadata repository. During installation, content mapping is created for the /SASContentServer/repository/default/sasfolders WebDAV directory. The Content Mapping tab is available only for folders that are directly below the root node of the SAS Folders navigation tree.

The following display shows the Content Mapping dialog box:

Content Mapping Dialog Box

[Content Mapping Dialog Box]

If you want to view or modify content mapping with a WebDAV Location, follow these steps:

  1. In SAS Management Console, go to the Folders tab, and navigate to SAS Folders. Right-click on SAS Folders to display the menu bar.

  2. In the menu bar, select Properties.

  3. In the SAS Folders Properties dialog box, select the Content Mapping tab.

  4. In the Content Mapping dialog box, select WebDAV location.

  5. From the menu for Server, select SAS Content Server. The server specifies a WebDAV-enabled HTTP server or HTTPS server where the report content will be stored.

    The Base path and URL: fields are filled with the folder path in SAS Management Console and the folder path in the SAS Content Server respectively. The Base path specifies the path to the report content. You can use this Base path field only when you select WebDAV location.

  6. When the WebDAV location is chosen for content mapping, also fill in the fields for User ID, Password, and Confirm Password.


Verify SAS Trusted User's Permissions to Directories in the SAS Content Server

To verify the SAS Trusted User's permissions to the SAS Content Server, follow these steps:

  1. Access the SAS Content Server's administration console by opening a Web browser to <machine-name>:8080/SASContentServer/dircontents.jsp and logging on as the SAS Content Server administrator.

  2. Select the permissions icon for the sasfolders directory, and verify that the SAS Trusted User has exclusive, full access to this directory (and to this directory's subdirectories and files).


Verify SAS Trusted User's Access to the Directories in the SAS Content Server

To verify that the SAS Trusted User (sastrust) can access the sasfolders directory, follow these steps:

  1. Access the SAS Content Server's administration console by opening a Web browser to <machine-name>:<port>/SASContentServer/repository/default and logging on as the SAS Content Server administrator.

  2. Authenticate as the sastrust user.

  3. Verify that you can see the contents of the directories.


Verify Users' Access to the SAS Directories in the SAS Content Server

To verify that other users cannot directly access the SAS Folders area in the SAS Content Server, access the SAS Content Server's administration console by opening a Web browser to <machine-name>:<port>/SASContentServer/repository/default and logging on as the SAS Demo User. You should see a "Page Not Found" message.


Protect Data in Temporary Files Created by SAS Web Report Studio

SAS Web Report Studio writes temporary files that might contain data that should be protected. These temporary files are stored in the following locations:

To protect the data in these temporary files, do the following:

Previous Page | Next Page | Top of Page