In order to connect to the Interaction Center server using IceLib, authentication must be provided. IceLib supports several types of authentication which are described below. Additionally, the sections below also describe some Interaction Center server settings that affect which authentication methods are available for use via IceLib connections.
See the Connecting to the Server "Getting Started" page for an examples of authentication.
This topic contains the following sections.
- Allowed Authentications
- Basic Authentication
- Interaction Center Based Authentication
- Windows Based Authentication
- Manual Windows Based Authentication
- Proxy Authentication
- Interaction Center Based Proxy Authentication
- Windows Based Proxy Authentication
- Alternate Windows Based Proxy Authentication
- Single Sign-On
- See Also
Allowed Authentications
Interaction Center provides configuration options in Interaction Administrator to control what types of authentication can be used when connecting. The configuration options are provided to limit the options provided to end users to meet security requirements or to prevent users from accidentially using options that will not work with the configuration of the Interaction Center server.
The GetAllowableAuthentications(HostSettings, String) method allows retrieval of the supported authentication modes. The isoLanguage parameter specifies the language in which the Single Sign-On (SSO) provider's display name information should be returned, if any SSO provider is specified.
These supported authentication modes are configured in Interaction Administrator in the System Configuration dialog on the Connection Security tab, by selecting the Configure logon authentication. On the Logon Authentication Configuration dialog, the Authentication Method section has options for which types of authentication will be allowed. When establishing an IceLib connection, the server enforces these settings.
Applications must only use the options enabled or the connection will be denied by the server. The method describe above is useful for applications to query the server for what application methods are allowed. This can be done before prompting the user for credentials to ensure they are only presented with options that are enabled.
Basic Authentication
There are three main types of basic authentication with IceLib: Interaction Center (IC) based authentication, current Windows session based authentication, and explicit Windows credentials based authentication. These are described in detail below.
Interaction Center Based Authentication
Basic authentication can be based on Interaction Center credentials. Interaction Center supports the configuration of passwords directly on user objects in Interaction Administrator. The password configured on a user is subject to the password policy, if any, that is configured for that user. This password can be changed through Interaction Administrator (on the user object via the Password setting), or by the end-user via ININ applications such as the Interaction Client or Interaction Center Business Manager (ICBM).
The use of this authentication type requires the Logon Authentication Configuration dialog in Interaction Administrator to have the Allow IC authentication setting enabled.
In IceLib, this type of authentication is supported via the ICAuthSettings class. It requires the Interaction Center credentials of the user.
Windows Based Authentication
Basic authentication can be based on the credentials of the Windows session under which the IceLib connection is being established. For this to work, an association of the Windows account must be made with the Interaction Center user in Interaction Administrator on the user object via the NT Domain User setting.
The use of this authentication type requires the Logon Authentication Configuration dialog in Interaction Administrator to have the Allow Windows authentication setting enabled.
In IceLib, this type of authentication is supported via the WindowsAuthSettings class. It automatically uses the Windows credentials of the current Windows session.
Manual Windows Based Authentication
Basic authentication can be based on explicit credentials of a Windows session, either the same or different than the one under which the IceLib connection is being established. In this case, the actual Windows domain/user and password will be provided to the login process. For this to work, an association of the Windows account must be made with the Interaction Center user in Interaction Administrator on the user object via the NT Domain User setting.
The use of this authentication type requires the Logon Authentication Configuration dialog in Interaction Administrator to have the Allow manual entry of Windows authentication credentials setting enabled.
In IceLib, this type of authentication is supported via the AlternateWindowsAuthSettings class. It requires the explicit Windows credentials of the user (e.g. domain/user and password).
Proxy Authentication
For certain server-side application integrations, it can be necessary to establish IceLib sessions on behalf of end-users. For instance, a server-side IceLib-based service that must integrate with 3rd-party software by creating an IceLib session for each agent in order to perform its work.
In this case, the server-side application does not have access to the end-user's Interaction Center or Windows credentials with which to establish a connection for them. IceLib provides a solution to this problem by allowing configuration of an "elevated rights" user that has the right to serve as a proxy for the authentication of other Interaction Center users. The "elevated rights" user should be created specifically for the server-side application's use, with very few rights other than the ability to proxy authentication.
The "elevated rights" user must have a specific "Proxy Logins" Access Control right configured on their Interaction Center User via the Interaction Administrator application. This setting is in the Miscellaneous section of the Access Control settings.
There are three types of proxy authentication with IceLib: Interaction Center (IC) based proxy authentication, current Windows session based proxy authentication, and alternate Windows session based proxy authentication. These are described in detail below.
Interaction Center Based Proxy Authentication
Proxy authentication can be based on Interaction Center credentials. The Interaction Center supports the configuration of passwords directly on user objects in Interaction Administrator. The password configured on a user is subject to the password policy, if any, that is configured for that user. This password can be changed through Interaction Administrator (on the user object via the Password setting), or by the end-user via ININ applications such as the Interaction Client or Interaction Center Business Manager (ICBM).
The use of this authentication type requires the Logon Authentication Configuration dialog in Interaction Administrator to have the Allow IC authentication setting enabled.
In IceLib, this type of authentication is supported via the ProxyAuthSettings class. It requires both the Interaction Center credentials of the "elevated rights" user as well as either the Interaction Center user ID or Windows domain/password for the user which to proxy authentication. If the Windows domain/password is specified for the user for which to proxy authentication, then the Interaction Center user object for that user being proxied must also have the correct NT Domain User setting.
Windows Based Proxy Authentication
Proxy authentication can be based on the credentials of the Windows session under which the IceLib connection is being established. For this to work, an association of the Windows account must be made with the Interaction Center user in Interaction Administrator on the user object via the NT Domain User setting.
The use of this authentication type requires the Logon Authentication Configuration dialog in Interaction Administrator to have the Allow Windows authentication setting enabled.
In IceLib, this type of authentication is supported via the ProxyWindowsAuthSettings class. It automatically uses the Windows credentials of the current Windows session and also requires either the Interaction Center user ID or Windows domain/password for the user which to proxy authentication. If the Windows domain/password is specified for the user for which to proxy authentication, then the Interaction Center user object for that user being proxied must also have the correct NT Domain User setting.
Alternate Windows Based Proxy Authentication
Proxy authentication can be based on the credentials of a specified Windows session under which the IceLib connection is being established. For this to work, an association of the Windows account must be made with the Interaction Center user in Interaction Administrator on the user object via the NT Domain User setting.
The use of this authentication type requires the Logon Authentication Configuration dialog in Interaction Administrator to have the Allow Windows authentication setting enabled.
In IceLib, this type of authentication is supported via the ProxyAlternateWindowsAuthSettings class. Unlike the Windows based proxy authentication that uses the current Windows session, this authentication requires a Windows user and password to be supplied. It also requires either the Interaction Center user ID or Windows domain/password for the user which to proxy authentication. Because this authentication requires a Windows user and password to be specified, special care should be taken when using this method in cases where this information is required to be persisted. If the Windows domain/password is specified for the user for which to proxy authentication, then the Interaction Center user object for that user being proxied must also have the correct NT Domain User setting.
Single Sign-On
Single Sign-On (SSO) provides the ability for Interaction Center to delegate the responsibility of authenticating users to a centralized authentication server. This setup means that users do not need separate credentials for the Interaction Center system. They only need to remember the credentials for a company's central authentication server.
Note |
---|
Active Directory Federation Services (ADFS) is an example of an Identity Provider that allows Single Sign-On. |
The use of this authentication type requires one or more configured SSO Identity Providers. The Identity Providers are configured in Interaction Administrator under Single Sign-On, Identity Providers.
In IceLib, this type of authentication is supported via the SecurityTokenServiceAuthSettings class. The list of configured Identity Providers is provided to IceLib through the GetAllowableAuthentications(HostSettings, String) method whose response contains the list of AuthProviderDefinitions. These definitions contain the display name for the Identity Provider and the AuthProviderContext instance which is required to create an instance of the setting class. The context class also provides information about what information the Identity Provider will need to authenticate.
The SecurityTokenServiceAuthParameters class has several options including properties for specifying the user name and password (the needs vary by the Identity Provider). This class also provides a place for IceLib applications to register a callback for when Identity Providers need additional information for authentication. For example, if the user name and password were not specified, but the Identity Provider expects a user name and password, the instance of SecurityTokenServicePresenter will be called to provide the credentials.
The SecurityTokenServiceAuthParameters class additionally provides PersistToken and UsePersistedToken properties. These properties control how the Single Sign-On token will be shared between IceLib applications. When PersistToken is true, the authentication token is stored on the local machine for use when the application is reopened or other IceLib applications are started. When UsePersistedToken is true, IceLib will attempt to find and use a stored token eliminating the need for the user to enter their credentials. The HasCachedToken(HostEndpoint, AuthProviderContext, String) method can be called to determine if a token exists before attempting the connection allowing IceLib applications to obtain credentials before attempting the connection. It is important to note that the tokens can expire so a token may be available but may not authenticate.
See the Connecting to the Server "Getting Started" page for an example using SSO.
Security Assertion Markup Language 2.0 (SAML 2.0)
IceLib supports the Security Assertion Markup Language 2.0 (SAML 2.0) protocol for Single Sign-On. In SAML 2.0, the central authentication server is known as the Identity Provider and trust is setup between Interaction Center and the Identity Provider by exchanging certificates. Once configured, when IceLib connects to the Interaction Center server, the server directs IceLib to first authenticate with the Identity Provider. The Identity Provider authenticates the user and provides a signed response containing claims about the user back to IceLib which forwards the response to the Interaction Center server. The server then validates the response and, using the claims defined in the response, associates the IceLib session with the correct user in the Interaction Center system.
The SAML 2.0 specification defines several methods for performing authentication. IceLib supports the HTTP Redirect and HTTP POST binding for the Web Browser SSO profile, as well as the Enhanced Client or Proxy (ECP) profile.