Single Sign-on e Cisco Webex Teams

Il Single Sign-on (SSO) è un processo di autenticazione di sessione o 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 a cui sono stati assegnati i diritti. Elimina ulteriori richieste quando gli utenti commutano le applicazioni durante una determinata sessione.

Il protocollo federativo di Security Assertion Markup Language (SAML 2,0) viene utilizzato per fornire l'autenticazione SSO tra il Cisco Webex cloud e il provider di identità (IDP).

Profili

Cisco Webex Teams supporta solo il profilo SSO del browser Web. Nel profilo SSO del browser Web, Cisco Webex Teams supporta le seguenti associazioni:

  • SP ha avviato POST-> POST binding

  • Reindirizzamento avviata SP-> binding POST

Formato NameID

Il protocollo SAML 2,0 supporta diversi formati NameID per la comunicazione su un utente specifico. Cisco Webex Teams supporta i seguenti formati NameID.

  • urn: Oasis: nomi: TC: SAML: 2.0: NameID-formato: temporaneo

  • urn: Oasis: nomi: TC: SAML: 1.1: NameID-formato: non specificato

  • urn: Oasis: nomi: TC: SAML: 1.1: NameID-formato: emailAddress

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

SingleLogout

Cisco Webex Teams supporta il profilo di disconnessione singolo. Nell' Cisco Webex Teams app, un utente può disconnettersi dall'applicazione, che utilizza il protocollo di disconnessione SAML single per terminare la sessione e confermare la disconnessione con l'IDP. Assicurarsi che l'IdP sia configurato per SingleLogout.

Integrazione Cisco Webex Control Hub con Shibboleth per Single Sign-on


Le guide alla configurazione mostrano un esempio specifico per l'integrazione SSO, ma non forniscono una configurazione esaustiva per tutte le possibilità. Ad esempio, le operazioni di integrazione per NameID-Format urn: Oasis: Names: TC: SAML: 2.0: nameid-format: Transient sono documentate. Altri formati come urn: Oasis: Names: TC: SAML: 1.1: nameid-format: non specificato o urn: Oasis: Names: TC: SAML: 1.1: nameid-format: EmailAddress funzionerà per l'integrazione SSO ma non rientra nell'ambito della nostra documentazione.

Impostare questa integrazione per gli utenti nella propria Cisco Webex organizzazione (inclusi Cisco Webex Teams, Cisco WebEx Meetingse altri servizi amministrati in Cisco Webex Control Hub). Se il Webex sito è integrato Cisco Webex Control Hub, il Webex sito eredita la gestione utenti. Se non è possibile accedere Cisco WebEx Meetings in questo modo e non è gestito in Cisco Webex Control Hub, è necessario eseguire un'integrazione separata per abilitare SSO per Cisco WebEx Meetings. (Vedere Configurare il Single Sign-on per WebEx per ulteriori informazioni nell'integrazione SSO in amministrazione sito.)

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

Prima di iniziare

Per SSO e Cisco Webex Control Hub, gli IDP devono essere conformi alla specifica SAML 2,0. Inoltre, gli IDP devono essere configurati nel modo seguente:
  • Impostare l'attributo di formato NameID su urn: Oasis: Names: TC: SAML: 2.0: nameid-format:Transient

  • Configurare un'attestazione sull'IdP per includere il nome dell'attributo UID con un valore mappato all'attributo scelto in Cisco connettore directory o l'attributo utente corrispondente a quello scelto in cisco WebEx servizio di identità. (Ad esempio, questo attributo può essere indirizzo e-mail o nome utente-principale). Per istruzioni, vedere le informazioni sull'attributo personalizzato in https://www.Cisco.com/go/Hybrid-Services-Directory .

  • Utilizzare un browser supportato: si consiglia l'ultima versione di Mozilla Firefox o Google Chrome.

  • Disabilitare qualsiasi blocco popup nel browser.

Scarica i Cisco Webex metadati nel sistema locale

1

Dalla vista del cliente in https://admin.webex.com, andare a impostazioni, quindi scorrere fino a autenticazione.

2

Fare clic su modifica, quindi su integra un provider di identità di terze parti. (Avanzato), quindi fare clic su Avanti.

3

Scaricare il file di metadati.

Il Cisco Webex nome file di metadati è IDB-meta-<org-ID>-SP. XML.

Configurazione dell'autorizzazione in file Shibboleth

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

1

Andare alla directory /opt/Shibboleth-IDP/conf per accedere ai file di esempio.

2

Decidere quale metodo di autorizzazione utilizzare, ad esempio, binding LDAP a Active Directory.

3

Modificare il file handler. XML nel modo seguente:

Decommentare

    <!-- Username/password login handler --> <ph:LoginHandler xsi:type="ph:UsernamePassword" jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config"> <ph:AuthenticationMethod>urn: Oasis: nomi: TC: SAML: 2.0: AC: classi: 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

Riempire i dettagli della Active Directory per consentire l'autenticazione. Fornire la configurazione al file login. config.

Esempio:

ShibUserPassAuth {edu. VT. middleware. LDAP. JAAS. LdapLoginModule richiesto ldapUrl = "LDAP://ad0a.Cisco.NET: 389" SSL = "false" TLS = "false" baseDn = "CN = Users, DC = Cisco, DC = net" subtreeSearch = "true" userFilter = "sAMAccountName ={0}" bindDn = "CN = Amministratore, CN = utenti, DC = Cisco, DC = net "bindCredential =" ThePassword "; };

Configurazione di Shibboleth provider di servizi Cobmponents per asserzione SAML

1

Aggiungere il file scaricato da CI alla directory /opt/Shibboleth-IDP/Metadata.

2

Modificare il relying-party. XML file dopo il tag DefaultRelyingParty, aggiungere i dettagli dell'asserzione SAML per Cisco 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 Cisco Webex file di metadati. Sostituire l'ID dell'esempio con la EntityID dell'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 Cisco Webex organizzazione.

Configurazione degli attributi dell'asserzione

1

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

Esempio:

Active Directory, con un ID di LDAP.

<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, conservare ciò che è già presente nella configurazione per transientID.

3

Aggiungere l'attributo aggiuntivo che l'SP si aspetta e definire il mapping a nell'origine dell'attributo.

Esempio:

Eseguire il mapping dell'attributo e-mail (attributo indirizzo e-mail in Active Directory) a UID (ID utente in Cisco 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 Cisco Webex tale mappa all'indirizzo e-mail dell'utente.

Esempio:

Rilasciare l'UID dell'attributo all'accordo SP con Cisco 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 avere un criterio per rilasciare l'attributo mail-attr alla EntityId corrispondente Cisco 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 il Single Sign-on dopo un test

Dopo aver esportato i Cisco Webex metadati, aver configurato l'IDP e aver scaricato i metadati IDP nel sistema locale, si è pronti a importarli nella propria Cisco Webex organizzazione da Hub di controllo.

1

Scegliere un'opzione:

  • Tornare alla Cisco Webex Control Hub pagina-Esporta metadati Rubrica nel browser, quindi fare clic su Avanti.
  • Se Hub di controllo non è più aperto nella scheda del browser, dalla vista del cliente in https://admin.webex.com, andare a impostazioni, scorrere fino a autenticazione, scegliere integra un provider di identità di terze parti (avanzato), quindi fare clic su Avanti su attendibile pagina file di metadati (perché è già stata eseguita prima).
2

Nella pagina importa metadati IdP, trascinare e rilasciare il file di metadati IdP nella pagina o utilizzare l'opzione del browser del file per individuare e caricare il file di metadati. Fare clic su Avanti.

Se i metadati non sono firmati, sono firmati con un certificato autofirmato o sono firmati con un'autorità di certificazione aziendale privata (CA), si consiglia di utilizzare Richiedi certificato firmato da un'autorità di certificazione in metadati (più sicuro). Se il certificato è autofirmato, è necessario scegliere l' opzione meno sicura .

3

Selezionare Test connessione SSOe quando viene aperta una nuova scheda del browser, eseguire l'autenticazione con l'IdP accedendo.


 

Se si riceve un errore di autenticazione, potrebbe essersi verificato un problema con le credenziali. Controllare il nome utente e la password e riprovare.

Un Webex Teams errore solitamente indica un problema con l'impostazione SSO. In questo caso, scorrere nuovamente le operazioni, in particolare le operazioni in cui vengono copiati e incollati i Hub di controllo metadati nell'impostazione IDP.

4

Tornare alla Hub di controllo scheda del browser.

  • Se il test è stato eseguito correttamente, selezionare questo test è stato eseguito correttamente. Abilitare l'opzione Single Sign-on e fare clic su Avanti.
  • Se il test non è riuscito, selezionare questo test non riuscito. Disabilitare l'opzione Single Sign-on e fare clic su Avanti.

Operazioni successive

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