In questo articolo
dropdown icon
Single Sign-on e Control Hub
    Profili
    Formato NameID
    Logout singolo
Integri Control Hub con Shibboleth
Scarichi i metadati Webex nel suo sistema locale
Configurare l'autorizzazione nei file Shibboleth
Configurare i componenti del fornitore di servizi Shibboleth per l'asserzione SAML
Configura gli attributi dell'asserzione
Importare i metadati IdP e abilitare il single sign-on dopo un test
Configura il single sign-on in Control Hub con Shibboleth
list-menuIn questo articolo
list-menuFeedback?

Può configurare un'integrazione Single Sign-On (SSO) tra Control Hub e una distribuzione che utilizza Shibboleth come provider di identità (IdP).

Single Sign-on e Control Hub

Il Single Sign-on (SSO) è un processo di autenticazione della sessione o dell'utente che consente a un utente di fornire le credenziali per accedere a una o più applicazioni. Il processo autentica gli utenti per tutte le applicazioni per cui hanno i diritti. Elimina ulteriori richieste quando gli utenti cambiano applicazione durante una sessione particolare.

Il protocollo federativo Security Assertion Markup Language (SAML 2.0) viene utilizzato per fornire l'autenticazione SSO tra il cloud Webex e il suo provider di identità (IdP).

Profili

L'app Webex supporta solo il profilo SSO del browser web. Nel profilo SSO del browser web, l'app Webex supporta le seguenti associazioni:

  • SP ha avviato POST -> Associazione POST

  • SP ha avviato REDIRECT -> Associazione POST

Formato NameID

Il protocollo SAML 2.0 supporta diversi formati NameID per comunicare su un utente specifico. L'app Webex supporta i seguenti formati 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

Nei metadati caricati dal suo IdP, la prima voce è configurata per l'uso in Webex.

Logout singolo

L'app Webex supporta il profilo di disconnessione singolo. Nell'app Webex, un utente può disconnettersi dall'applicazione, che utilizza il protocollo SAML single logout per terminare la sessione e confermare la disconnessione con il suo IdP. Si assicuri che il suo IdP sia configurato per SingleLogout.

Integri Control Hub con Shibboleth

Le guide alla configurazione mostrano un esempio specifico di integrazione SSO ma non forniscono una configurazione esaustiva per tutte le possibilità. Ad esempio, i passaggi di integrazione per nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transientsono documentati. Altri formati, ad esempio, urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddressfunzioneranno per l'integrazione SSO ma non rientrano nell'ambito della nostra documentazione.

Configura questa integrazione per gli utenti della sua organizzazione Webex (inclusa l'app Webex e altri servizi amministrati in Control Hub). Webex Meetings Se il suo sito Webex è integrato in Control Hub, il sito Webex eredita la gestione degli utenti. Se non può accedere Webex Meetings in questo modo e non è gestito in Control Hub, deve eseguire un'integrazione separata per abilitare l'SSO perWebex Meetings.

I passaggi di integrazione si riferiscono a Shibboleth 2.4.5 in CentOS 7 con Tomcat 7 come server web.

Prima che Lei cominci

Per SSO e Control Hub, gli IDP devono essere conformi alle specifiche SAML 2.0. Inoltre, gli IDP devono essere configurati nel modo seguente:

Scarichi i metadati Webex nel suo sistema locale

1

Accedi a Control Hub.

2

Vai a Gestione > Sicurezza > Autenticazione.

3

Vada alla scheda Identity provider e faccia clic su Attiva SSO.

4

Seleziona un IdP.

5

Scelga il tipo di certificato per la sua organizzazione:

  • Autofirmato da Cisco: consigliamo questa scelta. Ci faccia firmare il certificato, quindi deve rinnovarlo solo una volta ogni cinque anni.
  • Firmato da un' autorità di certificazione pubblica: più sicuro ma dovrà aggiornare frequentemente i metadati (a meno che il suo fornitore IdP non supporti i trust anchor).

I trust anchor sono chiavi pubbliche che fungono da autorità per verificare il certificato di una firma digitale. Per ulteriori informazioni, faccia riferimento alla documentazione del suo IdP.

6

Scarichi il file di metadati.

Il nome del file dei metadati Webex è idb-meta- -SP.xml. <org-ID>

Configurare l'autorizzazione nei file Shibboleth

Dopo aver installato Shibboleth, Le vengono forniti file di configurazione con esempi.

1

Vada alla directory /opt/shibboleth-idp/conf per accedere ai file di esempio.

2

Decidi quale metodo di autorizzazione utilizzare, ad esempio, associarsi a LDAP. Active Directory

3

Modificare il file handler.xml come segue:

Decommentare

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

Commento

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

Commetta i suoi dati Active Directory per consentire l'autenticazione. Fornisca la configurazione al file 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";
};

Configurare i componenti del fornitore di servizi Shibboleth per l'asserzione SAML

1

Aggiungere il file scaricato dal Webex SP alla directory /opt/shibboleth-idp/metadata.

2

Modificare il file relying-party.xml; dopo il tag DefaultRelyingParty, aggiungere i dettagli dell'asserzione SAML per 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>

Per id, deve utilizzare il valore EntityID dal file di metadati Webex. Sostituisca l'ID dell'esempio con l'EntityID della sua organizzazione.

3

All'interno del tag Metadata:MetadataProvider, aggiunga la posizione del file:

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

I metadati SP provengono da un file nel file system Shibboleth, nella posizione in cui ha caricato i metadati per la sua organizzazione Webex.

Configura gli attributi dell'asserzione

1

Nella sezione Connettore dati, specifichi dove recuperare gli attributi sui suoi utenti.

Active Directory, con un id 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

Nella sezione Definizione degli attributi, mantenga ciò che è già nella configurazione per TransientID.

3

Aggiunga l'attributo aggiuntivo che l'SP si aspetta e definisca a cosa è associato nella fonte dell'attributo.

Mappare l'attributo mail (attributo dell'indirizzo email inActive Directory) su uid (UserID in 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

Definire quale attributo fornire a ciascun accordo SP nel file attribute-filter.xml.

Fornire l'attributo uid a Webex che corrisponde all'indirizzo email dell'utente.

Rilasciare l'attributo uid dell'accordo 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 regola da Lei creata in attribute-resolver.xml dovrebbe avere una policy per rilasciare l'attributo mail-attr all'entityID che corrisponde a Webex.

5

Scarichi il file di metadati dal server Shibboleth in /opt/shibboleth-idp/metadata. Il nome del file è idp-metadata.xml.

Importare i metadati IdP e abilitare il single sign-on dopo un test

Dopo aver esportato i metadati Webex, configurato il suo IdP e scaricato i metadati IdP nel suo sistema locale, è pronto per importarli nella sua organizzazione Webex da Control Hub.

Prima che Lei cominci

Non testi l'integrazione SSO dall'interfaccia del provider di identità (IdP). Supportiamo solo i flussi avviati dal fornitore di servizi (avviati da SP), quindi deve utilizzare il test SSO di Control Hub per questa integrazione.

1

Ne scelga uno:

  • Tornare al Control Hub — pagina di selezione dei certificati nel suo browser, quindi fare clic su Avanti.
  • Riapra Control Hub se non è più aperto nella scheda del browser. Dalla vista clienti in Control Hub, vada a Gestione > Sicurezza > Autenticazione, selezioni l'IdP e poi scelga Azioni > Importa metadati.
2

Nella pagina Importa metadati IdP, trascina e rilascia il file di metadati IdP sulla pagina o usi l'opzione del browser dei file per individuare e caricare il file di metadati. Faccia clic su Avanti.

Dovrebbe usare l'opzione Più sicuro, se può. Questo è possibile solo se il suo IdP ha utilizzato una CA pubblica per firmare i suoi metadati.

In tutti gli altri casi, deve utilizzare l' opzione Meno sicuro. Ciò include se i metadati non sono firmati, autofirmati o firmati da un'autorità di certificazione privata.

Okta non firma i metadati, quindi deve scegliere Less secure per un'integrazione SSO di Okta.

3

Seleziona Verifica configurazione SSO e, quando si apre una nuova scheda del browser, si autentichi con l'IdP effettuando l'accesso.

Se riceve un errore di autenticazione, potrebbe esserci un problema con le credenziali. Controlli il nome utente e la password e riprovi.

Un errore dell'app Webex di solito indica un problema con la configurazione dell'SSO. In questo caso, ripeta i passaggi, in particolare i passaggi in cui copia e incolla i metadati di Control Hub nella configurazione dell'IdP.

Per vedere direttamente l'esperienza di accesso SSO, può anche fare clic su Copia l'URL negli appunti da questa schermata e incollarlo in una finestra privata del browser. Da lì, può procedere con l' accesso con SSO. Questo passaggio blocca i falsi positivi dovuti a un token di accesso che potrebbe trovarsi in una sessione esistente dal momento in cui Lei ha effettuato l'accesso.

4

Tornare alla scheda del browser Control Hub.

  • Se il test ha avuto esito positivo, selezioni Test riuscito. Attivi l'SSO e faccia clic su Avanti.
  • Se il test non ha avuto esito positivo, selezioni Test non riuscito. Disattivi l'SSO e faccia clic su Avanti.

La configurazione SSO non ha effetto nella sua organizzazione a meno che Lei non scelga il primo pulsante di opzione e attivi l'SSO.

Cosa fare dopo

Utilizza le procedure in Synchronize Okta Users in Cisco Webex Control Hub se desidera eseguire il provisioning degli utenti da Okta al cloud Webex.

Utilizza le procedure in Sincronizza gli utenti dell'ID Microsoft Entra Cisco Webex Control Hub se desidera eseguire il provisioning degli utenti dall'ID Entra nel cloud Webex.

Può seguire la procedura descritta in Elimina le e-mail automatizzate per disabilitare le e-mail inviate ai nuovi utenti dell'app Webex nella sua organizzazione. Il documento contiene anche le migliori pratiche per l' invio di comunicazioni agli utenti della sua organizzazione.

Questo articolo è stato utile?
Questo articolo è stato utile?