Managing Access to Reports
Overview of Managing Access to Reports
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.
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.
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:
-
The ability to view or work with a report can be affected by access to each of the report's underlying components. Beginning with the second maintenance release for SAS Web Report Studio 4.31, users who do not have the WriteMetadata permission to a report can modify the report in memory and e-mail a copy of the modified version of the report to a recipient. See Create, E-mail, View, and Delete Report Definition Snapshots.
-
If your organization uses publication channels to deliver reports, the reports can also be protected by controlling access to the publication channels. To enable all registered users to add channels or subscribers or to add items to a particular channel, see “Permissions by Object Type” in Authorization Model in SAS Intelligence Platform: Security Administration Guide.
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 in SAS Intelligence Platform: Middle-Tier Administration Guide.
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.
Create, E-mail, View, and Delete Report Definition Snapshots
Beginning with the second
maintenance release for SAS Web Report Studio 4.31, a user can open
a SAS Web Report Studio report, make modifications that are saved
in a report definition snapshot,
and e-mail the URL for the snapshot
to a recipient. The snapshot
is a customized report that is created from an original SAS Web Report
Studio report and e-mailed to a recipient.
The snapshot
is always associated with the original report, but the original report
remains unchanged when the snapshot
is created with modified content and e-mailed to a recipient. If the
original report is deleted, any snapshots
that are associated with that original report are automatically deleted.
This feature is useful when a user wants to create a custom report
(without altering the original report) and share the customized report
with other users by e-mailing them the URL for the snapshot.
When the user selects File
E-mail,
the URL for the customized snapshot
is placed automatically in the default e-mail application, and the
e-mail can be sent to recipients. When the recipient clicks on the
URL in the e-mail, SAS Web Report Studio opens in the user’s
browser. If the recipient is not logged on, then the recipient is
prompted to enter his or her user ID and password. The snapshot
is displayed in SAS Web Report Studio.
E-mail,
the URL for the customized snapshot
is placed automatically in the default e-mail application, and the
e-mail can be sent to recipients. When the recipient clicks on the
URL in the e-mail, SAS Web Report Studio opens in the user’s
browser. If the recipient is not logged on, then the recipient is
prompted to enter his or her user ID and password. The snapshot
is displayed in SAS Web Report Studio.
http://salesdepartment.orion.com:8080/SASWebReportStudio/openRVUrl.do?
rsRID=SBIP%3A%2F%2FMETASERVER%2FWRS+Testing%2FWill%2FFolder+five+
f%C3%BCnc+%C3%A7inq%2Ftestreport.srx%2FEmailed%2F120629_160104
%28ReportCI%29=0When the snapshot
is viewed by the recipient in SAS Web Report Studio, the name of the snapshot
is displayed in this format:
The filename includes
a timestamp in this format:
YearYearMonthMonthDayDay_HourHourMinuteMinuteSecondSecond
The following table
provides information about the metadata security and role capability
requirements that apply to the users who create, e-mail, view, or
delete snapshots.
By default, a maximum
of 50 snapshots
can be created. When the total number of snapshots
exceeds 50, the snapshots
that were created first are automatically deleted. You can, however,
increase the limit for the total number of snapshots
that can be created and associated with an original SAS Web Report
Studio report by configuring the
wrs.numEmailSnapshotsMax property.
See Create, E-mail, View, and Delete Report Definition Snapshots.The following figure
illustrates how snapshots
are created, e-mailed, viewed, and stored. In this example, the sender
has WriteMetadata permission for the SAS Web Report Studio report,
which is the source for creating the snapshot.
Creating, E-mailing, and Viewing a report definition snapshot
The following table
shows how a snapshot
is created and e-mailed by a user who does not have a WriteMetadata
permission to the SAS Web Report Studio report upon which this snapshot
depends.
Creating and E-mailing a Snapshot without WriteMetadata Permission
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.
For more information
about restrictive policy files, see Configuring and Deploying Restrictive Policy Files in SAS Intelligence Platform: Middle-Tier Administration Guide.
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.
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
Overview
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.
Verify SAS Trusted User's Access to the Directories in the SAS Content Server
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.