All good questions, though some are somewhat beyond support available via this forum. I'll attempt to provide some answers inline below, I might suggest opening a DevNet Developer Support ticket for additional followup questions:
https://developer.cisco.com/site/devnet/support/
|
1. Please explain redirectUri in detail. According to explanation presented in the reference, what I inferred is, this url will be reached after a successful sign in. There is also a direction about parsing the token from this url, can you explain this in detail? Against what parameters this token needs to be validated? What are the consequences if I skip this step?
|
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.
|
2. 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?
|
I believe 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
3. In what scenarios credentialsRequired will be called?
I believe this 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
|
4. How to configure LDAP based authentication. Are there any extra requirements besides the settings mentioned above?
|
This is probably 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…
|
5. I have booked a CCX lab. Please provide steps to configure this through devnet CCX labs.
|
It's possible that the UCCX lab already has LDAP integration partially or completely implemented; however, complete assistance for LDAP configuration will be beyond the scope of forum support. If you need help with configuring UCM/UCCX/Jabber etc. for LDAP/SSO (fairly likely, as these are advanced configurations) I would recommend opening a ticket with DevNet Developer Support and/or acquiring a Cisco TAC support contract. Additionally, as Sandbox labs have time-limited reservations, you may want to acquire your own CUCM/UCCX lab so you have unlimited access. Some suggestions on UC lab access/acquisition here: https://developer.cisco.com/site/collaboration/labs/
|
II. Following is a snippet from sample code for discovery based login:
$('#phonecontainer').cwic('startDiscovery', {
mode: mode,
forceRegistration: forceReg,
devicesAvailable: handleDevicesAvailable,
error: handleSignInFailure,
success: handleSignInSuccess
});
1.mode: Please explain the various modes that are possible.
|
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.
|
2.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)
|
3.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
|
III. Can I continue to credential based sign-in in case discovery based sign-in fails. Can the two approaches be sequenced or are there any other alternatives?
|
I believe this will be the default behaviour: 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.
|
IV. If a system has Jabber’s window client installed and my application which has jabber’s web sdk integrated is browsed through that same machine, which interface will receive an incoming call? Are there any ways to suppress the windows client in this case?
|
See the above comments on 'forceRegistration'. It could theoretically be possible for the user to register Jabber/Win with one device name (e.g. 'CSFABC123') and then attempt to register Jabber SDK with a different device name (e.g. 'CSFDEF456'). AFAIK this scenario is not really contemplated/tested, and behaviour could be indeterminate - in probably the best case, the two 'softphones' would behave independently if they were used serially; I can't speculate on what might happen if both attempted to make/receive a call at the same time (I assume at least some error regarding audio/video contention.)
