CA SSO Agent for Siebel Guide › Overview and Architecture

Overview and Architecture

This section contains the following topics:

Background

Increased Security with Tier 2 Integration

Architecture

Background

The Web is becoming the standard interface for newly deployed applications. In an effort to meet the requirements of customers and to enable more widespread use of applications, many leading ERP vendors, including Siebel, have developed either web‑based versions of applications or web-based front ends for applications. As a minimum, these web-based front ends provide:

• A standard look and feel for employees
• User authentication
• Basic security (user identity and password)
• Single sign-on (SSO) capability

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 Siebel. This integration enables the Siebel .COM‑based applications to coexist with other portals and web applications, while offering the maximum user experience and benefit.

Increased Security with Tier 2 Integration

Tier 1 Integration

Tier 1 integration typically describes the process in which an underlying application reads and interprets the authentication information passed by CA SSO so the application (Siebel) can log the user in and create its own session if necessary. Tier 1 integration is the minimum security required to provide SSO. With Tier 1 integration, the underlying application fully trusts that the information was sent from CA SSO and does no verification. Tier 1 integration can leave important integration issues untouched, such as session timeouts. In Tier 1, the point of trust is entirely within the first tier—the web server. This design is adequate in environments where the application server and web server are located entirely on a trusted network, where security requirements are low to moderate.

Tier 2 Integration

In Tier 2 implementation, the point of trust moves away from the web server and into a more trusted host, in this case the Siebel Object Manager.

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, ostensibly, from the web agent. The API used in this integration is a Siebel-specific API called the Security Adapter API.

Session Linking

Many web-based applications use an independent session management scheme, frequently through the use of a cookie. Therefore, 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.

Due to the enormous value of the data stored in Siebel, CA believes that extra security measures are warranted. The integration documented here includes the SessionLinker component, whose purpose is to prevent such session synchronization issues. SessionLinker is a web server plug-in that monitors the CA SSO Session ID header and Siebel session cookie. When the two sessions diverge, action is taken to prevent the application from operating until a new session within Siebel is established. By default the action is to destroy the Siebel session, which causes Siebel to create a new session for the correct user.

Note: For more information about SessionLinker, see the SessionLinker Guide.on the CA Support site.

Architecture

Components

Following are the main components of this product:

• An Active Response that generates an “Authentication Ticket” securely identifying the user.
• Siebel templates and a session initiator page.
• A CA SSO-enabled Siebel Security Adapter conforming to Siebel’s Security Adapter API.
• The web server code used for initiating a Siebel session through the Security Adapter.
• An authentication scheme that accepts the Authentication tickets generated by the Active Response.
• SessionLinker, which is a web server plug-in that maintains a mapping from the CA SSO session to the Siebel session to prevent session hijacking attacks.

  Note: For more information, see the SessionLinker Guide.

Conventional Environment

In a conventional Siebel COM environment, users connect to a web server, which in turn connects to the Siebel Server. The web server collects the user’s credentials and transports them to the Siebel Server, which validates them, generates a session cookie, and outputs HTML content to the user. See the following illustration:

Integrated Environment

The flow changes after CA SSO and this product are added to the environment. Before reaching the Siebel Web Engine on the web server, the web agent either collects and verifies the user’s credentials or verifies an existing CA SSO session by communicating with the Policy server. A single sign-on ticket is generated and passed through the Siebel server in place of the user’s password. The web agent allows the request to be passed on to the Siebel Web Engine.

The Siebel Web Engine passes the request along to the Siebel server – including the username and ticket (in place of a password). The Siebel server, via a customized Security Adapter, communicates with the Policy Server to verify the username and ticket.

In an integrated environment, user authorization and data access within Siebel continue to operate exactly as they had without the SSO agent.

Thick Clients

In addition to single sign-on through the web, this product supports conventional Siebel thick clients authenticating with username and passwords through the Siebel server. Once this product is installed, user passwords stored in the database are no longer accepted for authentication; instead users need to present their CA SSO username and password.

Note: Through a number of means, Siebel is enabled to accept the CA SSO username and password as well as the database username and password. To enable this support, you will need to configure the Policy Server to authenticate users out of both the enterprise directory and the Siebel database. Contact Technical Support for further information.

Data Flow

The following illustration shows the various components within an integrated CA SSO/Siebel installation in more detail.

Note: Certain components are omitted – for example the user directory, the Siebel database, and additional CA SSO responses are not shown, nor are the normal IsProtected, Login, and IsAuthorized calls shown.

The steps in the preceding illustration are the following:

1. User makes a request to the Siebel application, for example, http://machine.domain:port/service_enu.
2. Web Agent intercepts the request, and uses Policy Server to perform Authentication/Authorization.

   Note: If the Siebel responses are configured for a Get-Post rule under the realm protecting the Siebel application in the Policy Server, steps 3, 4 and 5 are implemented. Otherwise, control passes to step 6.

3. If the authentication by Policy Server is successful, the following takes place:
   • Active Response is fired, and generates the Siebel Authentication Ticket, SIEBELTICKET. This authentication ticket is specific to the user accessing the application.
   • Siebel user response is fired, sending a user attribute, whose value maps to a valid Siebel user.
4. Relevant results are provided to the Policy Server.
5. Web Agent receives the Active response and Siebel user response from Policy Server, and generates the HTTP headers for these responses: HTTP_SIEBELTICKET and HTTP_SIEBELUSER. These responses are sent to the session launching code.
6. The Siebel web component (SWSE) intercepts the request, performs some Siebel-controlled request transformation, and sends the request to Siebel Object Manager using Anonymous user credentials.
   1. On receiving the request from SWSE, Siebel Object Manager checks for the Anonymous user credentials before sending the Siebel Login Web template (SWELogin.swt) customized with the Siebel Agent session launching code back to the SWSE. For verifying the anonymous user credentials, Object manager calls Security Adapter (or Security Provider).

      Security Adapter verifies the passed Anonymous user credentials against the Anonymous username/password credentials specified in the SmSiebelSSO.conf file.

      Once the Anonymous user credentials are successfully verified, the customized SWELogin.swt is fetched and sent to SWSE.

   2. SWSE converts the modified SWELogin.swt into HTML format, and redirects the request to the /SiebelConnector/siebelstartup.asp hosted at the web server. A typical URL format for such a redirection is as follows:

      http://<machine.domainname:Port/SiebelConnector/siebelstartup.asp?URL=http%3A//corsairerp.ca.com/service_enu/start.swe%3FSWECmd%3DStart%26SWEHo%3Dcorsairerp.ca.com

   3. Since the /SiebelConnector/* resources are protected by Policy Server using Siebel SSO Authentication scheme, the web agent validates the user session from the Policy Server.

      Step 3 is carried out, and the Siebel Authentication Ticket (SIEBELTICKET) and SIEBELUSER responses are generated. Web Agent receives the above responses and generates HTTP headers HTTP_SIEBELUSER and HTTP_SIEBELTICKET from them.

      Important! The above two responses get fired irrespective of the fact that they have or have not got fired in the previous step 3. The values generated by these responses in the above two steps are used in the subsequent steps.

   4. siebelstartup.asp converts the URL into a form which SWSE uses to send the username and password to Siebel Object Manager.

      siebelstartup.asp extracts username (SIEBELUSER) and password (Siebel Ticket) from the HTTP request headers, HTTP_SIEBELUSER and HTTP_SIEBELTICKET, and places their values in ‘SWEUsername‘and ‘SWEPassword’ parameters respectively.

7. SWSE again sends the request to Siebel Object manager along with the above user credentials. Siebel Object Manager calls Security Adapter or Security Provider and passes the user credentials to it for verification.
8. Security Provider contacts Policy Server and accesses the protected resource /SiebelConnector/ (configured in the SmSiebelSSO.conf file) using the user credentials previously received (SIEBELUSER and SIEBELTICKET).
9. Policy Server uses the Siebel SSO authentication scheme to verify the user credentials.

   Authentication Scheme verifies the user credentials, SIEBELUSER, and the Siebel authentication Ticket (SIEBELTICKET).

10. The Siebel SSO Authentication scheme results are returned to Policy Server.
11. Policy Server returns the results of user credentials authentication back to Security Adapter. These results also contain relevant information, such as Siebel Roles and Siebel User Response.
12. Security provider checks the SIEBELUSER response returned previously against the response that was extracted from the HTTP headers. If the user credential authentication is successful and Siebel user responses match, Security Provider reports the results to Siebel Object Manager and creates a Siebel user context for the SIEBELUSER user, which creates a Siebel user session and sends the request to the main application startup page in the SWSE.

More information:

Monitoring the Processing of a Request