|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.