Single Sign-On e Control Hub

Il Single Sign-On (SSO) è una sessione o un processo di autenticazione 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 le quali dispongono di diritti. Elimina ulteriori prompt quando gli utenti passano da un'applicazione all'altra durante una determinata sessione.

Il protocollo di federazione Security Assertion Markup Language (SAML 2.0) viene utilizzato per fornire l'autenticazione SSO tra il cloud Webex e il provider 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:

  • POST avviato da SP -> Associazione POST

  • REDIRECT avviato da SP -> Associazione POST

Formato NameID

Il protocollo SAML 2.0 supporta diversi formati NameID per la comunicazione su uno specifico utente. Webex App 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 IdP, la prima voce è configurata per l'uso in Webex.

Disconnessione singola

L'app Webex supporta il profilo di disconnessione singola. Nell'app Webex, un utente può disconnettersi dall'applicazione, che utilizza il protocollo di disconnessione singola SAML per terminare la sessione e confermare tale disconnessione con l'IdP. Verifica che l'IdP sia configurato per la disconnessione singola.

Integrazione di 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 es. vengono documentate le fasi di integrazione per nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient. Altri formati come urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress funzioneranno per l'integrazione SSO ma non rientrano nell'ambito della nostra documentazione.

Imposta questa integrazione per gli utenti dell'organizzazione Webex (inclusi app Webex , Webex Meetings e altri servizi amministrati in Control Hub). Se il sito Webex è integrato in Control Hub, il sito Webex eredita la gestione utenti. Se non è possibile accedere a Webex Meetings in questo modo e non è gestito in Control Hub, è necessario eseguire un'integrazione separata per abilitare SSO per Webex Meetings. (vedi Configura il Single Sign-On per Webex per ulteriori informazioni sull'integrazione SSO in Amministrazione sito).

Le operazioni di integrazione si riferiscono a Shibboleth 2.4.5 in CentOS 7 con Tomcat 7 come server Web.

Operazioni preliminari

Per SSO e Control Hub, gli IdP devono essere conformi alla specifica SAML 2.0. Inoltre, gli IdP devono essere configurati nel modo seguente:

Scaricare i metadati Webex nel sistema locale

1

Dalla vista cliente inhttps://admin.webex.com , andare a Gestione > Impostazioni organizzazione , quindi scorrere fino a Autenticazione , quindi attivare il Single Sign-On per avviare la procedura di installazione guidata.

2

Scegli il tipo di certificato per la tua organizzazione:

  • Autofirmato da Cisco —Si consiglia questa scelta. Consente di firmare il certificato in modo che sia necessario rinnovarlo solo una volta ogni cinque anni.
  • Firmato da un'autorità di certificazione pubblica —Più sicuro, ma dovrai aggiornare frequentemente i metadati (a meno che il 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, fare riferimento alla documentazione IdP.

3

Scarica il file dei metadati.

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

Configura autorizzazione in file Shibboleth

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

1

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

2

Decidere quale metodo di autorizzazione utilizzare, ad esempio, LDAP si lega ad Active Directory.

3

Modificare il file handler.xml come segue:

Annulla commento

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

Compilare i dettagli di Active Directory per consentire l'autenticazione. Fornire 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";
};

Configurazione dei componenti del provider di servizi Shibboleth per l'asserzione SAML

1

Aggiungere il file scaricato da Webex SP alla directory /opt/shibboleth-idp/metadati.

2

Modificare il relying party.xml file; dopo il tag DefaultRelyingParty, aggiungi 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, è necessario utilizzare il valore EntityID dal file di metadati Webex. Sostituire l'ID dell'esempio con l'EntityID dell'organizzazione.

3

All'interno dei metadati:tag MetadataProvider, aggiungi 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 sono stati caricati i metadati per la propria organizzazione Webex.

Configura gli attributi dell'asserzione

1

Nella sezione Connettore dati, specificare dove recuperare gli attributi relativi agli utenti.

Active Directory, con un id di 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 attributo, mantenere ciò che è già nella configurazione per transientID.

3

Aggiungere l'attributo aggiuntivo previsto dal protocollo SP e definire le mappe nella fonte dell'attributo.

Associa la posta dell'attributo (attributo dell'indirizzo e-mail in Active Directory) a 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 l'attributo da fornire a ciascun contratto SP nel file attribute-filter.xml.

Fornire l'attributo uid a Webex associato all'indirizzo e-mail dell'utente.

Rilasciare l'uid dell'attributo al contratto 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 creata in attribute-resolver.xml deve disporre di un criterio per rilasciare l'attributo mail-attr all'EntityID corrispondente a Webex.

5

Scaricare il file di metadati dal server Shibboleth in /opt/shibboleth-idp/metadati. 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 tuo IdP e scaricato i metadati IdP nel sistema locale, sei pronto per importarli nell'organizzazione Webex da Control Hub.

Operazioni preliminari

Non testare l'integrazione SSO dall'interfaccia del provider di identità (IdP). Sono supportati solo i flussi avviati dal provider di servizi (SP), pertanto devi utilizzare il test SSO Control Hub per questa integrazione.

1

Scegli un'opzione:

  • Ritornare alla pagina di selezione del certificato Control Hub - nel browser, quindi fare clic su Avanti .
  • Se Control Hub non è più aperto nella scheda del browser, dalla vista del cliente inhttps://admin.webex.com , andare a Gestione > Impostazioni organizzazione , scorrere fino a Autenticazione , quindi scegliere Azioni > Importa metadati .
2

Nella pagina Importa metadati IdP, trascina la selezione del file di metadati IdP sulla pagina o utilizza l'opzione del file browser per individuare e caricare il file di metadati. Fai clic su Avanti.

È necessario utilizzare il file Più sicuro opzione, se possibile. Ciò è possibile solo se il provider di identità ha utilizzato un'Autorità di certificazione pubblica per firmare i metadati.

In tutti gli altri casi, è necessario utilizzare il file Meno sicuro opzione. Ciò include se i metadati non sono firmati, autofirmati o firmati da un'Autorità di certificazione privata.


 

Okta non firma i metadati, quindi devi scegliere Meno sicuro per un'integrazione Okta SSO .

3

Selezionare Verificare l'impostazione SSO , e quando si apre una nuova scheda del browser, eseguire l'autenticazione con l'IdP eseguendo l'accesso.


 

Se ricevi un errore di autenticazione in tal punto, è possibile che vi sia un problema con le credenziali. Verifica nome utente e password e riprova.

Un errore dell'app Webex solitamente indica un problema con l'impostazione SSO . In tal caso, esegui nuovamente la procedura, in particolare fai attenzione ai passaggi in cui devi copiare e incollare i metadati Control Hub nell'impostazione IdP.


 

Per visualizzare direttamente l'esperienza di accesso SSO, puoi anche fare clic su Copia URL negli appunti da questa schermata e incollare in una finestra del browser privata. Da qui, puoi eseguire l'accesso con SSO. Questo passaggio consente di impedire i falsi positivi a causa di un token di accesso che potrebbe trovarsi in una sessione esistente dopo aver eseguito l'accesso.

4

Torna alla scheda del browser Control Hub.

  • Se il test ha esito positivo, selezionare Test eseguito correttamente. Attiva SSO e fare clic Avanti .
  • Se il test non ha esito positivo, selezionare Test non riuscito. Disattiva SSO e fare clic Avanti .

 

La configurazione SSO non ha effetto nell'organizzazione a meno che non si scelga Primo pulsante di opzione opzione e si attivi SSO.

Operazioni successive

Utilizzare le procedure in Sincronizza gli utenti Okta in Cisco Webex Control Hub se si desidera eseguire il provisioning utenti da Okta al cloud Webex .

Utilizzare le procedure in Sincronizza gli utenti di Azure Active Directory in Cisco Webex Control Hub se si desidera eseguire il provisioning utente da Azure AD nel cloud Webex .

È possibile seguire la procedura in Eliminazione dei messaggi e-mail automatici per disabilitare i messaggi e-mail inviati ai nuovi utenti dell'app Webex nell'organizzazione. Il documento contiene anche le procedure consigliate per l'invio di comunicazioni agli utenti nella tua organizzazione.