Siebel CRM Desktop for IBM Notes Administration Guide > Customizing Authentication > About CRM Desktop SSO Architecture >

Architecture That an SSO Session Uses

Figure 19 illustrates the architecture that an SSO session uses.

Figure 19. Architecture That an SSO Session Uses

Explanation of Callouts

The architecture that an SSO session uses includes the following items:

1. Request handler. Accepts each request from the Outlook Bridge, wraps the request in an object that an SSO script can access, routes the request through SSO script, and then sends the reply from the SSO to the client. It initializes the script, registers the request handler to handle connector requests and initializes the request handler. For example, it reads configuration settings, initializes global variables, and so forth. It runs the function that the request handler code registers for callback. For each incoming connector request, the SSO script establishes or reuses an SSO session with the Siebel Server and sends a reply to this server. For more information, see Request Handler Function.
2. Update checker. Calls the SSO script that runs autoupdate. It does this work the first time this session uses this script. For more information, see Installing CRM Desktop SSO If You Use Autoupdate.
3. SSO script downloader. Downloads and prepares the SSO script.
4. Script context handler. Uses one instance of a Microsoft ActiveScript engine that runs SSO script and sends a reply to a request handler notification.
5. Web Browser handler. Displays an interactive login prompt to user, interprets the login information that this user enters, and notifies the SSO script.
6. Storage handler. Handles persistent and session storage.
7. Cookie manager. Gets and sets Internet Explorer cookies.
8. Cookie and form processor. Processes cookies, forms, and redirects. For more information, see Cookie Handling.

To customize the following items, you can reuse SSO objects or you can use your own set of common code. For more information, see CRM Desktop SSO Objects You Can Customize.

• Script context handler
• Storage handler
• Cookie and form processor

You cannot use JavaScript to customize items in Figure 19 that use C++ code, but you can change registry settings that affect these items.

SSO Script Lifecycle

If CRM Desktop SSO is enabled, and if the first connector starts, then CRM Desktop SSO loads the SSO module into Siebel CRM Desktop and it remains loaded until CRM Desktop closes.

The SSO script context includes all JavaScript global variables and state information. It is part of the SSO session data.The SSO Session Manager creates it and it exists until the SSO session ends.

Requests to start or end a session depend on the connector lifetime. CRM Desktop SSO starts a new session when it starts each new connector instance. If it ends a connector instance, then it also ends the SSO script context.

SSO Script Autoupdate

If SSO Script Autoupdate is enabled, then this Autoupdate determines if updated SSO script is available. If updated script is available, then CRM Desktop SSO loads this updated script instead of loading the old script. This configuration might result in the memory containing multiple versions of SSO script and SSO script context. When the connector sessions finish, CRM Desktop SSO unloads any old SSO script that exists and replaces it with the updated script.

Sharing Information Between Contexts

CRM Desktop SSO isolates script contexts and makes them independent from each other. To avoid unnecessary reauthentication, a script can handle different SSO sessions that share information. To do this, CRM Desktop SSO uses the settings_cache global object to read the configuration from one SSO session and reuse it or modify it in another SSO session.

SSO Script Operation

This topic describes SSO script operation.

Initialization

CRM Desktop SSO initializes SSO script when it creates a new SSO session. The initialization code must register a handler for the request_handler so that it handles connector requests and does the initialization that makes sure request handling is operational. For example, to set the read configuration settings, initialize global variables, and so forth.

Request Handling

To handle an SSO script request, CRM Desktop SSO runs a function for the request_handler callback. SSO script establishes or reuses an SSO session with the Siebel Server and returns a reply from this server for each incoming connector request.

Credentials Handling

CRM Desktop SSO handles credentials in one of the following ways:

• Noninteractive authentication. Sets user credentials in the CRM Desktop login dialog box and then communicates them to the SSO script through the get_sso_username function and the get_sso_password function of the sso_client global object.
• Interactive authentication. Does not send user credentials to SSO script. This SSO script must make sure that CRM Desktop allows the user to authenticate and that the authentication session runs correctly. It must use the ia_state object to capture cookie information and then use this information in the request and reply with the Siebel Server.

Cookie Handling

CRM Desktop SSO uses the WinHTTP protocol to support cookie handling. For more information, see the topic about Manual and Automatic Cookie Handling in the Cookie Handling in WinHTTP topic in the Dev Center - Desktop section of the Microsoft Developer Network web site.

The execute_request call returns cookies that the Siebel Server sets as part of the HTTP handling. WinHTTP interprets this call and adds it to the cookie cache that CRM Desktop SSO reuses during subsequent requests. The client can also specify cookies and then add them to a request. Interactive authentication requires special handling of cookies. Noninteractive authentication uses WinHTTP while interactive authentication uses Internet Explorer. CRM Desktop SSO sends all required cookies from the script session to the Internet Explorer session before it starts an interactive authentication. CRM Desktop sends these cookies back to the WinHTTP noninteractive session after interactive authentication finishes.