Web Authentication

Web Authentication
Summary
The metadata server accepts users who are authenticated at the Web perimeter.
Scope
From SAS Web applications to the metadata server.
Benefits
  • Facilitates single sign-on from and across the Web realm.
  • Enables SAS Web applications to use whatever authentication scheme you have set up in your Web environment. This can facilitate integration with J2EE servlet containers, products such as SiteMinder or Tivoli Access Manager/WebSEAL, and Web servers.
  • Can reduce the number of user accounts that you have to create in the metadata server's authentication provider, because users who use only Web applications no longer need accounts with the metadata server's provider.
Limits
  • When you use Web authentication to access the metadata server, there are no cached credentials from an initial logon. This prevents authentication from Web applications to the standard workspace server through reuse of credentials.
  • Prevents users from logging on to a SAS Web application with a SAS internal account.
  • Not compatible with anonymous access. See About PUBLIC Access and Anonymous Access.
Use
Optional.
The following figure depicts the high-level choice in authentication method for SAS Web applications:
  • SAS authentication (any form of authentication in which the metadata server is responsible for requesting verification)
  • Web authentication (any form of authentication in which verification occurs in the Web realm and the metadata server trusts that verification)
Examples of SAS Authentication and Web Authentication
Examples of  SAS Authentication and Web Authentication
The preceding figures are simplified in order to highlight the differences between the two configurations. The following figure includes additional detail about Web authentication.
Web Authentication: A Closer Look
Web Authentication: A Closer Look
In the preceding figure, a user who is not already authenticated at the Web perimeter makes a request to access SAS Web Report Studio. The numbers in the figure correspond to these activities:
  1. In a Web browser, the user makes the request.
  2. A SAS component within the Web application server (the Logon Manager application) prompts the user for credentials. This occurs because, in this example, the user has not already been authenticated at the Web perimeter.
  3. The user supplies credentials to the Web container.
  4. The Web container's Java Authentication and Authorization Service (JAAS) login module chain directs the container to verify the credentials against its designated authentication provider. JAAS then passes the authenticated ID to the SAS trusted login module.
  5. The SAS trusted login module uses a trusted user connection to authenticate to the metadata server and retrieve the user's SAS identity.
    Note: This is actually a two phase process in which the module first asks the metadata server for a one-time-use password for the user and then establishes a connection to the metadata server under the user's ID and the generated one-time-use password. The figure omits these details.
    The metadata server looks up the user's ID in the metadata repository. As usual, this step doesn't involve password validation and isn't affected by authentication domain assignments. Only the user's ID is being matched (the authentication domain assignment in a login affects only credential reuse).
  6. The user's authenticated ID and SAS identity is passed to the SAS Logon Manager and then to the SAS Authentication Service.
  7. The authentication service passes the user's identity information to another SAS component (Remote Services), which runs in its own Java virtual machine (JVM), outside of the Web application server.
  8. Remote Services initiates a second trusted user connection to the metadata server. The purpose of this connection is to obtain additional information for the user's context.
    Note: As in step five, the trusted user connection is actually a two phase process.
  9. The additional user context information is returned.