CA SSO Agent for Oracle PeopleSoft Guide › Overview and Architecture

Overview and Architecture

This section contains the following topics:

Background

Increased Security with Tier 2 Integration

Architecture

Background

In an effort to meet the requirements of customers and enable more widespread use of applications, many leading ERP vendors, including PeopleSoft, have developed web‑based versions of their applications or web-based front ends for their applications. These web-based front ends provide:

• A standard look-and-feel for employees
• User authentication
• Basic security (such as login by username and password)
• Single Sign-On (SSO) capability for some of these front ends

CA SSO lets you create a centrally managed environment, providing a secure, personalized user experience across all web applications. Through published interfaces, CA SSO can authenticate users to PeopleSoft. This integration enables the PeopleSoft web-based infrastructure and applications to coexist with other portals and web applications, while offering the maximum user experience and benefit.

Increased Security with Tier 2 Integration

Successful approaches to centrally managed security have typically included the use of a standard Web Agent on a front-end web server and a small piece of PeopleCode that enables PeopleSoft to trust the contents of an HTTP header inserted by CA SSO. Such designs depend upon a level of trust of the front-end web server, a compromise of which could be used to gain elevated access to the system. CA SSO labels these designs Tier 1 because the point of trust is entirely within the first tier—the front-end web server. In environments where the application server and front-end web server are located entirely on a trusted network, where security requirements are low to moderate, this design is adequate.

In Tier 2 implementation, the point of trust moves away from the front-end web server and into a more trusted host—in this case the PeopleSoft application server. In Tier 2 integrations, the application that implements the application logic and security is given the ability to call CA SSO APIs to communicate with a Policy server, to validate the information that is presented from the Web Agent.

Many web-based applications use an independent session management scheme, frequently through the use of a cookie. Therefore, the replay prevention and session management logic of CA SSO may be bypassed. The possibility that the CA SSO and application sessions could lose synchronization with each other is one of the main security problems when integrating applications that maintain their own sessions. Tier 2 integration includes a component to prevent such session synchronization issues. The SessionLinker web server plug-in monitors the CA SSO Session ID header and PeopleSoft session cookies. When the two sessions diverge, action is taken to prevent the application from operating until a new session within PeopleSoft is established. The default action is to destroy the PeopleSoft session, causing PeopleSoft to create a new session with the correct user information.

Architecture

The following illustration shows a typical environment.

A description of the numbers in the preceding illustration follows:

1. The user accesses the PeopleSoft application using the front-end web server.
2. Web Agent hosted on the web server intercepts the request, and determines whether the Policy Server is protecting the requested application or resource. If the resource is protected, Web Agent attempts to authenticate and authorize the request for access to PeopleSoft web application resources.
3. The Policy Server verifies access permissions and returns PeopleSoft username back to the Web Agent for use in PeopleSoft.
4. The web server passes user security context to an Optional Application Server for transmittal to the PeopleSoft application server.
5. The application server transmits the request to the PeopleSoft application server. Credentials (user security context information) for the DEFAULT_USER variable are carried to PeopleSoft. The PeopleSoft application server begins a session by invoking Signon PeopleCode.

   Note: The DEFAULT_USER account has no access to the system with or without CA SSO's approval; if someone were to obtain and attempt to use that account without CA SSO, no access would be granted and no data would be available.

6. Signon PeopleCode retrieves the existing CA SSO session information and calls the Tier 2 Validation Library to validate the information.
7. The Validation Library (SMPSLoginLib) calls the Policy Server with existing session information.
8. The Policy Server returns authorization information to the Validation Library.
9. The Validation Library returns the result to PeopleCode, which sets the PeopleSoft security context to that of the user.

Because PeopleSoft deployments vary, the preceding illustration may not reflect any particular customer’s actual environment. For example, the Optional Application Server might not be present. However, the diagram is representative of most typical deployments.