cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1306
Views
7
Helpful
14
Replies

Webex app with MRA and CUCM v12.5

tato386
Level 6
Level 6

We are currently running the latest Jabber on Windows, Android and Apple via MRA and CUCM v12.5.  Is it possible (and how much work is needed) to introduce Webex app to our current environment?  This would be for simple calling only.  We currently don't use or need conferencing, video or messaging features.

TIA,

Diego

1 Accepted Solution

Accepted Solutions

Microsoft is on the same cloud-or-bust war path as every other vendor. If you do not already have ADFS deployed I suggest looking at Azure AD’s SAML SSO capabilities instead - or one of their competitors such as Okta. SSO IdPs are a very attractive target for an attacker, similar to a Domain Controller but inherently internet-facing. You’re better off letting someone else be responsible for keeping it secure, IMO.

You’ll get the best user experience when everything - Webex & CUCM/CUC/Expressway - all use the same SAML SSO IdP. Once the user authenticates once, and thus has a valid SAML cookie, other things should login on the user’s machine without prompting them for creds. This is relevant to the Webex app with UCM Calling because the authentication process happens several times: the Webex app itself initially and then CUCM/CUC/Expressway. If you do not use SSO the user must enter their credentials in the Webex app Preferences > Phone Services section. And then update them each time their password changes.

You may want to watch the Cisco Live session recording from Authentication, Authorization and Provisioning for Cisco Collaboration – BRKCOL-2007 for more detail on the topic.

View solution in original post

14 Replies 14

Jonathan Schulenberg
Hall of Fame
Hall of Fame

If Jabber and MRA are implemented correctly it’s pretty easy; the Webex app reuses the exact same architecture to support UCM Calling. One thing it won’t do is prompt the user to manually accept a TLS certificate that is not trusted by the client OS (a good thing, IMO). Also, for the most part (there are a couple exceptions) it does not consume the Jabber-config.xml parameters. SAML SSO is recommended - especially having the same IdP for Webex and the CUCM/CUC/Expressway stack; OAuth is strongly recommended; ICE Media Path Optimization is a nice-to-have with internal calls if users are working from home.

Deployment guide for Calling in Webex App (Unified CM) 

Does that mean that Webex can't use CUCM user accounts?  Will I have to setup cloud accounts or anything off-prem for it to work?

The Webex app depends on the cloud backend that you, as a customer admin, see as Webex Control Hub. When configured for UCM Calling it also ties into the CUCM/CUC End User, of course. When a user is set for UCM Calling in Control Hub the Webex app uses the same Service Discovery process that Jabber does for the calling workload. The difference is that it happens after the app has already authenticated to the cloud and learned of the user’s config. You can disable the meeting and messaging workloads for a given user if you want the app to be calling only, although Cisco has a free 40-minute meeting offer you can give all users.

Entitlement to have users in Control Hub should be included in every annuity subscription with on-premises calling, either named user or employee count/enterprise agreement.

On a partially-related topic, you should look at Cloud Connected UC to add capabilities to your CUCM/CUC clusters. WebRTMT is a nice alternative to the Java client, for example. As is the ability to support automated softphone device provisioning for only the device types users actually have (eg iPhone or Android - not both). It allows desk phone control in the Webex app while MRA-connected. The list goes on…

Good stuff.  One last question.  The docs always show an IdP server integrated with CUCM and WCH.  Is this mandatory or can CUCM integrate directly with WCH?  If I need to implement an IdP server I have AD available, but the docs say MS Federation services is needed?  Is that correct?  

The CM does not integrate with Control Hub, nor is that what an IdP does. The IdP is there to provide authentication services, often known by SSO. AD is not an IdP, but MS has a product named ADFS that is.



Response Signature


Microsoft is on the same cloud-or-bust war path as every other vendor. If you do not already have ADFS deployed I suggest looking at Azure AD’s SAML SSO capabilities instead - or one of their competitors such as Okta. SSO IdPs are a very attractive target for an attacker, similar to a Domain Controller but inherently internet-facing. You’re better off letting someone else be responsible for keeping it secure, IMO.

You’ll get the best user experience when everything - Webex & CUCM/CUC/Expressway - all use the same SAML SSO IdP. Once the user authenticates once, and thus has a valid SAML cookie, other things should login on the user’s machine without prompting them for creds. This is relevant to the Webex app with UCM Calling because the authentication process happens several times: the Webex app itself initially and then CUCM/CUC/Expressway. If you do not use SSO the user must enter their credentials in the Webex app Preferences > Phone Services section. And then update them each time their password changes.

You may want to watch the Cisco Live session recording from Authentication, Authorization and Provisioning for Cisco Collaboration – BRKCOL-2007 for more detail on the topic.

I already have our AD syncing to Azure so I guess I will take your advice by watching the Cisco live session and get going with SSO for my UC setup!

Thank you.

Sorry, I guess I lied when I said, "one last question".    In my scenario I already have on-prem DCs syncing with Azure and my on-prem CUCM will use on-prem AD for IdP.  So when it comes to Control Hub it would seem I have two options.  I can use SCIM and use Azure IdP or I can use AD Connector and use on-prem DCs for IdP.  Is that correct?  I believe that AD Connector has slightly more functionality than SCIM (AD group sync?) but I don't think I will use or need them.  So if I assume both will provide all the functionality I need, should I use SCIM/Azure or AD Connector/AD?  Does it matter?

Thanks,

Diego

 

 

SCIM, the newer Azure AD wizard (Graph API), and the Directory Connector are only account sync. They are not involved in the user authentication flow.

The Azure AD wizard is capable of also configuring SAML SSO using Azure AD as the IdP, but that’s just for convenience; it’s still a separate config and protocol.

As for which to use: it depends what your AD strategy is. If the plan is to migrate off of on-prem AD to Azure AD then it seems short-sighted to use the Directory Connector.

You bring up a good point about SAML SSO.  We do not have plans to migrate off of on-prem AD anytime soon and we are content with our "hybrid" on-prem/Azure AD for now.  But we definitely want to do SSO so if using SCIM makes SSO easier and doesn't limit any features that we are interested in, then SCIM is probably the way to go.  

SCIM has nothing to do with SAML; seperare config. The Azure AD Wizard, which mostly uses the Graph API instead of SCIM, is capable of also setting up SAML.

Sorry, getting all my acronyms mixed up!  So is it correct to say that if I use the Azure AD Wiz it will setup both IdP (via graph API) and SAML?

Yes. The Azure AD Wizard uses the Graph API to synchronize user accounts, and optionally groups as well as user avatar photos (not available via SCIM) into Webex Common Identity. Step 10 of the Set up Azure AD Wizard App in Control Hub enablement process mentions that you can also opt to configure SAML SSO using Azure AD as your IdP.

And before it trips you up: the Users and Groups tabs are filter criteria of what you want to sync in. IMO the GUI is not self-evident on that front. If you want to sync specific users, select them. If you want to sync all users that are a member of a dynamic group, select that group.

thank you!