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 SAML 2.0 (Security Assertion Markup Language) viene utilizzato per fornire l'autenticazione SSO tra il cloud Webex e il provider di identità (IdP).

Profili

L'app Webex supporta solo il profilo SSO web browser. Nel profilo web SSO, 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. L'app Webex supporta i seguenti formati di 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 dall'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 la 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 esempio, viene documentata la procedura 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 o urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress sono validi per l'integrazione SSO ma non rientrano nell'ambito della nostra documentazione.

Impostare questa integrazione per gli utenti nell'organizzazione Webex (inclusi App Webex , Webex Meetings e altri serviziamministrati in Control Hub). Se il sito Webex è integrato in ControlHub, il sito Webex eredita la gestione degli utenti. Se non è possibile accedere Webex Meetings in questo modo e non è gestito in Control Hub , è necessario effettuare un'integrazione separata per abilitare l'SSO per Webex Meetings. (vedi Configura il Single Sign-On per Webex per ulteriori informazioni sull'integrazione SSO in Amministrazione sito).

La procedura di integrazione fa riferimento 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 come segue:

Scarica i metadati Webex sul sistema locale

1

Dalla vista del cliente in , andare a Gestione > Impostazioni organizzazione , quindi scorrere fino ad Autenticazione , quindi attivare l'impostazione https://admin.webex.com Single Sign-On per avviare la procedura di installazione guidata.

2

Scegliere il tipo di certificato per la propria organizzazione:

  • Autofirmato daCisco: questa scelta è consigliata. Firma il certificato in modo da rinnovarlo una volta ogni cinque anni.
  • Firmata da un'autorità di certificazione pubblica: più sicura, ma occorre aggiornare frequentemente i metadati (a meno che il fornitore idP non supporti glitrust anchor).

 

Gli trust anchor sono chiavi pubbliche che agiscono 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 file di metadati Webex èidb-meta-<org-ID>-SP.xml.

Configurazione dell'autorizzazione nei file Shibboleth

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

1

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

2

Decidere il metodo di autorizzazione da utilizzare, ad esempio, associazione 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

Compilare i dettagli del Active Directory consentire l'autenticazione. Fornire la configurazione al file login.config.

Esempio:

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 provider di servizi Shibboleth per l'asserzione SAML

1

Aggiungere il file scaricato da Webex SP nella 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 l'ID, è necessario utilizzare il valore EntityID del file di metadati Webex. Sostituire l'ID dell'esempio con entityID della propria organizzazione.

3

All'interno del tag metadata:MetadataProvider, aggiungere 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.

Configurare gli attributi di asserzione

1

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

Esempio:

Active Directory, con 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 della definizione dell'attributo, mantenere ciò che è già nella configurazione per transientID.

3

Aggiungere l'attributo aggiuntivo previsto da SP e definire a cosa corrisponde nell'origine dell'attributo.

Esempio:

Mappare l'attributo mail (attributo 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 che esegue la mappatura all'indirizzo e-mail dell'utente.

Esempio:

Rilasciare l'uid attributo per il 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-attr.xml deve disporre di un criterio per rilasciare l'attributo mail-attr per l'EntityID corrispondente a Webex.

5

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

Importare i metadati IdP e abilitare la Single Sign-On dopo un test

Dopo aver esportato i metadati Webex, configurato l'IdP e scaricato i metadati IdP nel sistema locale, è possibile 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:

  • Tornare alla pagina Control Hub – selezione del certificato nel browser, quindi fare clic su Avanti .
  • Se Control Hub non è più aperto nella scheda del browser, dalla vista del cliente in , andare a Gestione > Impostazioni organizzazione , scorrere fino > Autenticazione , quindi scegliere Azioni https://admin.webex.com > 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. Fare clic su Avanti.

Se possibile, è necessario utilizzare l'opzione Più sicura. Ciò è possibile solo se l'IdP ha utilizzato una CA pubblica per firmare i relativi metadati.

In tutti gli altri casi, occorre utilizzare l'opzione Meno sicura. Ciò include se i metadati non sono firmati, autofirmati o firmati da una CA privata.

3

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


 

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 SSO impostazione. 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 SSO'accesso, è possibile fare clic su Copia URL negli Appunti da questa schermata e incollarlo in una finestra del browser privata. Da qui, è possibile accedere direttamente SSO. Questa operazione interrompe i false positives (falso) a causa del token di accesso che potrebbe essere in una sessione esistente dall'accesso.

4

Torna alla scheda del browser Control Hub.

  • Se il test ha esito positivo, selezionare Test completato correttamente. Attivare questa SSO fare clic su Avanti.
  • Se il test non è riuscito, selezionare Test non riuscito. Disattivare la SSO e fare clic su Avanti.

 

La SSO della configurazione del sistema non ha effetto nell'organizzazione a meno che non si sce pulsante di opzione e si attiva SSO.

Operazione successivi

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