![]() |
![]() |
Security Tasks |
Limit the Ability to Update or Delete Servers |
In the initial configuration, the Server
Manager
capability is available to only the SAS Administrators group. This prevents
other users from accessing server definitions under that plug-in. For greater
security, use permissions to protect server definitions. See Protecting Server Definitions.
Establish Access Distinctions for Content and Data |
In a new deployment, access to most resources and data is undifferentiated. All registered nonadministrators have identical metadata-layer access to content, data, and application features. Everyone who uses a stored process server or pooled workspace server has identical host-layer access to any SAS data that server retrieves. In a migrated deployment, access to most resources and data mirrors access in the original environment.
To manage access to items such as reports, stored processes, information maps, and data definitions, create custom folders that reflect the distinctions that you want to make. See Permissions on Folders.
To fully protect SAS data sets, you must also address host access. See Host Access to SAS Tables.
Provide PUBLIC Access (Optional) |
Note: This is not a widely applicable task. Before you use
these instructions, verify that they are appropriate for your environment
and goals. See About PUBLIC Access and Anonymous Access.
If you need to set up a specialized configuration in which unregistered users can participate, make these changes in SAS Management Console:
On the Plug-ins
tab, under Authorization Manager Access Control Templates
right-click the repository ACT (default ACT) and select Properties. On the Permission Pattern
tab, grant the ReadMetadata and WriteMetadata permissions to PUBLIC.
Note: Even users who only consume content need both
of these permissions at the repository level, because some applications write
system information about user activity, even during what appears to be a view-only
transaction.
On the Folders tab, give the PUBLIC group the Read permission for any information maps, cubes, and MLE data that you want to make universally available. A good approach is to create a folder branch for such content, set the grant on the top folder in that branch, and allow the grant to flow through the branch.
Note: Users also need ReadMetadata permission to
folders and content items. In general, it isn't necessary to set specific
grants because this permission must flow through from the repository ACT into
the public areas of the folder tree (for navigational purposes).
Note: If you want to allow everyone (including unregistered
users) to contribute content to a particular folder, give the PUBLIC group
a grant of the WriteMemberMetadata permission on that folder's Authorization tab.
On the Plug-ins tab, under User Manager, right-click the PUBLIC group and select Properties. Review the PUBLIC group's role memberships. Typically, no adjustments are necessary, because the initial role assignments give the PUBLIC group basic capabilities.
Make sure that the PUBLIC group can use servers.
On the Plug-ins tab, under Server Manager, verify that the PUBLIC group has appropriate permissions to the servers that unregistered users will access.
If necessary, add one or more logins on the PUBLIC group's Accounts tab (for example, to provide seamless access to a third-party DBMS).
If you have configured client-side pooling, verify that PUBLIC is a designated puddle group.
On the Plug-ins tab, under
Application Management Configuration
Manager
Web Report Studio, select
the Settings tab and the Application
Configuration section. Set the Allow
Public Users property for SAS Web Report Studio to yes. This change takes effect after you restart the SAS Web Infrastructure
Services application and then restart SAS Web Report Studio.
Note: Some applications don't accept PUBLIC-only
users.
See Also
![]() |
![]() |
Copyright © 2011 by SAS Institute Inc., Cary, NC, USA. All rights reserved.