• 5.19 • 5.3 • 5.8

Design

The Identity Provider API works with the Identity Provider component, which is designed to do the following:

• Maintain active user sessions (see below)
• Authenticate new logins and creates new sessions
• Determine privileges to run a particular application type (but does not determine privileges within the application)
• Perform checks and enforce limits on attempted login rate, account lockouts, IP address ranges, and concurrent user logins per tenant

For more information on this component, see the Deployment Guide, section Server-Side Components.

Sessions

A session is defined as a “authenticated state” of the user and is uniquely identified by a session token (cookie). It is separate from the “logged in” state for an agent. An agent can login and logout several times by closing and reopening the browser tab with the Agent Desktop application and remain within one authentication session.

Multiple sessions for the same user are enforced by each application server separately for each application type:

• For Agent Desktop, only one logged in state (and therefore, one session) is allowed. Otherwise, two browsers with two valid sessions will fight for one agent login.

• For wallboards, only one session is allowed. Otherwise, it is hard to find out who is using up all concurrent logins per tenant and extra sessions would be creating unnecessary server load.

• For Contact Center Administrator, more than one session is allowed.

HTTP

The API is provided via HTTP to simplify integration from web servers and app servers.

< Previous | Next >