12Customizing Authentication
Customizing Authentication
This topic describes how to customize authentication for Siebel CRM Desktop. It includes the following topics:
Overview of Customizing Authentication
This topic describes an overview of single sign on for Siebel CRM Desktop. It includes the following topics:
Authentication That Comes Predefined with Siebel CRM Desktop
Types of Authentication That You Can Use With Siebel CRM Desktop SSO
Siebel CRM Desktop SSO (Siebel CRM Desktop Single Sign On) is a single sign on feature that allows the user to log in to Siebel CRM Desktop one time and use Siebel CRM Desktop features without being prompted to log in again to gain access to features that use access control. It allows you to implement single sign on for the Siebel CRM Desktop client. It uses the Web transport protocol and the HTTP or HTTPS protocol. It supports standard Web browser functionality, such as HTTP forms, cookies, and process redirects. It provides the following capabilities:
Customizable architecture. You can install Siebel CRM Desktop SSO as an add-on. Beginning with Siebel CRM Desktop version 3.1, the Siebel CRM Desktop installer automatically includes Siebel CRM Desktop SSO.
Supports your existing Web single sign on feature. You can customize Siebel CRM Desktop SSO so that it works in your network topology and for mobile or remote access.
Supports your custom user interface. You can use Siebel CRM Desktop SSO that is automated and transparent to the user. You can also use it with a custom authentication screen that you already use, perhaps that includes your company branding.
Supports typical login name and password authentication or custom authentication that requires more than just a login name and password.
Handles single sign on, session, and network errors in a way that is transparent to the user.
Unless noted otherwise, support for features that this chapter describes begins with Siebel CRM Desktop version 3.1.
Authentication That Comes Predefined with Siebel CRM Desktop
This topic describes authentication that comes predefined with Siebel CRM Desktop.
Direct Connection
Siebel CRM Desktop can connect to an unprotected EAI (Enterprise Application Integration) endpoint for a direct connection. It comes predefined to use direct connection. For more information, see About Authentication and Session Management.
The following figure includes the dialog box that Siebel CRM Desktop displays for a direct connection. This dialog box allows the user to enter the user name and password.
Single Sign On
Siebel CRM Desktop SSO can protect EAI on the client. In this situation, Siebel CRM Desktop SSO displays a dialog box that is identical to the dialog box in the figure in the topic Direct Connection except the user sets the Auth Type field to SSO and the Siebel:SSOUser parameter determines if Siebel CRM Desktop SSO enables the User Name field. For more information, see Registry Keys That Control SSO for Credentials.
If you configure Siebel CRM Desktop SSO to use interactive authentication, then it displays another dialog box after the user clicks Login in the CRM Desktop-Login dialog box. The following figure includes an example of this second dialog box. For more information, see Types of Authentication That You Can Use With Siebel CRM Desktop SSO.
Types of Authentication That You Can Use With Siebel CRM Desktop SSO
This topic describes the types of authentication that you can use with Siebel CRM Desktop SSO.
How Siebel CRM SSO Starts and Stops Interactive Authentication
If the POST request to the EAI web service returns one of the following values, then CRM Desktop SSO starts interactive authentication:
HTTP Redirect (302)
HTML content
CRM Desktop SSO does one or more request and reply iterations during an interactive authentication. It monitors these iterations for the presence of one of the following stop conditions. If it encounters one of these conditions, then it stops the iteration:
If the setting for the EndpointRegExp registry key is:
Not defined. The URL must match the URL parameter that resides on the Login dialog box. This setting is the default value.
Defined. The destination URL must match the EndpointRegExp registry setting.
If the setting for the SuccessLoginRegExp registry key is:
Not defined. The HTML body must match the expression that the Siebel EAI server returns. This setting is the default value. For more information, see the description about SuccessLoginRegExp in Registry Keys That Control SSO for Siebel CRM Desktop.
Defined. The HTML body must match the setting of the SuccessLoginRegExp registry key.
The user can also close the dialog box at any time to stop interactive authentication. Siebel CRM Desktop interprets this closure and cancels interactive authentication. For more information, see Registry Keys That Control SSO for Siebel CRM Desktop.
Noninteractive Authentication
Noninteractive authentication is a type of authentication in CRM Desktop SSO that uses a separate dialog box as the login window for Siebel CRM Desktop. It includes the following functionality:
Save password. The user can set the Save Password option on the CRM Desktop - Login dialog box to one of the following values:
Include a check mark. CRM Desktop SSO stores encrypted credentials in the Windows Registry. It does not prompt the user for credentials the next time the user starts Siebel CRM Desktop.
Do not include a check mark. CRM Desktop SSO prompts the user for credentials the next time the user starts Siebel CRM Desktop and after the first SSO session starts. This behavior typically occurs during the first synchronization that occurs after the user restarts Siebel CRM Desktop.
Detect session expiration. If a CRM Desktop SSO session expires, then CRM Desktop SSO reestablishes the session without involving the user. CRM Desktop SSO requires user interaction only if the user credentials are not valid.
Use only the login name and password. Noninteractive authentication does not support multifactor authentication, such as requiring code from a security token in addition to the password.
Detect invalid user password. The SSO script can detect if the user enters an invalid password and then react accordingly.
Does not include Web pages. The user interacts only with Siebel CRM Desktop Web pages that do not include CRM Desktop SSO.
Benefits and Challenges of Using Noninteractive Authentication
If CRM Desktop SSO uses noninteractive authentication, then SSO script interprets HTTP requests and replies that do not involve the user. It handles HTTP redirects, HTML form submits, automatic submits, and so on. It emulates the user interaction that typically occurs during a login that is native to the Web browser.
Noninteractive SSO provides the following benefits:
CRM Desktop SSO can log in without user intervention.
CRM Desktop SSO can reestablish a session automatically. User interaction is required only if a password lockout occurs.
Noninteractive SSO provides the following challenges:
Requires slightly more customization than interactive authentication.
The implementation can be complex and difficult to scale. If you modify the login process that your company uses, then these modifications might be difficult to implement. For example, if your company must change from a simple username and password sign on to a complex sign on that requires more than these factors. In this situation, you must modify, test, and redeploy the SSO script.
Single Sign On Services That CRM Desktop SSO Supports
Predefined CRM Desktop SSO supports the following Web single sign on services:
ClearTrust
IBM Tivoli
Computer Associates Siteminder
Ping Federate
Customized CRM Desktop SSO can support other services, such as the following:
Capgemini SSO
CAS (Central Authentication Service)
Cosign
CRM Desktop SSO supports the following operating systems:
Windows XP SP3
Windows Vista SP1 and above
Windows 7
Installing CRM Desktop SSO
This topic describes how to install CRM Desktop SSO. It includes the following topics:
Starting with Siebel CRM Desktop version 3.1, it is not necessary to install CRM Desktop SSO. It comes predefined starting with these version. For more information about using an installation package, see Overview of Installing the Siebel CRM Desktop Add-In.
To install CRM Desktop SSO:
Verify the network and infrastructure:
Modify the Windows Registry settings, as necessary.
For more information, see Using the Windows Command Line to Set Optional Parameters for Siebel CRM SSO.
Make sure SSO script supports the single sign on capabilities that your implementation requires.
CRM Desktop SSO cannot connect directly to a single sign on system. To operate properly, it requires SSO script that you customize for the target single sign on system. For a list of options, see Windows Registry Keys You Must Set to Enable Siebel CRM Desktop SSO.
Determine the sequence you will use to install CRM Desktop SSO.
You can install, remove, or upgrade CRM Desktop SSO independent of Siebel CRM Desktop. You can install it before or after you install Siebel CRM Desktop.
Make sure you are a member of the Administrators group in Windows XP on the client computer.
This membership provides the rights you require to run the executable file that Siebel CRM Desktop SSO uses in the installation package.
Set the Windows Registry keys.
For more information, see Setting Windows Registry Keys to Enable Siebel CRM Desktop SSO.
(Optional) The installer calls the UAC (User Account Control) prompt in Windows Vista or Windows 7. To disable this prompt, you can set the following properties on the operating system on the client computer:
ALLUSERS=2 MSIINSTALLPERUSER=1
Copy the InvisibleSSOModule.msi file from the release location to the client computer.
To install CRM Desktop SSO, you use an installation package that comes predefined as a single MSI file. This file includes the following data:
Installation information for CRM Desktop SSO
CRM Desktop SSO binary files
To copy this file, you can do one of the following
Manually copy the InvisibleSSOModule.msi file to the client computer.
Use third-party deployment software to deploy the InvisibleSSOModule.msi file to multiple computers. For more information, see Installing Siebel CRM Desktop in the Background.
Log in to the client computer.
If Microsoft Outlook is open, then close it.
Locate the InvisibleSSOModule.msi installation package.
This location depends on where the user saves the InvisibleSSOModule.msi file. The following directory is a typical location:
C:\Documents And Settings\username\Desktop
Run the InvisibleSSOModule.msi installation package:
In the Welcome dialog box, click Next.
In the Customer Information dialog box, specify the user name and organization and then chose to do this install for a single user or for any user who uses this client computer.
If you choose to do this installation for any user who uses this client computer, then you must be a member of the Administrators group. If you are not, then this installation will fail.
It is recommended but not required that you use the same installation configuration for Siebel CRM Desktop SSO that you use for Siebel CRM Desktop. For example, if you install Siebel CRM Desktop for each user, then it is recommended that you install Siebel CRM Desktop SSO for each user. if you install Siebel CRM Desktop for anyone who uses this computer, then it is recommended that you install Siebel CRM Desktop SSO for anyone who uses this computer. If you do not use this configuration, then Siebel CRM Desktop SSO might not be available for some users.
In the Destination Folder dialog box, specify the folder where the installer must install CRM Desktop SSO.
You can specify a directory. For more information, see Setting the Installation Directory for Siebel CRM Desktop SSO.
In the Ready to Install the Program dialog box, click Install.
Because you can install Siebel CRM Desktop for multiple users, the user who is currently logged in can view application files that Siebel CRM Desktop stores in the default directory described in Setting the Installation Directory for Siebel CRM Desktop SSO.
In the InstallShield Wizard dialog box, click Finish.
The installer installs CRM Desktop SSO. The next time Siebel CRM Desktop starts it loads CRM Desktop SSO according to the Windows Registry settings. For more information, see Setting the Installation Directory for Siebel CRM Desktop SSO.
After you complete the installation, CRM Desktop SSO is configured and Siebel CRM Desktop uses it when it communicates with the Siebel Server.
Notify the user that CRM Desktop SSO is installed.
Setting Windows Registry Keys to Enable Siebel CRM Desktop SSO
This topic describes Windows Registry settings that you must set if you install Siebel CRM Desktop for Siebel CRM Desktop version 3.1. You do not set registry keys with version 3.1, or later. This description applies only to installing Siebel CRM Desktop. It does not apply to using the InvisibleSSOModule.msi installer.
To set Windows Registry keys to enable Siebel CRM Desktop SSO
Enter the required command-line parameters when you run msiexec.exe.
For example:
msiexec.exe /I CRMDesktop.msi SSOENABLE=1 SSOSCRIPTINCLUDEPATH=%appdata% SSOURL=http://myurl
For more information, see Windows Registry Keys You Must Set to Enable Siebel CRM Desktop SSO.
Options for Installing CRM Desktop SSO
This topic describes options for installing CRM Desktop SSO. It includes the following topics:
Installing Siebel CRM Desktop SSO If You Do Not Use Autoupdate
Using the Windows Command Line to Set Optional Parameters for Siebel CRM SSO
Setting the Installation Directory for Siebel CRM Desktop SSO
Siebel CRM Desktop version and later comes predefined with these options enabled. It is only necessary to enable these options if you are using version 3.1 or earlier.
Installing Siebel CRM Desktop SSO If You Use Autoupdate
Autoupdate is a Siebel CRM Desktop SSO feature that automatically updates the SSO script if any change occurs to this script. Siebel CRM Desktop SSO scripts must reside in a single ZIP file. The Siebel CRM Desktop SSO installer uses the SSOURL parameter to determine the file path where these scripts reside. Siebel CRM Desktop SSO uses this location to download these scripts during installation and later during updates. This configuration allows you to deploy Siebel CRM Desktop SSO across your enterprise. It makes sure that the scripts on each client are consistent and valid. If autoupdate is enabled, then Siebel CRM Desktop SSO deploys the SSO script as a single ZIP file.
To install Siebel CRM Desktop SSO if you use autoupdate
Enter the following parameter on the msiexec command line anywhere after
CRMDesktop.msi:SSOENABLE=1 SSOURL=URL
For example:
msiexec.exe /I CRMDesktop.msi SSOENABLE=1 SSOURL=http://myurl
You can also set the following optional parameters:
SSOSCRIPTINCLUDETEMPLATE = template SSOCHECKINTERVAL = new interval SSOSCRIPTFILENAME = file name
For more information, see Using the Windows Command Line to Set Optional Parameters for Siebel CRM SSO.
Installing Siebel CRM Desktop SSO If You Do Not Use Autoupdate
If you do not use autoupdate, then you configure Siebel CRM Desktop SSO to read scripts from a fixed location that you specify on the local drive. If autoupdate is not enabled, then Siebel CRM Desktop SSO deploys the SSO script as separate JavaScript files.
To install Siebel CRM Desktop SSO if you do not use autoupdate
Enter the following command on the msiexec command line anywhere after
CRMDesktop.msi:SSOENABLE=1 SSOUPDATEDISABLE=1 SSOSCRIPTINCLUDEPATH=path_to_scripts
For example:
msiexec.exe /I CRMDesktop.msi SSOENABLE=1 SSOUPDATEDISABLE=1 SSOSCRIPTINCLUDEPATH=%appdata%
You can also set the following parameters optional:
SSOCHECKINTERVAL = new interval SSOSCRIPTFILENAME = file name
For more information, see Using the Windows Command Line to Set Optional Parameters for Siebel CRM SSO.
If you use MST or a prepackaged MSI, the you must make sure that the path that you specify for the SSOSCRIPTINCLUDEPATH parameter matches the path where you install the InvisibleSSOModule.msi file.
Using the Windows Command Line to Set Optional Parameters for Siebel CRM SSO
This topic describes how to use the Windows command line to set optional parameters for Siebel CRM SSO. CRM Desktop SSO supports all parameters that you can set in the Windows Installer msiexec command line. This option is not available starting with Siebel CRM Desktop version . CRM Desktop SSO comes predefined starting with these versions. For more information, see Using the Windows Command Line to Set Optional Parameters.
To use the Windows command line to set optional parameters
On the client computer, open the Windows command line interface.
Navigate to the directory that contains the InvisibleSSOModule.msi file.
For example:
c:\Documents And Settings\username\Desktop
Enter the Windows Installer command using the following format:
msiexec.exe /I InvisibleSSOModule.msi optional_parameter_1 optional_parameter_n
where:
optional_parameter is a parameter that the installer can run. For example:
msiexec.exe /I InvisibleSSOModule.msi INSTALLDIR=c:\My_Custom_Directory
Note the following conditions:
You must specify each optional parameter in the same command line after the name of the InvisibleSSOModule.msi file.
To separate each optional parameter, you must enter a space.
You can arrange optional parameters in any order.
Press Enter.
The CRM Desktop SSO setup wizard displays the welcome dialog box.
Abbreviating the Installation Procedure
To automatically run the windows that normally require user action, you can use the optional QR parameter. If you use it, then the InvisibleSSOModule.msi installation package does not display dialog boxes that require user action. This option is not available starting with Siebel CRM Desktop version 3.1. CRM Desktop SSO comes predefined starting with these versions.
To abbreviate the installation procedure
Append the QR parameter to the msiexec command.
For example:
msiexec.exe /I InvisibleSSOModule.msi INSTALLDIR=c:\My_Custom_Directory /QR
For more information, see Using the Windows Command Line to Set Optional Parameters for Siebel CRM SSO.
Setting the Installation Directory for Siebel CRM Desktop SSO
The InvisibleSSOModule.msi installation package saves binary files during installation in one of the following directories, by default:
Installation directory for each user on Windows 7 or Vista. For Windows XP, it installs the binary files into the following folder:
C:\Users\user\AppData\Roaming\
Installation directory for each computer:
C:\Program Files\InvisibleCRM\SSO\
To change this directory, the user can choose a different location in the InstallShileld wizard or you can use the INSTALLDIR parameter.
If you install CRM Desktop SSO for any user who uses this computer, then you must make sure that all users can read this directory. Predefined CRM Desktop SSO suggests a different directory depending on if you install for each user or for anyone who uses this computer.
This option is not available starting with Siebel CRM Desktop version 3.1. CRM Desktop SSO comes predefined starting with these versions.
To set the installation directory for Siebel CRM Desktop SSO
Enter the following parameter on the msiexec command line anywhere after the InvisibleSSOModule.msi name parameter:
INSTALLDIR=directory_path
For example:
msiexec.exe /I InvisibleSSOModule.msi INSTALLDIR=c:\My_Custom_Directory /QR
For more information, see Using the Windows Command Line to Set Optional Parameters for Siebel CRM SSO.
Removing or Upgrading Siebel CRM Desktop SSO
This topic describes how to remove or upgrade CRM Desktop SSO for versions that occur earlier than Siebel CRM Desktop version 3.1. For information about removing multiple users, see Removing the Siebel CRM Desktop Add-In for Multiple Users.
Removing Siebel CRM Desktop SSO for a Single User
This topic describes how to remove Siebel CRM Desktop SSO for a single user.
To remove Siebel CRM Desktop SSO for a single user
Log on to the computer where Siebel CRM Desktop SSO is installed.
Synchronize and back up all personal data:
In Microsoft Outlook, perform synchronization.
Backup personal data.
It is recommended that the user use the export feature in Microsoft Outlook to export personal data to a file.
Remove Siebel CRM Desktop SSO:
In Microsoft Windows, click the Start menu, choose Settings, and then click Control Panel.
In the Control Panel, right-click Add or Remove Programs and then choose Open.
In the Add or Remove Programs dialog box, in the Currently Installed Programs window, click Invisible SSO Module and then click Remove.
Siebel CRM Desktop removes the registry settings and the files that Siebel CRM Desktop SSO uses.
Upgrading Siebel CRM Desktop SSO
This topic describes how to upgrade Siebel CRM Desktop SSO.
To upgrade Siebel CRM Desktop SSO
Remove Siebel CRM Desktop SSO.
For more information, see Removing Siebel CRM Desktop SSO for a Single User.
Install Siebel CRM Desktop SSO.
For more information, see Installing CRM Desktop SSO.
About CRM Desktop SSO Architecture
This topic describes the architecture that CRM Desktop SSO uses. It includes the following topics:
Architecture That CRM Desktop SSO Uses
The following figure illustrates the architecture that CRM Desktop SSO uses.
Explanation of Callouts
The architecture that Siebel CRM Desktop SSO uses includes the following items:
Siebel CRM Desktop Bridge. Uses a customization package that allows Siebel CRM Desktop to synchronize data. This synchronization uses the credentials that the user provides.
Siebel Connector. Communicates information between Siebel CRM Desktop and Siebel CRM. It communicates through the SSO Connector to synchronize data, get the customization package, and open objects in Outlook
SSO Connector. A set of JavaScript files that Siebel CRM Desktop SSO deploys to the client during installation. Siebel CRM Desktop uses the SSO Connector as a proxy to emulate a direct communication channel to the Siebel Connector. It uses SSO script. It includes the following items:
SSO session. Includes state information and code that handles the request and reply that allows Siebel CRM Desktop SSO to establish, monitor, and exchange data between the connector and the Siebel Server. The Outlook Bridge uses the connector to start this session. To start multiple SSO sessions, this bridge can create a separate connector instance for each session.
SSO session data. Includes a global JavaScript context and other state information that the SSO script uses to track an SSO session.
SSO session handler. Each handler handles communication for a single SSO session.
Siebel CRM Desktop SSO Proxy. Proxy for the Siebel CRM Desktop SSO Connector that handles all requests from this connector and provides replies back to this connector.
Flow That Siebel CRM Desktop SSO Uses During Authentication
The following figure illustrates the flow that Siebel CRM Desktop SSO uses during authentication.
Explanation of Callouts
The architecture for Siebel CRM Desktop SSO does the following during authentication:
User opens Outlook and then enters user name and password or uses credentials that Siebel CRM Desktop saved during a prior session.
Siebel Connector sends SOAP request with saved credentials to the SSO Connector. CRM Desktop SSO is a plug-in to Siebel CRM Desktop and acts as a local HTTP proxy. If the agent SessionID cookie that Siebel CRM SSO uses is set, then flow continues to Step 9.
SSO Connector attempts to send a request to the SSO Agent.
If the Agent SessionID cookie that Siebel CRM SSO uses is not set, or if this cookie is expired, then the SSO Agent sends a request for authentication in an HTTP redirect form or in an HTML form. This HTML form allows the user to reenter authentication information.
SSO Connector detects a request for authentication and then starts interactive or noninteractive authentication.
SSO connector sends HTTP request to the SSO Agent.
The SSO Agent sends a reply to the client and does something depending on the following authentication that Siebel CRM Desktop uses:
Interactive authentication. The user must enter authentication information and then start the next step, for example, by clicking Login, and so forth.
Nonnteractive authentication. The SSO Connector interprets the HTML reply.
Step 6 and Step 7 might repeat multiple times until authentication successfully finishes. CRM Desktop SSO considers this authentication successful if the HTTP can redirect to the original Siebel EAI address. When it meets this criteria is met, The SSO connector can use the session cookies when authentication successfully finishes.
The SSO Connector sends the original SOAP request and the session cookies to the SSO Agent.
The request now includes valid session information so the SSO Agent sends the original SOAP request to Siebel Web Services.
Siebel Web Services sends a reply to the SSO Agent.
The SSO Agent sends this reply to the SSO Connector. If the Siebel Server does not reply with HTTP 200 or HTTP 500, or if the reply does not include XML content, then the session is not valid and CRM Desktop SSO goes to Step 5. The presence of XML content indicates that the user has logged in into the native Web SSO that the browser uses.
The SSO Connector sends a reply to the Siebel Connector for processing. The SSO Connector can store an Agent SessionID cookie while Outlook runs. It can reuse this cookie in subsequent connection attempts. If this cookie expires, then Siebel CRM SSO requests the user to log in again.
Flow That the Siebel CRM Desktop SSO DLL Uses
The following figure illustrates the flow that the Siebel CRM Desktop SSO DLL uses.
Explanation of Callouts
The Siebel CRM Desktop SSO DLL does the following:
Siebel CRM Desktop SSO loads the DLL.
The Instance Handler loads and initializes the DLL.
The Session Manager starts and maintains SSO sessions.
If you enable autoupdate, then the Update Checker automatically updates the script for each new session instance. For more information, see Installing Siebel CRM Desktop SSO If You Use Autoupdate.
The Session Data Controller stores the names and values of parameters that the SSO sessions share. It allows data exchange between SSO sessions and provides a single location to store data that these sessions can share. For more information, see About Authentication Sessions and Data Exchange Sessions.
The SSO sessions are a collection of SSO sessions that are currently active. For more information, see Architecture That an SSO Session Uses.
About Authentication Sessions and Data Exchange Sessions
Siebel CRM Desktop SSO can create the following types of sessions:
Authentication session. Starts if the user must change the login name and password or if Siebel CRM Desktop SSO requests the user to reenter the password to confirm these credentials. Note the following:
The SSO script does not use any cached information from a previous SSO session during an authentication session.
In some situations the SSO script cannot prevent Internet Explorer from allowing the user to access Siebel CRM Desktop without entering credentials. This situation typically occurs if CRM Desktop SSO uses a persistent cookie to identify the Web SSO user session. To allow the user to modify credentials when CRM Desktop SSO uses a persistent cookie, the user must use Internet Explorer to log out from Siebel CRM Desktop. This log out removes the persistent cookie. An authentication session prompts the user for a user name and password the next time the user attempts to connect to the Siebel Server from Siebel CRM Desktop.
Data exchange session. Starts during a normal operation, such as synchronization, opening the Control Panel, and so on. CRM Desktop SSO can create multiple data exchange sessions. To avoid displaying unnecessary login prompts, the SSO Connector caches any session cookies that exist in the shared session cache or that reside in the cookie cache that Internet Explorer uses.
Architecture That an SSO Session Uses
The following figure illustrates the architecture that an SSO session uses.
Explanation of Callouts
The architecture that an SSO session uses includes the following items:
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.
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 Siebel CRM Desktop SSO If You Use Autoupdate.
SSO script downloader. Downloads and prepares the SSO script.
Script context handler. Uses one instance of a Microsoft ActiveScript engine that runs SSO script and sends a reply to a request handler notification.
Web Browser handler. Displays an interactive login prompt to user, interprets the login information that this user enters, and notifies the SSO script.
Storage handler. Handles persistent and session storage.
Cookie manager. Gets and sets Internet Explorer cookies.
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 Siebel CRM Desktop SSO Objects You Can Customize.
Script context handler
Storage handler
Cookie and form processor
You cannot use JavaScript to customize items in the previous figure 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 Siebel 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 Siebel 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 Siebel 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. Siebel CRM Desktop sends these cookies back to the WinHTTP noninteractive session after interactive authentication finishes.
How Siebel CRM Desktop SSO Handles Errors
SSO script avoids creating JavaScript exceptions. If the user enables a JIT Debugger on the client computer, such as Visual Studio, then this debugger might display a separate prompt and debug message for each exception. These prompts can significantly affect the user experience. Siebel CRM SSO uses the following functions to handle exceptions:
cpp_exception_occurred
drop_exception
raise_not_logged_in_exception
raise_not_valid_exception
raise_cancel_exception
execute_request
The execute_request function is the only function that can fail with exception. It depends on the network state and the availability of Siebel Servers. If execute_request fails, then Siebel CRM SSO returns null instead of a response object to handle logic that does not include exceptions. The SSO Connector must examine the return code, determine if an error occurred, and then take corrective action.
If an exception occurs, then the SSO script does one of the following:
Pass error to Siebel Connector. Recreates the exception when flow returns to the Siebel Connector so that this connector can handle the exception. The SSO Connector script must finish running without calling any other execute_request function or calling a function that modifies the exception, such as a raise_value_ exception or drop_exception. It does this to avoid overwriting the original exception message that the script created as a result of the error.
Clear the exception. Use the drop_exception function to clear the exception.
Run another request. Use the other execute_request function to clear the previous exception.
Create an exception:
Use the raise_not_valid_exception function. In this situation, the user provided the credentials in the client but they are not valid.
Use the raise_not_logged_in_exception function. In this situation, the credentials are not complete or are missing.
For more information about these methods, see SSO Client Object.
How the SSO Script Sends an Error to the Connector
The following type of error determines how the SSO script sends an error to the connector:
Network error. If the execute_request function returns a value of Null, then the SSO script sends the error back to the connector and the connector processes the error.
Authentication or SSO script logic error. The SSO script translates the error to a not_valid or a not_logged_in error so that the corresponding function in the sso_client object can handle the error. It uses the following functions:
Uses the raise_not_logged_in_exception function for a not_logged_in error
Uses the raise_not_valid function for a not_valid error
User cancelled interactive authentication. The SSO script runs the raise_cancel_exception function to start a cancel_exception exception.
How the SSO Script Logs Errors and Messages
Siebel CRM SSO writes log messages to the Siebel CRM Desktop general log which simplifies debugging and gathering diagnostics. The SSO script logs information about the SSO API and application failures. For more information, see Logger Object.
Modifying SSO JavaScript
You can use the API (application programming interface) that comes predefined with CRM Desktop SSO (SSO API) to create a custom script that does the following:
Get HTML and XML pages
Submit forms
Follow redirects
Support cookies
CRM Desktop SSO uses JavaScript to implement the logic it requires. This script can accommodate some layout or workflow changes but it might be necessary to modify it to meet your deployment requirements. CRM Desktop SSO comes predefined with the following JavaScript files:
core.js and utils.js. A set of reusable functions and building blocks that handle authentication. The lib.js file includes detailed documentation in the source code that describes the API that you can use to customize CRM Desktop SSO.
sso.js. An entry point that handles authentication.
You must distribute any update you make by uploading the new script you create to an autoupdate location or you can use external provisioning. For more information, see Installing Siebel CRM Desktop SSO If You Use Autoupdate.
Siebel CRM Desktop SSO Objects You Can Customize
This topic describes the objects that you can use to customize Siebel CRM Desktop SSO. It includes the following topics:
SSO Client Object
This topic describes functions that you can use with the SSO client object. It includes the following topics:
To communicate the credentials that the user enters in the Siebel CRM Desktop login dialog box to the SSO script, CRM Desktop SSO uses the get_sso_username and get_sso_password functions of the sso_client object.
The sso_client object is a global object that is available anywhere in the main script file. The following registry key identifies this main script file:
SSO\ScriptFileName
For more information, see Windows Registry Keys You Must Set to Enable Siebel CRM Desktop SSO.
Create Request Function
The create_request function creates a request and returns a new request object. It uses the following format:
create_request(url, method, body, encoding)
where:
url is a string that contains the URL that identifies the request endpoint.
method is a string that identifies the HTTP request method. It can include one of the following values:
GET
POST
body is a string that contains the body of the request.
encoding is a string that identifies how to encode the request body. It can include one of the following values:
iso-8859-1
utf-8
utf-16
For example, the following code creates a simple GET request to a URL:
var req = sso_client.create_request("http:\\siebel\eai_enu", "GET", "", "utf-8");
For more information, see Request Object.
Decode URL Function
The decode_url function decodes a URL. It does the following:
Splits a URL into components and then reconstructs this URL. It adds any missing components.
Replaces encoded sequences into their corresponding values. The following format identifies a sequence:
%xx
where:
% represents percent encoding that allows you to encode information in a Uniform Resource Identifier (URI).
The decode_url function uses the following format:
decode_url(url)
where:
url is a string that contains the URL that the decode_url function decodes.
Encode URL Function
The encode_url function encodes a URL. It replaces each nonstandard character with the encoded value. The following format identifies a sequence:
%xx
The encode_url function uses the following format:
encode_url(url)
where:
url is a string that contains the URL that the encode_url function encodes.
Exception Occurred Function
The cpp_exception_occurred function is a Boolean function that returns True if the last call to an execute_request function resulted in C++ code creating an exception. Any subsequent call to the execte_request function resets a previously recorded exception, so you must use this function immediately after the call to the execute_request function.
Get Platform Cookie Function
The get_platform_cookie function gets the Internet Explorer cookie. It can only get Internet Explorer cookies that are persistent and that are not of type HTTPOnly. It uses the following format:
get_platform_cookie(url, name)
where:
url is a string that contains the URL that Siebel CRM Desktop SSO uses to get the cookie.
name is a string that contains the name of the cookie.
Interactive Function
The interactive function instructs the SSO script to use interactive authentication. It uses callbacks to monitor the state of the interactive session. CRM Desktop SSO runs the statement that occurs immediately after the statement that calls the interactive function only after the interactive authentication finishes. While interactive authentication runs, the SSO script gets notifications from the function that the callback parameter identifies. This callback delivers the information that this script requires to monitor the interactive authentication. It can send a request to stop the interactive authentication when the interactive session finishes.
The interactive function uses the following format:
interactive(ia_state, callback)
where:
ia_state is a string that identifies the object that contains information about interactive authentication.
callback is a string that identifies the function that CRM Desktop SSO calls on every change that occurs in the ia_state.status. This callback must return a Boolean value. If it returns True, then CRM Desktop SSO stops the interactive authentication. ia_state is an object that the sso_client.create_ia_state function creates and then uses to control how interactive authentication runs. The callback is a function that returns one of the following values:
true. Interactive authentication finished.
false. Interactive authentication has not yet finished.
The following example does a simple callback for interactive authentication. It does not do any processing. It always return false to indicate that CRM Desktop SSO must display the native browser dialog box in every subsequent web page where the user navigates:
function ia_callback(ia_state)
{
switch (ia_state.status) {
case "before":
// before navigate to url
break;
case "finished":
// page download complete
break;
case "cancelled":
// user closed dialog
break;
}
return false;
}
This example includes the following code. This code is part of the request handler function:
var ia_state = sso_client.create_ia_state(); ia_state.url = url; ia_state.dialog.width = 1024; ia_state.dialog.height = 768; ia_state.dialog.title = "SSO"; ia_state.dialog.visible = false; sso_client.interactive (ia_state, ia_callback);
Request Handler Function
CRM Desktop SSO routes each request from the Siebel Connector through the request_handler function. This function handles requests that occur from the Siebel Connector to the Siebel Server. This request_handler function expects a single argument that contains the initial request object from the SSO Connector. It sends a return value to the SSO Connector as if the Siebel Server sent this reply. The Siebel Connector is a proxy that resides between the Siebel Connector and Siebel Web Services. The SSO Agent protects these Web services. This proxy hides the SSO Agent from the Siebel Connector.
The following example includes a CRM Desktop SSO script that passes all requests from the Siebel Connector to the Siebel Server without doing any processing. This example is for illustration purposes only. An actual SSO Connector script includes the process_request function to do processing:
sso_client.request_handler = process_request;
function process_request(request)
{
return sso_client.execute_request(request);
}
The following line from this code defines the entry point where Siebel CRM Desktop SSO registers the handler:
sso_client.request_handler = process_request
Set Platform Cookie Function
The set_platform_cookie function sets the Internet Explorer cookie. It can only get Internet Explorer cookies that are persistent and that are not of type HTTPOnly. It uses the following format:
get_platform_cookie(url, name, value)
where:
url is a string that contains the URL that Siebel CRM Desktop SSO uses to set the cookie.
name is a string that contains the name of the cookie.
value is a string that contains the data that Siebel CRM Desktop SSO associates with the cookie.
For example:
sso_client.set_platform_cookie("http:\\example.com", "Cookie_name",
"Cookie_value");
Other Functions That the SSO Client Object Includes
You can use the following functions in the SSO Client object. Siebel CRM Desktop supports each of these functions starting with Siebel CRM Desktop version except for the execute_request function. Support for the execute_request function starts with an earlier release:
create_ia_state. Creates and returns a new ia_state object. Siebel CRM Desktop SSO uses this object for initial configuration with interactive authentication to send status information. ia_state is an object, while create_ia_state is a function that creates the ia_state object. For more information, see Interactive State Object.
execute_request. Runs the request and returns a reply. It accepts a request from the request_handler function or a request that the create_request function creates. It uses the following format:
execute_request(request_object)
get_sso_username. Gets the user name that the user provides in noninteractive authentication. Siebel CRM Desktop SSO does not use this function for interactive authentication.
get_sso_password. Gets the password that the user provides in noninteractive authentication. Siebel CRM Desktop SSO does not use this function for interactive authentication.
drop_exception. Drops any exceptions that the connector reports. If the script finishes running after Siebel CRM Desktop SSO calls this method, then Siebel CRM Desktop SSO does not create an exception.
raise_not_logged_in_exception. Drops any not_logged_in exceptions that the connector reports and then creates a not_logged_in exception with a description that states it cannot process the login because a problem occurred with the Siebel Server or credentials are not valid. Siebel CRM Desktop SSO does not stop the session flow. The SSO script must finish running correctly before the connector creates the exception.
raise_not_valid_exception. Drops any not_valid exceptions that the connector reports and creates a not_valid exception with a description that states the user password is not valid or is missing. Siebel CRM Desktop SSO does not stop the session flow. The SSO script must finish running correctly before the connector creates the exception.
raise_cancel_exception. Clears any reported exception. It creates the following exception for the SSO Connector:
cancelled
CRM Desktop SSO does not stop the session flow. The SSO script must finish running the request_handler after it creates an exception.
Logger Object
The logger object is a global object that is available anywhere in the main script file. It allows Siebel CRM Desktop SSO to log messages to a general log. It uses the following format:
log(component,message,class)
where:
component is a string that identifies the source of the log message
message is a string that identifies the message that Siebel CRM Desktop SSO logs.
class is a string that identifies the error class.
For example:
logger.log ("SSO", "Sample message", 0);
Settings Cache Object
The settings_cache object is a global object that is available anywhere in the main script file. It is a shared name-value cache. Multiple SSO script instances that run in different threads of a single process can reuse this cache to get session information.
It includes the following function that sets the value of a cache setting:
set(name, value)
where:
name is a string that identifies the setting name
value is a string that identifies the setting value
It includes the following function that gets the value of a cache setting:
get(name)
where:
name is a string that identifies the setting name
For example:
The following code stores a value that CRM Desktop SSO gets in another instance of the SSO script:
settings_cache.set("MyKey", "MyValue");
The following code gets the stored value. If no value exists, then this code returns an empty string:
var v = settings_cache.get("MyKey");
Settings Object
The settings object is a global object that is available anywhere in the main script file. It gets the value of a key that Siebel CRM Desktop SSO maps from the product key in the Windows Registry. It uses the following format:
get(name)
where:
name is a string that identifies the name of a registry key
Request Object
The request object represents the initial HTTP request that the connector sends to the SSO script. You can also use it to allow the SSO script to create an instance of a request object that establishes an SSO session for the connector, as necessary. It includes the following functions:
get_headers. Gets the object that represents the HTTP request header. For more information, see Header Object.
get_server. Gets the host part of the request URL. For example,
http://example.com/.get_object. Gets the path part of the request URL. For example,
path/page.asp.get_method. Gets the HTTP method. For example, GET, POST, and so forth.
get_contents. Gets the content object that contains the request body and that Siebel CRM Desktop SSO can use to get the request in plain text. For more information, see Content Object.
get_credentials. Gets the credentials object that contains the security credentials for the HTTP request. These credentials include the login name, password, and other authentication information. For more information, see Credentials Object.
Response Object
The response object contains the HTTP response that Siebel CRM Desktop SSO gets from the Siebel Server. It includes the properties that Siebel CRM Desktop SSO requires to retrieve the response status, headers, and the body. It includes the following functions:
get_status_code. Gets the HTTP status code for the current response.
get_headers. Gets the header object that contains the HTTP headers for the response. For more information, see Header Object.
get_contents. Gets the content object that contains the response body and that Siebel CRM Desktop SSO can use to get the response in plain text. For more information, see Content Object.
Content Object
The content object gets the string content of a request or a response. It includes the following function that gets the text content of a request or response:
get_text(encoding)
where:
encoding is a string that identifies how the body of the request or response is encoded. It can include one of the following strings:
iso-8859-1
utf-8
utf-16
For example:
get_text(iso-8859-1)
It includes the following function that sets the text content of a request or response:
set_text(text, encoding)
where:
text is the text of the body of the request or response.
encoding is a string that identifies how Siebel CRM Desktop SSO must encode the body of the request or response. It can include one of the following strings:
iso-8859-1
utf-8
utf-16
For example:
set_text("My text string", "iso-8859-1");
You must enclose each string in JavaScript quotes, so the following code returns the body of the request converted from utf-8:
var body = req.get_contents().get_text("utf-8");
CRM Desktop SSO does not allow you to modify the text of the initial request that comes as a parameter of the request_handler function. For more information, see Request Handler Function.
For more information, see Request Object and Response Object.
Header Object
The header object includes the HTTP headers of a request or response. It is read-only for a response and writable for a request. It includes the following functions:
get_header_count. Gets the number of headers that the request or response contains.
get_string_value. Gets all headers as a single string.
Get Header Name Function
The get_header_name function gets the name of a header. It uses the following format:
get_header_name(index)
where:
index is a numeric value that identifies the header index. This index starts with 0 as the first value. To access the first header, you use an index value of 0. To access the second header, you use an index value of 1, and so forth.
For example, the following code gets the name of the first header:
var header = req.get_headers().get_header_name(0);
Get Header Value Function
The get_header_value function gets the value of a header. It uses the following format:
get_header_value(index)
where:
index is a numeric value that identifies the header index. This index starts with 0 as the first value. To access the first header, you use an index value of 0. To access the second header, you use an index value of 1, and so forth.
For example, the following code gets the value of the first header:
var header_val = req.get_headers().get_header_value(0);.
Add Header Function
The add_header function adds a new header. You can use it only for a request. You cannot use it for a reply. It uses the following format:
add_header(name, value)
where:
name is a string that contains the header name.
value is a string that contains the header value.
For example, the following code adds the content type for the request:
req.get_headers().add_header("Content-Type", "text/html");
For more information, see Request Object and Response Object.
Credentials Object
The credentials object is a subobject of a request object that specifies the HTTP authorization parameters that Siebel CRM Desktop SSO uses. It includes the following functions:
get_username. Gets the user name associated with a request.
get_password. Gets the password associated with a request.
get_auth_schemes. Gets the list of authorization schemes that this request supports, in order of preference. For a list of schemes, see Set Authorization Schemes Function.
Set User Name Function
The set_username function sets the user name for a request. It uses the following format:
set_username(username)
where:
username is a string that contains the user name.
Set Password Function
The set_password function sets the password for a request. It uses the following format:
set_password(password)
where:
password is a string that contains the password.
Set Authorization Schemes Function
The set_auth_schemes function sets the authorization schemes that Siebel CRM Desktop SSO uses with a request. It uses the following format:
set_auth_schemes(auth_schemes)
where:
auth_schemes is a string that contains the authorization schemes. It can contain any combination of the following values:
B, b. Specifies to use basic authorization.
N, n. Specifies to use NTLM (NT LAN Manager) authorization.
P, p. Specifies to use passport authorization.
D, d. Specifies to use digest authorization.
You must use the following format:
The order that you use is important. For example, if you specify NB, then this request only supports NTLM or basic authentication and it uses NTLM first, if possible.
JavaScript requires that you use double quotes to enclose each string.
Values are not case-sensitive.
For example, the following code configures the HTTP client to use NTLM basic authentication if the direct request fails, where NTLM authentication takes priority over basic authentication:
req.get_credentials().set_auth_schemes("nb");
For information about basic authorization and passport authorization, see the topic about HTTP authentication schemes at the Microsoft Developer Network web site.
Interactive State Object
The interactive state object contains information about the state of the interactive authentication. The create_ia_state function of the sso_client object creates the interactive state object so that the interactive function of the sso_client object can use it when it calls the SSO script. CRM Desktop SSO uses the same interactive state object to do a callback from the code that handles the interactive authentication to the SSO script. For an example that uses a callback, see Interactive Function.
The ia_state object includes the following properties:
url. A string that identifies the URL of the page that Internet Explorer displays when Siebel CRM SSO runs the following function:
interactive()
CRM Desktop SSO provides the current URL that the Web browser object processes. It does this during the callback. CRM Desktop SSO uses ia_state later as a callback to JavaScript, and the URL contains the current URL of the page that the browser control processes. For an example of this usage, see Example Code That Customizes CRM Desktop SSO.
cookies. A string A string that identifies the cookies that are associated with the HTML page that CRM Desktop SSO loads into the control Internet Explorer.
headers. A string that identifies any other HTTP headers that the Browser sends.
post_data. A string that identifies the data that CRM Desktop SSO sends through an HTTP POST function to the Siebel Server. This property exists on form submission. CRM Desktop SSO uses HTML forms to get user information on the Web page and to send this information to the Siebel Server for processing. For example, to get the login name and password that the user enters during login.
html_body. A string that identifies the HTML body of the document that Siebel CRM Desktop loads in Internet Explorer.
status. A string that indicates the type of callback that the interactive authentication handler uses. It can include one of the following values:
before. CRM Desktop SSO sends the callback before it navigates the Web browser to a URL.
finished. CRM Desktop SSO sends the callback after the page download finishes.
cancelled. CRM Desktop SSO sends the callback if the user cancels the login and closes the dialog box.
JavaScript requires that you enclose each string in double quotes.
title. A string that contains the title of the dialog box. CRM Desktop SSO displays this title in the dialog box during interactive authentication. The default configuration that the SSO Connector uses adds the following prefix to any page title that the Siebel Server renders:
SSO:
dialog. A string that identifies the dialog object. For more information, see Dialog Object.
Dialog Object
The dialog object is a subobject of the ia_state object. It defines the size, position, visibility, and title of the SSO login dialog box that CRM Desktop SSO displays during interactive authentication. It includes the following properties:
width. A number that determines the width of the dialog box, in pixels.
height. A number that determines the height of the dialog box, in pixels.
visible. A Boolean value. If True, then CRM Desktop SSO displays the dialog box.
title. A string that contains the title of the dialog box. CRM Desktop SSO displays this title in the dialog box during interactive authentication.
Example Code That Customizes CRM Desktop SSO
The following code comes predefined with Siebel CRM Desktop:
include("utils.js", "_utils");
include("core.js", "_core");
_utils.logger = logger;
_utils.sso_client = sso_client;
_core.sso_client = sso_client;
_core.settings_cache = settings_cache;
var Utils = _utils.Utils;
var Lib = _core.Lib;
var CookieManager = new Lib.CookieManager();
var SSOConfiguration = {
"CookieBuffer": "DomainCookies",
"AuthType": settings.get("AuthType"),
"EndpointRegExp": settings.get("EndpointRegExp"),
"SuccessLoginRegExp": settings.get("SuccessLoginRegExp")
};
var interactive_params = {
"InitialWidth": 1024,
"InitialHeight": 768,
"InitialTitle": "SSO",
"InitialTitlePrefix": "SSO",
"CheckFn": InteractiveCheckFunction
};
var persistent_cookies = true;
sso_client.request_handler = process_request;
function InteractiveCheckFunction (ia_state, ia_result, original_request) {
var path = (original_request.get_object()).replace(/\//i,"").split("?");
if (SSOConfiguration.EndpointRegExp == "") {
is_original_url = ( (ia_state.url).toLowerCase()
).indexOf((original_request.get_server() + path[0]).toLowerCase() ) != -1;
} else {
is_original_url = (new RegExp(SSOConfiguration.EndpointRegExp,
'i')).test(ia_state.url)
}
if (!is_original_url && ia_state.status == "before") {
persistent_cookies = false;
}
if (ia_state.status == "finished" && ia_state.html_body != "") {
if (is_original_url) {
var regexp = SSOConfiguration.SuccessLoginRegExp == "" ? "FAULTSTRING.
*?10944629" : SSOConfiguration.SuccessLoginRegExp;
if ( ia_state.html_body.match( new RegExp(regexp,'mi') ) != null) {
return true;
}
}
}
return false;
}
function RequestData(request, clear_session) {
if (GetCache() !== "" && CookieManager.GetAllCookies().length == 0) {
Utils.SetRequestCookies(request, GetCache());
}
var response = Lib.ExecuteRequest(request, CookieManager, clear_session);
if (CookieManager.GetAllCookies().length > 0) {
UpdateCache(CookieManager.GetAllCookiesAsString());
}
return response;
}
function RedefineInteractiveDescriptor (response, redefine_location) {
return function (descriptor, ia_state) {
Utils.Log("Clear browser cookies", "info");
var cookies = Utils.ParseCookieString(ia_state.cookies);
var cookie = {};
for (var i = 0, len = cookies.length; i < len; i++) {
cookie = Utils.ParseCookie(cookies[i]);
ia_state.cookies = cookie.Name + "=;";
}
if (response !== null) {
if (redefine_location) {
descriptor.SetEndpoint(Utils.GetSpecificHeader(response.get_headers(),
"Location")[0]);
}
}
return descriptor;
}
}
function UpdateCache (value) {
Utils.Log("Update cache cookies", "info");
var cached = Utils.ParseCookies(Utils.ParseCookieString(GetCache()));
var browser = Utils.ParseCookies(Utils.ParseCookieString(value));
for (var i = 0, iLen = browser.length; i < iLen; i++) {
isset = false;
for (var j = 0, jLen = cached.length; j < jLen; j++) {
if (browser[i].Name == cached[j].Name) {
isset = true;
cached[j] = browser[i];
}
}
if(!isset) {
cached.push(browser[i]);
}
}
settings_cache.set(SSOConfiguration.CookieBuffer,CookieManager.ConvertCookiesToString(
cached));
}
function ClearCache () {
settings_cache.set(SSOConfiguration.CookieBuffer, "");
}
function GetCache() {
return settings_cache.get(SSOConfiguration.CookieBuffer);
}
function process_request(sso_client_request) {
var ignore_cache = settings.get("IgnoreCache");
var response;
if (SSOConfiguration.AuthType == "NTLM") {
var creds = sso_client_request.get_credentials();
creds.set_username('');
creds.set_password('');
creds.set_auth_schemes('n');
response = sso_client.execute_request(sso_client_request);
if (response == null) Utils.Log("No response received", "warning");
} else {
var request_x_type = Utils.GetSpecific-
Header(sso_client_request.get_headers(), "X-CRMD-TYPE");
if (request_x_type == "verify" && ignore_cache == "1") {
ClearCache();
}
response = RequestData(sso_client_request, false);
var status_code = response.get_status_code();
if (request_x_type == "logout") {
response = null;
} else if (status_code == "401" || status_code == "407") {
Utils.Throw("not_valid", "script_not_valid_sso_ntlm_attempt");
Utils.Log("Attempt to use SSO mode with NTLM-protected EAI", "info");
return null;
} else if (status_code == "302" || Utils.Transitions.IsHtml(response)) {
var redefine = status_code == "302" ? true : false;
Utils.Log("Interactive mode initialized", "info");
var result = Lib.RunInteractive(sso_client_request, interactive_params,
CookieManager, RedefineInteractiveDescriptor(response, redefine));
if (result == "success") {
if (persistent_cookies == true && ignore_cache == "1" && settings.
get("UserChanged") == "1") {
Utils.Throw("not_valid", "script_not_valid_clear_cookies");
Utils.Log("Persistent cookies exist", "info");
return null;
} else {
persistent_cookies = true;
Utils.Log("Login successful", "info");
}
} else if (result == "canceled") {
Utils.Log("Login canceled", "info");
sso_client.raise_cancel_exception("User canceled login dialog.");
return null;
}
Utils.Log("Interactive mode finished", "info");
response = RequestData(Utils.CloneRequest(sso_client,
sso_client_request, null), true);
}
}
return response;
}