Inicio de sesión único y Control Hub

El inicio de sesión único (SSO) es un proceso de autenticación de sesiones o usuarios que permite que el usuario proporcione credenciales para acceder a una o varias aplicaciones. El proceso autentica a los usuarios para todas las aplicaciones que tengan derecho a usar. Elimina la aparición de mensajes adicionales cuando los usuarios cambian de una aplicación a otra durante una sesión en particular.

Se utiliza el Protocolo de federación del Lenguaje de marcado de aserción de seguridad (Security Assertion Markup Language, SAML 2.0) para proporcionar autenticación de SSO entre la nube de Webex y su proveedor de servicios de identidad (IdP).

Perfiles

La aplicación de Webex solo es compatible con el explorador web SSO perfil. En el navegador web SSO perfil, la aplicación de Webex admite los siguientes enlaces:

  • SP initiated POST -> POST binding

  • SP initiated REDIRECT -> POST binding

Formato NameID

El protocolo SAML 2.0 proporciona soporte para varios formatos de NameID a fin de comunicar información sobre un usuario específico. La aplicación de 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 ser utilizarla en Webex.

SingleLogout

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

Integrar Control Hub con Shibboleth

Las guías de configuración muestran un ejemplo específico para la integración del SSO, pero no proporcionan una configuración exhaustiva para todas las posibilidades. Por ejemplo, se documentan los pasos de integración para el formato de “nameid” urn:oasis:names:tc:SAML:2.0:nameid-format:transient. Otros formatos como urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified o urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress funcionarán para la integración del SSO, pero están fuera del alcance de nuestra documentación.

Configure esta integración para los usuarios de su organización de Webex ( incluida la aplicación Webex, Webex Meetingsy otros servicios administrados en Control Hub). Si su sitio de Webex está integrado en Control Hub, el sitio de Webex hereda la administración de usuarios. Si no puede acceder a Webex Meetings de esta manera y no se administra en Control Hub, debe realizar una integración aparte para habilitar SSO para Webex Meetings. (Consulte Configurar el inicio de sesión único para Webex para obtener más información sobre la Integración del SSO en la Administración del sitio).

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

Antes de comenzar

Para SSO Control Hub, los IdP deben cumplir con la especificación SAML 2.0. Además, los IdP se deben configurar de la siguiente manera:

Descargue los metadatos de Webex en su sistema local

1

Desde la vista del cliente en ,https://admin.webex.com vaya a Administración > Configuración de la organización y, a continuación,desplácese hasta Autenticación y, luego, active el ajuste del Inicio de sesión único para iniciar el asistente de configuración.

2

Elija el tipo de certificado para su organización:

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

 

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

Descargue el archivo de metadatos.

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

Configurar la autorización en archivos de Shibboleth

Una vez que haya instalado Shibboleth, tendrá archivos de configuración con ejemplos.

1

Diríjase al directorio /opt/shibboleth-idp/conf para acceder a los archivos de ejemplo.
2

Decida qué método de autorización se usará, por ejemplo: enlace LDAP a Active Directory.
3

Edite el archivo handler.xml de la siguiente manera:

Desmarque como comentario

    <!--  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>

Marque como 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 los detalles de su Active Directory para permitir la autenticación. Proporcione la configuración para el archivo login.config.

Ejemplo:

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 de 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 utilizar el valor de EntityID del archivo de metadatos de Webex . Reemplace el ID del ejemplo por el valor de 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 de SP proviene de un archivo del sistema de archivos de Shibboleth, que se encuentra en la ubicación donde usted haya cargado los metadatos para su organización de Webex .

Configurar los atributos de la aserción

1

En la sección de Conectores de datos, especifique dónde se recuperarán los atributos sobre sus usuarios.

Ejemplo:

Active Directory, con un id 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 de Definición de atributos, no haga cambios en la configuración correspondiente a transientID.
3

Agregue el atributo adicional que está esperando SP, y defina a qué elemento se asigna en el origen del atributo.

Ejemplo:

Asigne el atributo mail (atributo de la dirección de correo electrónico en Active 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 se proporcionará a cada acuerdo de 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.

Ejemplo:

Libere el atributo uid al acuerdo de 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 debería 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.

Importar los metadatos del IdP y habilitar la 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á en disposición de importarlos a su organización de Webexdesde Control Hub.

Antes de comenzar

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

1

Elija una opción:

  • Regrese a la página de selección de certificados del Control Hub en su explorador y, luego, haga clic en Siguiente.
  • Si el Control Hub ya no está abierto en la ficha del explorador,https://admin.webex.com desde la vista del cliente en ,vaya a Administración > Configuración de la organización, desplácese hasta Autenticación y, a continuación, elija Acciones > Importar metadatos.
2

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

Debe utilizar la opción Más seguro, si puede. Esto solo es posible si su IdP utilizó una CA pública para firmar sus metadatos.

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

Seleccione Configuración SSO pruebay, cuando se abra una nueva ficha del navegador, autentique el IdP iniciando sesión.


 

Si recibe un error de autenticación, es posible que haya un problema con las credenciales. Controle el nombre de usuario y la contraseña e inténtelo nuevamente.

Un error de la aplicación de Webex suele significar que hay un problema con la SSO configuración. En este caso, repita los pasos, especialmente los pasos en los que copia y pega los metadatos de Control Hub en la configuración del IdP.

 

Para ver la SSO inicio de sesión de forma directa, también puede hacer clic en Copiar URL al portapapeles desde esta pantalla y pegarla en una ventana privada del explorador. Desde allí, puede realizar un recorrido para 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 de que usted haya iniciado sesión.
4

Vuelva a la ficha del navegador de Control Hub.

  • Si la prueba fue exitosa, seleccione Prueba exitosa. Active la SSO y haga clic en Siguiente.
  • Si la prueba no fue exitosa, seleccione Prueba no exitosa. Desactive la SSO y haga clic en Siguiente.

 

La SSO de ajustes no tendrá efecto en su organización a menos que elija el nombre botón de opciones y active SSO.

Qué hacer a continuación

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