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.
Default Setting: None before MRA is turned on. After MRA is turned on, the default is UCM/LDAP.
|
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.
OAuth is supported by Cisco Jabber and Cisco Webex clients as well as by Cisco IP Phones that onboard using device activation codes in MRA 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.
Default Setting: 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 Cisco Jabber and Cisco Webex clients can use this authorization method, which is not supported by other MRA endpoints.
Default Setting: 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.
Default Setting: 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:
-
Cluster: Generates a single clusterwide SAML metadata file. You must import only this file to IdP for the SAML agreement.
-
Peer: Generates the metadata files for each peer in a cluster. You must import each metadata file into IdP for the SAML agreement.
|
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
|
The IdP or Unified CM authentication page is displayed in an embedded web browser (not the Safari browser) on iOS devices by default. 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.
Default Setting: 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 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:
-
Yes: The get_edge_sso request will ask the user’s home Unified CM if OAuth tokens are supported. The home Unified CM is determined from the identity sent by the Jabber client's get_edge_sso request.
-
No: If the Expressway is configured not to look internally, the same response will be sent to all clients, depending on the
Edge authentication settings.
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.
Default Setting: 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.
Default Setting: 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.
Default Setting: 0 seconds
|
WebEx Client Embedded Browser Support
|
Applies to Jabber and WebEx clients that send a SSO redirect URI.
Default value: No. Set the value to Yes to enable this option.
This feature enhances the security of Jabber and Webex Client Embedded Browser support. It allows the client to use the Embedded
browser for Unified Communications Manager (and MRA) OAuth flow and improves the user experience.
|