En este artículo
dropdown icon
Inicio de sesión único y centro de control
    Perfiles
    Formato NameID
    Sale de sesión único
Integre Control Hub con Shibboleth
Descargue los metadatos de Webex a su sistema local
Configurar autorización en archivos Shibboleth
Configurar los componentes del proveedor de servicios Shibboleth para la aserción SAML
Configurar los atributos de aserción
Importe los metadatos del IdP y habilite el inicio de sesión único después de una prueba
Configurar el inicio de sesión único en Control Hub con Shibboleth
list-menuEn este artículo
list-menu¿Comentarios?

Puede configurar una integración de inicio de sesión único (SSO) entre Control Hub y una implementación que utiliza Shibboleth como proveedor de identidad (IdP).

Inicio de sesión único y centro de control

El inicio de sesión único (SSO) es un proceso de autenticación de sesión o usuario que permite a un usuario proporcionar credenciales para acceder a una o más aplicaciones. El proceso autentica a los usuarios para todas las aplicaciones a las que se les otorgan derechos. Elimina más indicaciones cuando los usuarios cambian de aplicación durante una sesión en particular.

El protocolo de federación del lenguaje de marcado de aserción de seguridad (SAML 2.0) se utiliza para proporcionar autenticación SSO entre la nube de Webex y su proveedor de identidad (IdP).

Perfiles

La aplicación Webex solo admite el perfil SSO del navegador web. En el perfil SSO del navegador web, Webex App admite los siguientes binomios:

  • SP inició el enlace POST -> POST

  • SP inició el enlace REDIRECT -> POST

Formato NameID

El protocolo SAML 2.0 admite varios formatos de NameID para comunicarse sobre un usuario específico. La aplicación Webex admite los siguientes formatos de NameID.

  • urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

  • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

En los metadatos que carga desde su IdP, la primera entrada está configurada para su uso en Webex.

Sale de sesión único

La aplicación Webex admite el perfil de cierre de sesión único. En la aplicación Webex, un usuario puede cerrar sesión en la aplicación, que utiliza el protocolo de cierre de sesión único SAML para finalizar la sesión y confirmar ese cierre de sesión con su IdP. Asegúrese de que su IdP esté configurado para SingleLogout.

Integre Control Hub con Shibboleth

Las guías de configuración muestran un ejemplo específico para la integración de SSO, pero no proporcionan una configuración exhaustiva para todas las posibilidades. Por ejemplo, los pasos de integración nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transientestán documentados. Otros formatos, como urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddressfuncionarán para la integración de SSO, pero están fuera del alcance de nuestra documentación.

Configure esta integración para los usuarios de su organización Webex (incluida Webex App y otros servicios administrados en Control Hub). Webex Meetings Si su sitio de Webex está integrado en Control Hub, el sitio de Webex hereda la administración de usuarios. Si no puede acceder Webex Meetings de esta manera y no se administra en Control Hub, debe realizar una integración separada para Webex Meetings habilitar el SSO.

Los pasos de integración se refieren a Shibboleth 2.4.5 en CentOS 7 con Tomcat 7 como servidor web.

Antes de comenzar

Para SSO y Control Hub, los IDP deben cumplir con la especificación SAML 2.0. Además, los IDP deben configurarse de la siguiente manera:

Descargue los metadatos de Webex a su sistema local

1

Inicie sesión en Control Hub.

2

Vaya a Administración > Seguridad > Autenticación.

3

Vaya a la ficha Proveedor de identidad y haga clic en Activar SSO.

4

Seleccione un IdP.

5

Elija el tipo de certificado para su organización:

  • Autofirmado por Cisco: recomendamos esta opción. Permítanos firmar el certificado para que solo necesite renovarlo una vez cada cinco años.
  • Firmado por una autoridad de certificación pública: más seguro, pero necesitará actualizar con frecuencia los metadatos (a menos que su proveedor de IdP admita anclajes de confianza).

Los anclajes de confianza son claves públicas que actúan como una autoridad para verificar el certificado de una firma digital. Para obtener más información, consulte la documentación de su IdP.

6

Descargue el archivo de metadatos.

<org-ID>El nombre de archivo de metadatos de Webex es idb-meta- -SP.xml.

Configurar autorización en archivos Shibboleth

Después de instalar Shibboleth, se le proporcionan archivos de configuración con ejemplos.

1

Vaya al directorio /opt/shibboleth-idp/conf para acceder a los archivos de ejemplo.

2

Decida qué método de autorización usar, por ejemplo, enlace LDAP. Active Directory

3

Edite el archivo handler.xml de la siguiente manera:

Dejar de comentar

    <!--  Username/password login handler -->
    <ph:LoginHandler xsi:type="ph:UsernamePassword"
                  jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config">  
  <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</ph:AuthenticationMethod>
    </ph:LoginHandler>

Comentario

<ph:LoginHandler xsi:type="ph:RemoteUser"> 
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</ph:AuthenticationMethod>
    </ph:LoginHandler>
4

Complete sus datos Active Directory para permitir la autenticación. Proporcione la configuración al archivo login.config.

ShibUserPassAuth {
   edu.vt.middleware.ldap.jaas.LdapLoginModule required
      ldapUrl="ldap://ad0a.cisco.net:389"
      ssl="false"
      tls="false"
      baseDn="cn=Users,dc=cisco,dc=net"
      subtreeSearch="true"
      userFilter="sAMAccountName={0}"
      bindDn="cn=Administrator,cn=Users,dc=cisco,dc=net"
      bindCredential="ThePassword";
};

Configurar los componentes del proveedor de servicios Shibboleth para la aserción SAML

1

Agregue el archivo que descargó del SP de Webex al directorio /opt/shibboleth-idp/metadata.

2

Edite el archivo relying-party.xml; después de la etiqueta DefaultRelyingParty, agregue los detalles de la aserción SAML para Webex.

 <rp:RelyingParty id="https://idbroker.webex.com/ea7c1420-711d-4916-95f8-
22de53230d1e"
              provider="https://shib9a.cisco.net/idp/shibboleth"
              defaultSigningCredentialRef="IdPCredential">
            <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
                includeAttributeStatement="true"
                assertionLifetime="PT5M" assertionProxyCount="0"
                signResponses="never" signAssertions="always"
                encryptAssertions="conditional" encryptNameIds="never"
                includeConditionsNotBefore="true"/>
        </rp:RelyingParty>

Para id, debe usar el valor EntityId del archivo de metadatos de Webex. Reemplace el ID del ejemplo por el entityID de su organización.

3

Dentro de la etiqueta Metadata:MetadataProvider, agregue la ubicación del archivo:

 <metadata:MetadataProvider id="ShibbolethMetadata" xsi:type="metadata:Chaini
ngMetadataProvider">
        <metadata:MetadataProvider id="IdPMD" xsi:type="metadata:FilesystemMetad
ataProvider" metadataFile="/opt/shibboleth-idp/metadata/idp-metadata.xml" maxRefreshDelay="P1D" />
    <!--     Cisco UCXN Configuration               -->
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="ucxn9a" metadataFile="/opt/shibboleth-idp/metad
ata/ucxn9a-single-agreement.xml" />
    <!--     Cisco CUCM Configuration               -->
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="cucm9a" metadataFile="/opt/shibboleth-idp/metad
ata/cucm9a.cisco.net-single-agreement.xml" />
    <!--     Cisco CI Configuration               
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="CI" metadataFile="/opt/shibboleth-idp/metadata/
idb-meta-ea7c1420-711d-4916-95f8-22de53230d1e-SP.xml" />
    </metadata:MetadataProvider>

Los metadatos SP provienen de un archivo en el sistema de archivos Shibboleth, en la ubicación donde cargó los metadatos para su organización Webex.

Configurar los atributos de aserción

1

En la sección Conector de datos, especifique dónde recuperar los atributos de sus usuarios.

Active Directory, con una identificación de MyLDAP.

<resolver:DataConnector id="MyLDAP" xsi:type="dc:LDAPDirectory"
      ldapURL="ldap://ad0a.cisco.net:389"
      baseDN="cn=Users,dc=cisco,dc=net"
      principal="Administrator@cisco.net"
      principalCredential="ThePassword">
        <dc:FilterTemplate>
            <![CDATA[
                (sAMAccountName=$requestContext.principalName)
            ]]>
        </dc:FilterTemplate>
    </resolver:DataConnector>

2

En la sección Definición de atributo, mantenga lo que ya está en la configuración para TransientID.

3

Agregue el atributo adicional que espera el SP y defina a qué se asigna en el origen del atributo.

Asigne el atributo mail (atributo de dirección de correo electrónico enActive Directory) a uid (UserId en Webex).

<resolver:AttributeDefinition id="mail-attr" xsi:type="ad:Simple" 
sourceAttributeID="mail">
        <resolver:Dependency ref="MyLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="uid" />
     </resolver:AttributeDefinition>

4

Defina qué atributo proporcionar a cada acuerdo SP en el archivo attribute-filter.xml.

Proporcione el atributo uid a Webex que se asigna a la dirección de correo electrónico del usuario.

Libere el atributo uid al acuerdo SP con Webex.

<!--  Release the attributes to cisco CI Cloud  -->
    <afp:AttributeFilterPolicy id="ReleaseToCI">
        <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" 
value="https://idbroker.webex.com/ea7c1420-711d-4916-95f8-22de53230d1e" />
        <afp:AttributeRule attributeID="transientId">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
        </afp:AttributeRule>
        <afp:AttributeRule attributeID="mail-attr">
            <afp:PermitValueRule xsi:type="basic:ANY" />
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>

La regla que creó en attribute-resolver.xml debe tener una política para liberar el atributo mail-attr al entityId que coincida con Webex.

5

Descargue el archivo de metadatos del servidor Shibboleth en /opt/shibboleth-idp/metadata. El nombre del archivo es idp-metadata.xml.

Importe los metadatos del IdP y habilite el inicio de sesión único después de una prueba

Después de exportar los metadatos de Webex, configurar su IdP y descargar los metadatos del IdP a su sistema local, estará listo para importarlos a su organización Webex desde Control Hub.

Antes de comenzar

No pruebe la integración de SSO desde la interfaz del proveedor de identidad (IdP). Solo admitimos flujos iniciados por el proveedor de servicios (iniciados por SP), por lo que debe usar la prueba de SSO de Control Hub para esta integración.

1

Elija uno:

  • Vuelva a la página de selección de certificados de Control Hub en su navegador y, a continuación, haga clic en Siguiente.
  • Vuelva a abrir Control Hub si ya no está abierto en la pestaña de su navegador. Desde la vista del cliente en Control Hub, vaya a Administración > Seguridad > Autenticación, seleccione el IdP y, a continuación, elija Acciones > Importar metadatos.
2

En la página Importar metadatos de IdP, arrastre y suelte el archivo de metadatos del IdP en la página o utilice la opción del explorador de archivos para localizar y cargar el archivo de metadatos . Haga clic en Siguiente.

Debería usar la opción Más seguro, si puede. Esto solo es posible si su IdP usó una CA pública para firmar sus metadatos.

En todos los demás casos, debe usar la opción Menos seguro. Esto incluye si los metadatos no están firmados, autofirmados o firmados por una CA privada.

Okta no firma los metadatos, por lo que debe elegir Menos seguro para una integración de Okta SSO.

3

Seleccione Probar configuración de SSO y, cuando se abra una nueva pestaña del navegador, autentique con el IdP iniciando sesión.

Si recibe un error de autenticación, puede haber un problema con las credenciales. Compruebe el nombre de usuario y la contraseña e inténtelo de nuevo.

Un error de Webex App generalmente significa un problema con la configuración del SSO. En este caso, vuelva a seguir los pasos, especialmente los pasos en los que copia y pega los metadatos de Control Hub en la configuración del IdP.

Para ver directamente la experiencia de inicio de sesión de SSO, también puede hacer clic en Copiar URL al portapapeles desde esta pantalla y pegarlo en una ventana privada del navegador. A partir de ahí, puede iniciar sesión con SSO. Este paso detiene los falsos positivos debido a un token de acceso que podría estar en una sesión existente al iniciar sesión .

4

Vuelva a la pestaña del navegador Control Hub.

  • Si la prueba fue exitosa, seleccione Prueba exitosa. Active el inicio de sesión único y haga clic en Siguiente.
  • Si la prueba no tuvo éxito, seleccione Prueba fallida. Desactive el SSO y haga clic en Siguiente.

La configuración de SSO no tiene efecto en su organización a menos que elija el primer botón de radio y active el SSO.

Qué hacer a continuación

Utilice los procedimientos de Sincronizar usuarios de Okta en Cisco Webex Control Hub si desea realizar el aprovisionamiento de usuarios de Okta a la nube de Webex.

Utilice los procedimientos de Sincronizar usuarios de Microsoft Entra ID Cisco Webex Control Hub si desea realizar el aprovisionamiento de usuarios desde Entra ID en la nube de Webex.

Puede seguir el procedimiento de Suprimir correos electrónicos automatizados para deshabilitar los correos electrónicos que se envían a nuevos usuarios de Webex App en su organización. El documento también contiene las mejores prácticas para enviar comunicaciones a los usuarios de su organización.

¿Ha encontrado este artículo útil?
¿Ha encontrado este artículo útil?