Siebel CRM Desktop for IBM Notes Administration Guide > Customizing Authentication > Overview of Customizing Authentication >

Types of Authentication That You Can Use With CRM Desktop SSO

This topic describes the types of authentication that you can use with CRM Desktop SSO.

Interactive Authentication

Interactive authentication is a type of authentication in CRM Desktop SSO that displays a second login dialog box that is native to the client. It displays this native dialog box in the following situations:

• ÅAfter the user sets values in the CRM Desktop - Login dialog box and then clicks Login.
• ÅThe first time CRM Desktop logs in to the Siebel Server after Outlook restarts.
• ÅA previously obtained SSO session expires.

Siebel CRM supports interactive authentication beginning with Siebel CRM Desktop version .

If you enable CRM Desktop SSO, then it uses interactive authentication by default. It is the only SSO authentication that comes predefined with CRM Desktop.

Interactive authentication includes the following functionality:

• Detect session expiration. If a CRM Desktop SSO session expires, then CRM Desktop SSO prompts the user to provide credentials and then reestablishes the session.
• Multifactor authentication. Supports more than only the login name and password from the the dialog box that is native to the browser, such as requiring code from a security token in addition to the password. The CRM Desktop SSO login dialog box can include more fields, images, a list of questions that the user must answer, ActiveX controls, and other items that your implementation requires for authentication. It can support an input field for an RSA (Rivest Shamir Adleman) token or other information that only the user can provide.
• Supports Internet Explorer. The CRM Desktop SSO log-in dialog box is an Internet Explorer ActiveX dialog box.

Interactive authentication provides the following benefits:

• Allows CRM Desktop SSO to support a more complex SSO login
• Allows you to use script to customize an SSO login on the client that supports a nonstandard configuration.
• Interactive SSO provides the following challenges:
• Cannot store credentials in the product configuration that CRM Desktop SSO can use later. This situation might require the user to reenter credentials during the first and subsequent SSO session logins.
• Supports only Internet Explorer version 7 or later.

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. 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 is similar to the dialog box that Figure 16 on page 346 displays. 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 CRM Desktop.
  • Do not include a check mark. CRM Desktop SSO prompts the user for credentials the next time the user starts CRM Desktop and after the first SSO session starts. This behavior typically occurs during the first synchronization that occurs after the user restarts 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 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.