Jabber Voice/Video SDK Discovery Based Sign-In

A redirect URI is a component of the OAuth2/SAML authentication flow that Jabber supports for SSO - a complete understanding of what it's for and how it works will require a fairly thorough understanding of OAuth2: RFC 6749 - The OAuth 2.0 Authorization Framework

In essence, however, once the SSO 'flow' is launched by the user via the browser-based Jabber SDK app, the user's browser window will be redirected to a number of different network components, including the Identity Provider, CUCM, and the application, where the user will be provided with a web based form to login and be validated.  At the end of this (successful) process, the user's browser window is finally redirected to the administratively configured 'redirect URI' with the SSO authentication token included in the fragment/'hash' portion of the URL: Fragment identifier - Wikipedia, the free encyclopedia

In the sample code project in the Jabber SDK, the redirect URI is given as http://localhost:8000/samples/ssopopup.html and a corresponding sample ssopopup.html page is in the JS directory of the sample.  This page will need to be served by your web application appropriately, and the redirect URI in the jabber settings adjusted to match.  Note from the code in ssopopup.html, that when the browser is redirected to this page, some JavaScript on the page immediately execute to send the URL hash and token back to the Jabber plugin's cwic function _cwic_onSSOTokenReceived:

<script>

 

    var hash = document.location.hash;

    var token = hash.split('&')[0].split('=')[1];

    var parentProp = window.opener.testData;

    var url = document.location.href;

    

    window.opener._cwic_onSSOTokenReceived({hash:hash, token:token, data:parentProp, url: url});

    window.close();

    

</script>

More details about how SSO works with CUCM (including configuring the redirect URI in UCM admin) can be found here: Cisco DevNet: SSO

Assuming the ssopupup.html page is used by your web app as-is, or re-uses the code fragment above, then the code and Jabber plugin will handle the parsing and subsequent usage of the SSO access token to perform its internal operations.  I assume if all this is not implemented properly, the SSO login will not work, and the Jabber plugin will be unable to login the user.

On first login, emailRequired method is required to set the Email ID of the user. Which Email ID is expected here? Is this a registered Email ID with CUCM? If yes, are these Emails the only ones that will be allowed signIn and not all the AD users?

This email address is parsed to 1) identify the domain of the user, and therefore lookup the DNS SRV entry which allows the client to 'discover' the location of the user authentication service (whether UDS or CUP/IM&P) on CUCM.  More here: Cisco Jabber DNS Configuration Guide - Cisco 2) Find out if the user ID portion is one of the users managed by the authentication service.

Typically this 'email address' is the CUCM user ID and CUCM domain, or the AD user ID linked to CUCM.  I am not certain if this is limited to user IDs actually configured on CUCM or whether it just checks the LDAP store (a question for Cisco TAC).  More info here: http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/install/10_0_1/ipchange/CUCM_BK_C3782AAB_00_change-ipaddress-hostname-100/CUCM_BK_C3782AAB_00_change-ipaddress-hostname-100_chapter_0100.html

The callback will occur if the SSO service discovery detects that SSO is not active, and user authentication should be conducted by prompting the user for his username/password, i.e. via the web application's UI

LDAP integration with SSO is a somewhat involved topic, this doc may be a good starting point, with Cisco TAC being available for detailed Q&A and assistance: Cisco Collaboration System 10.x Solution Reference Network Designs (SRND) - Directory Integration and Identity Managemen…

Following is a snippet from sample code for discovery based login:

$('#phonecontainer').cwic('startDiscovery', {
      mode: mode,
      forceRegistration: forceReg,
      devicesAvailable: handleDevicesAvailable,
      error: handleSignInFailure,
      success: handleSignInSuccess
});

mode: From the Jabber SDK documentation available in the SDK at .../JabberSDK-voice-video-Web11.0_MR1/docs/api/symbols/%24.fn.cwic.html#-startDiscovery

{String}args.modeOptionalRegister the phone in this mode. Available modes are "SoftPhone" or "DeskPhone". Default of intelligent guess is applied after a device is selected.

This setting indicates whether the Jabber SDK will be attempting to control a separate phone endpoint (e.g. a Cisco deskphone) in 'remote control' (3rd party call control) mode, or instantiate the device itself as in softphone (1st party call control) mode.

forceRegistration: In what scenarios force registration will be required?

This setting controls what happens if the Jabber plugin attempts to register a device that is already registered.  For example if a user already has a Jabber for Windows client (or another instance of Jabber SDK) running registered as 'DeviceABC', then if 'forceRegistration'=True the current instance will be registered and the previous instance will be forcefully un-registered.  If False, then the current instance registration will fail (I believe with an error indicating that the device is already registered)

devicesAvailable: Is this in context of CUCM or the audio video devices of the system?

This will be a list of CUCM phone devices that the user is able to monitor/control (deskphone) or instantiate (CSF device as softphone).  Not related to PC/OS audio/video devices.

If service discovery determines that discovery/SSO is not configured, then it will be assumed that credential-based login is active and the appropriate events (e.g. credentialsRequired) will be fired.