1 – Setup > 1.3 Viewpoint security configuration > Integrating with Single Sign-On (SSO) authentication

Integrating with Single Sign-On (SSO) authentication

This topic explains Viewpoint's SSO implementation and describes what you must do to set it up on your system. It contains the following sections:

Overview of SSO implementation in Viewpoint

Viewpoint can be configured to work in some types of single sign-on (SSO) environments. SSO allows a user to access many different applications without being prompted to log in for each application. With SSO, the user logs in once to a central authentication service (CAS)—like SiteMinder, for example—and then they are able to browse to multiple applications without having to re-enter a username and password.

To use Viewpoint in an SSO environment, Viewpoint must run behind a proxy like Apache Web Server. Apache must intercept all HTTP requests to Viewpoint and redirect unauthenticated requests to the external authentication service. Once this service authenticates the user, Apache allows the HTTP request to continue on to Viewpoint. Apache adds an HTTP header that indicates to Viewpoint the username of the authenticated user. Viewpoint then queries MWS for user permissions. For authorization, MWS queries LDAP directly to discover the user's group memberships and OUs. (This information is used to identify the principals and roles for the user.) Viewpoint trusts that the user in the HTTP header has already been authenticated and will NOT prompt the user for a password. Once Viewpoint knows which user has logged in, it will grant the user permissions based on his or her principals and associated roles. (For more information on configuring principals, see About principal management.)

Click to enlarge

Once a user logs out, Viewpoint does not allow access to any pages until another user logs in to the CAS. When another user logs in to the CAS, Apache will forward the new username in an HTTP header to Viewpoint. Viewpoint creates a new session and queries MWS for the new user's permissions.

For example, say Bob logs in to the CAS, looks at his Viewpoint nodes and services, and then clicks the Log out link. Because you configured the Log out link to point to the CAS login page (see Configuring the Log out link), Bob's web browser will be redirected to the CAS login page. Bob walks away. Alice now sits in front of Bob's machine and logs in using her CAS username and password. Apache then forwards Alice's username to Viewpoint in an HTTP header. Since Bob's session ended with his logout, Viewpoint examines the headers of the next HTTP request and creates a new session for Alice. Alice's session lasts until she clicks the Log out link or until her session times out.

Performing initial Viewpoint setup

There is a potential problem when initially setting up Viewpoint with SSO. Describing this issue requires some background information. Viewpoint relies on an MWS connection to authorize user logins. The only user that does not require this MWS authorization is the super user. The idea is that the super user can log in and configure the MWS connection that will then provide authorization for other users to log in. Now, the problem is: What happens if the super user does not exist in your central authentication service (CAS)? If you cannot log in as the super user, you cannot configure Viewpoint's connection to MWS. Without that connection, there is no user authorization.

So here is the proposed solution. You must first log in as the super user and configure the Viewpoint connection to MWS, set up roles, and set up LDAP principals before you set up the SSO solution.

To configure Viewpoint before setting up SSO

  1. Log in to Viewpoint as the super user.
  2. Configure Viewpoint's connection to MWS.
  3. Create a principal that contains the administrator role (or another role with all permissions).
  4. Verify that the user in your administrator principal can log in through CAS.

Once you have done this, you can place Viewpoint behind Apache, set up your SSO solution (see Configuring Viewpoint to trust the username in an HTTP header), log in as the new administrator (with the CAS username you set up in the principal), and finish configuring Viewpoint.

Configuring Viewpoint to trust the username in an HTTP header

To configure Viewpoint to trust the username in an HTTP header

Set the following parameter in the ViewpointConfig.groovy file:

http_header_authentication = true

Warning! When http_header_authentication is set to true, Viewpoint must run behind a proxy that redirects unauthenticated requests to an external authentication service. If Viewpoint is not run behind a proxy, any user could masquerade as the super user simply by modifying the HTTP header to be the username of the super user. This could cause a very serious security breach.

The default HTTP header that Viewpoint reads to determine the authenticated user's username is called SM_USER. For example, if a GET request contains an HTTP header of SM_USER with a value of "bjones," then Viewpoint assumes that "bjones" has already logged in. If you want Viewpoint to read the username from a header other than SM_USER, configure the http_header_username parameter in ViewpointConfig.groovy. For example:

http_header_username = "SM_USER"

Configuring the Log out link

Users can terminate their Viewpoint session by clicking on the "Log out" link in the header. With an SSO implementation, you will most likely want to configure the Log out link to point to the CAS login prompt so that a different user can log in. These steps explain how this is to be done.

To configure the Log out link

  1. Open the navigation.xml file from the $VIEWPOINT_HOME directory.
  2. Within the <top-links> element, identify the Log out <top-link>.
  3. Modify the href attribute to contain the URL to your CAS login page.
  4. For example, if your CAS login page is " http://mysiteminderhost.mydomain/login", you would make this change:

    <top-links>
      <top-link href="http://mysiteminderhost.mydomain/login" target="thisWindow" label="Log out"/>
    </top-links>
  5. Save the navigation.xml file.

Related topics 

© 2013 Adaptive Computing