Using the Single Signon API

PeopleSoft provides a component interface named PRTL_SS_CI that enables external applications to seamlessly integrate a single signon solution with the PeopleSoft portal applications. This ensures that users who have already signed in to the portal don't have to sign in again for every system you reference in your portal.

To take advantage of the Single Signon API, you need to create a custom API, which includes building the dynamic link libraries, classes, and registry settings necessary to enable an external application to communicate with PeopleSoft software.

Note:

Due to constraints imposed by the PeopleCode SwitchUser built-in function, PRTL_SS_CI does not work properly when called from PeopleCode. Only external applications, such as Java, Visual Basic, and C/C++ programs, can access PRTL_SS_CI.

The files of your custom API need to reside on the client machine; that is, the web server for ASP, and the machine running the Java program for Java. The registry file may also need to be used to update the registry with the new libraries.

Understanding the Signon Process with the API

The PRTL_SS_CI Component Interface contains two user-defined methods:

  • Authenticate

    Your external authentication program distributes an authentication token that can be retrieved from a cookie in the browser. The Authenticate function determines if an authentication token is valid.

  • GetUserID

    If the token is valid, you use the GetUserID function to retrieve the User ID associated with the authentication token.

Before we describe the development requirements of your API, PeopleSoft recommends that you take a moment to examine the steps that occur internally when you use the API in conjunction with the delivered PRTL_SS_CI.

Step Description

1

The user enters the User ID and password into the PeopleSoft portal sign in page.

2

If the login on portal application server is successful, the server generates a single signon token. The web server receives the single signon token from the application server, and issues a cookie to the browser.

3

The user navigates in the portal and encounters a link to the external system. The user clicks the link.

4

The browser passes the PS_TOKEN cookie to your external web server.

5

The external web server checks for the PS_TOKEN cookie before displaying a sign in page.

6

Once it is determined that the user is accessing your application through the PeopleSoft portal, you retrieve the authentication token and send it to the PRTL_SS_CI component interface to verify authentication.

7

After the system authenticates the token, the system can then make calls to the PRTL_SS_CI.Get_UserID function to return the appropriate User ID.

Developing your External Application to Support Single Signon

Developers of the external applications need to alter the signon process to conform to the following requirements.

  1. Check for the PS_TOKEN cookie.

    If the cookie doesn’t exist, continue with your normal signon process. Otherwise, bypass the sign in page.

  2. Retrieve the authentication token from the PS_TOKEN cookie.

  3. Make a connection to the PeopleSoft system through the PRTL_SS_CI API.

  4. Pass the authentication token to the Authenticate() function of the API.

  5. If the function returns True, you then the Get_UserID() function retrieves the user ID associated with the authentication token.

Note:

The component interface is not mapped to data because the key field for the data would be the authentication token. This token is dynamically assigned when the user signs in to the portal, and it is not stored anywhere in the system as data. Therefore, there are no key fields and the token is passed directly to the user defined functions.