Configure MRA Access Control
Define how clients must authenticate for Mobile and Remote Access (MRA) requests.
Caution |
If you are upgrading from X8.9 or earlier, the settings applied after the upgrade are not the same as listed here. R refer instead to the upgrade instructions in the Expressway Release Notes. |
Procedure
On the Expressway-C, go to . |
Authorization and Authentication Comparison
We use the concepts "authorization" and "authentication" in documentation and the user interface. At a high level, these terms can be explained using a hotel analogy:
-
Authentication: Equates to hotel registration by a visitor. Defines the initial check-in process to allow you access into the hotel, where you prove who you are by presenting credentials like a passport or driving license.
-
Authorization: Equates to a hotel key card given to a visitor. Controls the specific hotel room and other services that you are allowed to use during your stay.
The fields you actually see in the Web UI depend on whether MRA is enabled (Unified Communications mode set to Mobile and remote access) and on the selected authentication path. Not all the fields in the table are necessarily displayed.
Expressway (Expressway-C) Settings for Access Control
Field |
Description |
Default |
---|---|---|
Authentication path |
Hidden field until MRA is enabled. Defines how MRA authentication is controlled. SAML SSO authentication: Clients are authenticated by an external IdP. UCM/LDAP basic authentication: Clients are authenticated locally by the Unified CM against their LDAP credentials. SAML SSO and UCM/LDAP: Allows either method. None: No authentication is applied. The default until MRA is first enabled. The "None" option is required (rather than just leaving MRA turned off) because some deployments must turn on MRA to allow functions which are not actually MRA. (Such as the Web Proxy for Meeting Server, or XMPP Federation.) Only these customers should use "None". It is not recommended in other cases. |
None before MRA turned on UCM/LDAP after MRA turned on |
Authorize by OAuth token with refresh |
This option requires self-describing tokens for authorization. It's our recommended authorization option for all deployments that have the infrastructure to support them. Only Jabber clients are currently capable of using this authorization method. Other MRA endpoints do not currently support it. The clients must also be in OAuth token with refresh authorization mode. Important: From X8.10.1, the Expressway fully supports the benefits of self-describing tokens (including token refresh, fast authorization, and access policy support). However, not all of the benefits are actually available throughout the wider solution. Depending on what other products you use (Unified CM, IM and Presence Service, Cisco Unity Connection) and what versions they are on, not all products fully support all benefits of self-describing tokens. If you use this option on Expressway, you must also enable OAuth with refresh on the Unified CMs, and on Cisco Unity Connection if used. The process is summarized below. |
On |
Authorize by OAuth token (previously SSO Mode) |
Available if Authentication path is SAML SSO or SAML SSO and UCM/LDAP. This option requires authentication through the IdP. Currently, only Jabber clients are capable of using this authorization method, which is not supported by other MRA endpoints. |
Off |
Authorize by user credential |
Available if Authentication path is UCM/LDAP or SAML SSO and UCM/LDAP. Clients attempting to perform authentication by user credentials are allowed through MRA. This includes Jabber, and supported IP phone and TelePresence devices. |
Off |
Identity providers: Create or modify IdPs |
Available if Authentication path is SAML SSO or SAML SSO and UCM/LDAP. For more information, see Identity Provider Selection. |
— |
SAML Metadata |
Available if Authentication path is SAML SSO or SAML SSO and UCM/LDAP. Determines how to generate the metadata file for the SAML agreement. The possible modes are:
|
|
Identity providers: Export SAML data |
Available if Authentication path is SAML SSO or SAML SSO and UCM/LDAP. For details about working with SAML data, see SAML SSO Authentication Over the Edge. |
— |
Allow Jabber iOS clients to use embedded Safari |
By default the IdP or Unified CM authentication page is displayed in an embedded web browser (not the Safari browser) on iOS devices. That default browser is unable to access the iOS trust store, and so cannot use any certificates deployed to the devices. This setting optionally allows Jabber on iOS devices to use the native Safari browser. Because the Safari browser is able to access the device trust store, you can now enable password-less authentication or two-factor authentication in your OAuth deployment. A potential security issue exists for this option. The mechanism to return browser control from Safari to Jabber after the authentication completes, uses a custom URL scheme that invokes a custom protocol handler. It's possible that another application other than Jabber could intercept the scheme and gain control from iOS. In that case, the application would have access to the OAuth token in the URL. If you are confident that your iOS devices will not have other applications that register the Jabber custom URL scheme, for example because all mobile devices are managed, then it's safe to enable the option. If you are concerned about the possibility of another app intercepting the custom Jabber URL, then do not enable the embedded Safari browser. |
No |
Check for internal authentication availability |
Available if Authorize by OAuth token with refresh or Authorize by OAuth token is enabled. The default is No, for optimal security and to reduce network traffic. Controls how the Expressway-E reacts to remote client authentication requests by selecting whether or not the Expressway-C should check the home nodes. The request asks whether the client may try to authenticate the user by OAuth token, and includes a user identity with which the Expressway-C can find the user's home cluster:
The option to choose depends on your implementation and security policy. If all Unified CM nodes support OAuth tokens, you can reduce response time and overall network traffic by selecting No. Or select Yes if you want clients to use either mode of getting the edge configuration—during rollout or because you can't guarantee OAuth on all nodes. Caution: Setting this to Yes has the potential to allow rogue inbound requests from unauthenticated remote clients. If you specify No for this setting, the Expressway prevents rogue requests. |
No |
Allow activation code onboarding |
Only available if Authorize by OAuth token with refresh or Authorize by OAuth token is enabled. This setting enables onboarding by activation code in the Expressway. The default value is No. Set the value to Yes to enable this option. |
No |
SIP token extra time to live |
Available if Authorize by OAuth token is On. Optionally extends the time-to-live for simple OAuth tokens (in seconds). Gives users a short window to accept calls after their credentials expire. However, it increases the potential security exposure. |
0 seconds |
Configure Cisco Unified Communications Manager for OAuth with Refresh
To use self-describing tokens on Expressway (Authorize by OAuth token with refresh), you must also enable OAuth with refresh on Unified CM, and on Unity Connection if you use it. The settings are summarized here for convenience. For details, refer to the Cisco Unified Communications Manager or Cisco Unity Connection documentation.
Procedure
Do one of the following actions.
|
Check Unified CM Support
You can check what authorization methods your Unified CM servers support. This displays the version numbers in use.
Procedure
On the Expressway, select . |
Configure OAuth with Refresh (Self-Describing) on Unified CM SIP Lines
From version X12.5, OAuth is supported on the Unified CM SIP line interface for Jabber clients only. When OAuth is enabled on the Unified CM SIP line and Jabber client, on-premises clients are authorized using self-describing tokens instead of client certificates.
Support for OAuth on the Unified CM SIP line from X12.5 means that secure SIP and SRTP is possible without Certificate Authority Proxy Function (CAPF). It enables end-to-end encryption of ICE and ICE passthrough calls over MRA.
Procedure
Step 1 |
On Unified CM node, do the following: The settings to enable SIP OAuth on the SIP line on Unified CM are summarized here for convenience. For detailed information, see the Cisco Unified Communications Manager documentation. |
Step 2 |
After you enable Unified CM for SIP OAuth, discover or refresh the Unified CM nodes in Expressway-C. A new CEOAuth (TLS) zone is created automatically in Expressway-C. For example, CEOAuth <Unified CM name>. A search rule is created to proxy the requests originating from the on-premises endpoints towards the Unified CM node. This zone uses TLS connections irrespective of whether Unified CM is configured with mixed mode. To establish trust, Expressway-C also sends the hostname and Subject Alternative Name (SAN) details to the Unified CM cluster |
Step 3 |
Upgrade the Jabber clients to 12.5. Cisco Jabber 12.5 or later is required for either MRA or on-premises clients to connect using OAuth. |
Step 4 |
Enable OAuth authorization on the Phone Security Profile (Jabber clients. ) and apply the Phone Security Profile on the |
Refresh Servers on the Expressway-C
You must refresh the Cisco Unified Communications Manager and Cisco Unity Connection nodes defined on the Expressway-C. This fetches keys that the Expressway needs to decrypt the tokens.
Procedure
Step 1 |
For Unified CM, go to and click Refresh servers. |
Step 2 |
For Unity Connection, go to Refresh servers. and click |