Hide Server Definitions

Introduction

In a new deployment, all registered users can see and use server definitions. You might choose to limit the availability of certain servers in any of the following circumstances:

You want to create different levels of host access to data.
You want to direct power users to a server with settings that offer advanced options.
You want to direct high priority users to a server on hardware that offers superior performance.
You want to enable users in SAS Information Map Studio to use a standard workspace server even when a logical pooled workspace server is present.

Method

If you choose to limit the availability of a server, preserve access as follows:

Make sure that the SAS System Services group has ReadMetadata permission for server metadata. This enables the SAS Trusted User to see server definitions. This is necessary because the object spawner uses the SAS Trusted User to discover and read all server metadata.

Note: Users should not be members of the SAS System Services group. This group is for service identities. In the standard configuration, the only member of this group is the SAS Trusted User.
Make sure that the SAS General Servers group has ReadMetadata permission for server metadata. This enables the metadata identity of the launched server to see the server definition. This is a requirement for stored process servers and pooled workspace servers. This isn't a requirement for standard workspace servers.

Note: Users should not be members of the SAS General Servers group. This group is for service identities. In the standard configuration, the only member of this group is the SAS Trusted User.
Metadata administrators should have ReadMetadata permission for all server metadata.
Any user who will use a particular server needs ReadMetadata permission for that server, with the following exceptions:
- The requirement for ReadMetadata permission doesn't apply to requests to use a client-side pooled workspace server. A user can use a client-side pooled workspace server even if that user can't see that server definition.
- The requirement for ReadMetadata permission isn't enforced if the Use Server Access Security check box on a logical server's Options tab is present and not selected. This check box should always be selected.

To efficiently set the permissions, create an ACT that includes the baseline grants and denials that you would use when you hide any server. To enable selected users to use a particular server, supplement the ACT settings with an explicit grant of ReadMetadata permission on that server.

For example, the following table summarizes settings that you might add to provide mutually exclusive access to two server components beneath a standard workspace server that is configured for SAS token authentication:

Example: Hiding Server Definitions

Object	Direct Controls1
Object	ACTs	Explicit Grants
SASApp - ServerA	HideServer	GroupA: +RM
SASApp - ServerB	HideServer	GroupB: +RM
1The direct controls in this example don't determine which of the users who can see the server can also update or delete the server. See Protect Server Definitions.

Someone who has ReadMetadata permission for both ServerA and ServerB (for example, a member of the SAS Administrators group) uses the first server in the object spawner's list of servers.

Instructions

Here is one way to set the permissions:

Log on to SAS Management Console as a member of the SAS Administrators group (for example, sasadm@saspw). Select the Plug-ins tab.
(Optional) To examine the current settings:
1. Expand Server Manager, right-click the server or server component that you are limiting use of and select Properties.
  
  Note: The SASMeta application server should have limited availability, because it should be used only as instructed (in a few specialized administrative tasks).
2. On the Authorization tab, select SASUSERS. Notice that this group (which includes all registered users) has ReadMetadata permission. The application server inherits the grant from the standard repository-level settings. Click OK to close the dialog box.

To create the ACT:

Expand Authorization Manager, right-click Access Control Templates, and select New Access Control Template.
On the General tab, enter a name such as HideServer.

On the Permission Pattern tab, define baseline settings for hiding servers.

Example: Pattern for the HideServer ACT

Group	Permission Pattern
PUBLIC	Deny	ReadMetadata
SAS Administrators	Grant	ReadMetadata1
SAS General Servers	Grant	ReadMetadata
SAS System Services	Grant	ReadMetadata2
1This grant ensures that administrators can manage all server metadata (for alternatives, see Separated Administration).
2This grant ensures that the SAS Trusted User (who is a member of SAS System Services) can read server metadata for the object spawner (on behalf of all users).

Tip

This pattern, when applied to a standard workspace server, grants a little more access than is strictly necessary. For a standard workspace server, the SAS General Servers group doesn't need ReadMetadata permission. If you want to avoid this, consider omitting the SAS General Servers group from this ACT and remembering to add an explicit grant for this group when you are hiding a stored process server or pooled workspace server.

On the Authorization tab, protect the ACT that you are creating. Either apply an ACT or add explicit controls that deny WriteMetadata permission to PUBLIC and grant WriteMetadata permission to the SAS Administrators group.

Note: If the Users and Groups list box on the ACT's Authorization tab is empty, click OK to save the ACT. Then, right-click the new ACT, select Properties, and select the Authorization tab again.
Click OK.

(Optional) If you don't already have a group that represents the users who will use the server, create a new custom group.
1. Right-click User Manager and select NewGroup.
2. On the General tab, enter a name such as GroupA.
3. On the Members tab, move users (or groups) to the Selected Identities list box.
4. Click OK to save the new group. You will grant ReadMetadata permission to this group in step 5c. This group doesn't participate in the general pattern because this group doesn't need ReadMetadata permission on all servers.
Note: As an alternative to creating a group for only this purpose, you can skip this step and instead assign the permissions directly to specific users in step 5c.
To set the permissions:
1. Under Server Manager, right-click the server that you are limiting use of and select Properties.
2. On the Authorization tab, click Access Control Templates. In the Add and Remove Access Control Templates dialog box, move the HideServer ACT to the Currently Using list box (you have to expand the Foundation node to get to the ACT). Click OK to return to the Authorization tab.
  
  Note: If the Currently Using list already includes another ACT (such as the Protect ACT), don't remove that assignment.
  
  Note: Review the revised settings. Notice that SASUSERS is now denied ReadMetadata permission and that PUBLIC and SAS Administrators have some ACT settings. These settings come from the HideServer ACT.
3. Click Add, add one or more identities to the Authorization tab, and give each of those identities an explicit grant of ReadMetadata permission. For example, you might assign the grant to a group (such as GroupA) or to individual users.
4. Click OK.
If you are limiting use of a logical server or server component, ensure that the Use Server Access Security check box on the logical server's Options tab is selected. If the check box is not selected, requirements for ReadMetadata permission for that server and its components are not enforced. This option affects only enforcement of the ReadMetadata permission.

Hide Server Definitions

Introduction

Method

Instructions

See Also