PUBLIC Access and Anonymous Access

About PUBLIC Access and Anonymous Access

In general, only users who can authenticate and who have a well-formed user definition should use a SAS deployment. However, in order to accommodate scenarios where more general access is desired, the following specialized configurations are supported:
  • PUBLIC access enables unregistered users to participate if they can authenticate to the metadata server (directly or through a trust mechanism). Unregistered users are referred to as PUBLIC-only users because their only SAS identity is that of the PUBLIC group. A PUBLIC-only user has the logins, permissions, and capabilities of the PUBLIC group. A PUBLIC-only user can't belong to any other groups, or have any personal logins, or have any specialized (individual) access controls. Not all applications allow a PUBLIC-only user to log on.
  • Anonymous access enables unregistered users to participate without authenticating to the SAS environment. Anonymous access is an optional configuration that is available for only a few applications. Anonymous access is supported only with SAS authentication; anonymous access is not compatible with Web authentication. Anonymous access is supported as follows:
    • For SAS BI Web Services and the SAS Stored Process Web Application, a user who connects through anonymous access uses the SAS Anonymous Web User identity. This is a service identity that functions as a surrogate for users who connect without supplying credentials. See Using the SAS Anonymous Web User with SAS Authentication in SAS Intelligence Platform: Middle-Tier Administration Guide.
    • For the SAS Information Delivery Portal, a user who connects through anonymous access uses the Unchallenged Access User identity. This is a service identity that functions as a surrogate for users who connect without supplying credentials. See Enabling Unchallenged Portal Access in SAS Intelligence Platform: Web Application Administration Guide.
PUBLIC access and anonymous access differ in the following ways:
  • In PUBLIC access, each participating user must authenticate. In anonymous access, participating connections don't require user authentication.
  • In PUBLIC access, participating users share the PUBLIC group identity. In anonymous access, participating connections share a designated service identity (the surrogate identity is always a member of both the SASUSERS group and the PUBLIC group).
  • You can choose to provide wide support for PUBLIC access. You can't extend support for anonymous access beyond the specific applications that can be configured to use it.
CAUTION:
If you choose to offer PUBLIC or anonymous access, you risk users seeing more data and content than you might expect.
Carefully review and manage access control for the PUBLIC group. If you offer anonymous access, carefully review and manage access control for your surrogate service identity too.

How to Enable PUBLIC Access

You can use the following instructions to set up a specialized configuration in which unregistered users can participate from most SAS applications. However, not all SAS applications can be configured to accept PUBLIC-only users. For example, SAS Information Map Studio never accepts PUBLIC-only users.
To enable PUBLIC access, complete the following steps in SAS Management Console:
  1. Provide the necessary repository-level access.
    On the Plug-ins tab, under Authorization Managerthen selectAccess 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.
  2. Provide Read access as needed.
    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 objects. 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.
  3. Review role assignments for the PUBLIC group.
    On the Plug-ins tab, under User Manager, right-click the PUBLIC group and select Properties. Review the PUBLIC group's role memberships. Often, no adjustments are necessary, because the initial role assignments give the PUBLIC group basic capabilities.
  4. Make sure that the PUBLIC group can use servers.
    1. On the Plug-ins tab, under Server Manager, verify that the PUBLIC group has the ReadMetadata permission for any servers that the PUBLIC-only users will access.
    2. 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).
    3. If you have configured client-side pooling, verify that PUBLIC is a designated puddle group.
  5. Configure middle tier properties applications to accept PUBLIC-only users.
    On the Plug-ins tab, navigate to Application Managementthen selectConfiguration Manager, and make changes as needed. Not all deployments include and use all components.
    Tip
    If you need additional information, see the administrative documentation for your application. Not all deployments include and use all components. Not all middle-tier components have an applicable property.
    1. For SAS Web Report Studio, set the Allow Public Users property to Yes (this property is in the Application Configuration section of the Settings tab of the properties dialog box for Web Report Studio).
    2. For the SAS Stored Process Web application, set the App.PublicIdAllowed property to true (this property is on the Advanced tab of the properties dialog box for the Stored Process Web App).
    3. To make the changes take effect, restart the SAS Web Infrastructure Services Application and then restart the affected Web applications.