În acest articol
dropdown icon
Conectare unică și hub de control
    Profiluri
    Formatul numeiID
    SingleLogout
Integrați Control Hub cu Shibboleth
Descărcați metadatele Webex în sistemul dvs. local
Configurați autorizarea în fișierele Shibboleth
Configurați componentele furnizorului de servicii Shibboleth pentru afirmarea SAML
Configurați atributele afirmației
Importați metadatele IdP și activați conectarea unică după un test
Configurați conectarea unică în Control Hub cu Shibboleth
list-menuÎn acest articol
list-menuFeedback?

Puteți configura o integrare de conectare unică (SSO) între Control Hub și o implementare care utilizează Shibboleth ca furnizor de identitate (IdP).

Conectare unică și hub de control

Single sign-on (SSO) este un proces de autentificare a sesiunii sau a utilizatorului care permite unui utilizator să furnizeze acreditări pentru a accesa una sau mai multe aplicații. Procesul autentifică utilizatorii pentru toate aplicațiile la care li se acordă drepturi. Elimină solicitările suplimentare atunci când utilizatorii schimbă aplicațiile în timpul unei anumite sesiuni.

Protocolul de federație Security Assertion Markup Language (SAML 2.0) este utilizat pentru a furniza autentificarea SSO între cloud-ul Webex și furnizorul dvs. de identitate (IdP).

Profiluri

Aplicația Webex acceptă numai profilul SSO al browserului web. În profilul SSO al browserului web, aplicația Webex acceptă următoarele legături:

  • SP inițiat POST -> Legarea POST

  • SP a inițiat REDIRECT -> Legarea POST

Formatul numeiID

Protocolul SAML 2.0 acceptă mai multe formate NameID pentru a comunica despre un anumit utilizator. Aplicația Webex acceptă următoarele formate 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

În metadatele pe care le încărcați de la IdP, prima intrare este configurată pentru utilizare în Webex.

SingleLogout

Aplicația Webex acceptă profilul unic de deconectare. În aplicația Webex, un utilizator se poate deconecta de la aplicație, care utilizează protocolul de deconectare unică SAML pentru a încheia sesiunea și a confirma deconectarea cu IdP-ul tău. Asigurați-vă că IdP-ul dvs. este configurat pentru SingleLogout.

Integrați Control Hub cu Shibboleth

Ghidurile de configurare arată un exemplu specific pentru integrarea SSO, dar nu oferă o configurație exhaustivă pentru toate posibilitățile. De exemplu, pașii de integrare pentru nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transientsunt documentați. Alte formate, cum ar fi acestea, urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddressvor funcționa pentru integrarea SSO, dar sunt în afara domeniului de aplicare al documentației noastre.

Configurați această integrare pentru utilizatorii din organizația dvs. Webex (inclusiv aplicația Webex și alte servicii administrate în Control Hub). Webex Meetings Dacă site-ul dvs. Webex este integrat în Control Hub, site-ul Webex moștenește gestionarea utilizatorilor. Dacă nu puteți accesa Webex Meetings în acest mod și nu este gestionat în Control Hub, trebuie să efectuați o integrare separată pentru a activa SSO pentruWebex Meetings.

Pașii de integrare se referă la Shibboleth 2.4.5 în CentOS 7 cu Tomcat 7 ca server web.

Înainte de a începe

Pentru SSO și Control Hub, IDP-urile trebuie să respecte specificația SAML 2.0. În plus, IDP-urile trebuie configurate în felul următor:

Descărcați metadatele Webex în sistemul dvs. local

1

Conectați-vă la Control Hub.

2

Accesați Gestionare > Securitate > Autentificare.

3

Accesați fila Furniz or de identitate și faceți clic pe Activare SSO.

4

Selectați un IdP.

5

Alegeți tipul de certificat pentru organizația dvs.:

  • Auto-semnat de Cisco - Vă recomandăm această alegere. Permiteți-ne să semnăm certificatul, astfel încât trebuie să îl reînnoiți doar o dată la cinci ani.
  • Semnat de o autoritate publică de certificare —Mai sigur, dar va trebui să actualizați frecvent metadatele (cu excepția cazului în care furnizorul dvs. IdP acceptă ancore de încredere).

Ancorele de încredere sunt chei publice care acționează ca o autoritate pentru a verifica certificatul unei semnături digitale. Pentru mai multe informații, consultați documentația IdP.

6

Descărcați fișierul metadate.

<org-ID>Numele fișierului metadatelor Webex este idb-meta- -SP.xml.

Configurați autorizarea în fișierele Shibboleth

După ce instalați Shibboleth, vi se oferă fișiere de configurare cu exemple.

1

Accesați directorul /opt/shibboleth- idp/conf pentru a accesa fișierele de exemplu.

2

Decideți ce metodă de autorizare să utilizați - de exemplu, la LDAP bind. Active Directory

3

Editați fișierul handler.xml după cum urmează:

Anulați comentariul

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

Comentariu

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

Completați detaliile dvs. Active Directory pentru a permite autentificarea. Furnizați configurația fișierului 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";
};

Configurați componentele furnizorului de servicii Shibboleth pentru afirmarea SAML

1

Adăugați fișierul pe care l-ați descărcat din Webex SP în directorul /opt/shibboleth-idp/metadata.

2

Editați fișierul relying-party.xml; după eticheta defaultRelyingParty, adăugați detaliile afirmației SAML pentru 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>

Pentru id, trebuie să utilizați valoarea EntityId din fișierul metadate Webex. Înlocuiți ID-ul exemplului cu EntityID al organizației dvs.

3

În interiorul etichetei Metadata:metadataProvider, adăugați locația fișierului:

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

Metadatele SP provin dintr-un fișier din sistemul de fișiere Shibboleth, în locația în care ați încărcat metadatele pentru organizația dvs. Webex.

Configurați atributele afirmației

1

În secțiunea Conector de date, specificați unde să preluați atributele despre utilizatorii dvs.

Active Directory, cu 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

În secțiunea Definiție atribut, păstrați ceea ce este deja în configurația pentru TransientID.

3

Adăugați atributul suplimentar pe care SP îl așteaptă și definiți la ce se mapează în sursa atributului.

Mapați atributul mail (atributul adresei de e-mail înActive Directory) la uid (userID în 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

Definiți ce atribut să furnizați fiecărui acord SP în fișierul attribute-filter.xml.

Furnizați atributul uid către Webex care se mapează la adresa de e-mail a utilizatorului.

Eliberați atributul uid la acordul SP cu 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>

Regula pe care ați creat-o în attribute-resolver.xml ar trebui să aibă o politică de eliberare a atributului mail-attr la EntityID care se potrivește cu Webex.

5

Descărcați fișierul metadate de pe serverul Shibboleth în /opt/shibboleth-idp/metadata. Numele fișierului este idp-metadata.xml.

Importați metadatele IdP și activați conectarea unică după un test

După ce exportați metadatele Webex, configurați IdP-ul și descărcați metadatele IdP în sistemul local, sunteți gata să le importați în organizația dvs. Webex din Control Hub.

Înainte de a începe

Nu testați integrarea SSO din interfața furnizorului de identitate (IdP). Acceptăm doar fluxurile inițiate de furnizorul de servicii (inițiate de SP), deci trebuie să utilizați testul SSO Control Hub pentru această integrare.

1

Alegeți unul:

  • Reveniți la pagina de selectare a certificatului Hub de control din browser, apoi faceți clic pe Următorul.
  • Redeschideți Control Hub dacă nu mai este deschis în fila browserului. Din vizualizarea client din Control Hub, accesați Ges tionare > Secur itate > Autentificare, selectați IdP, apoi alegeți Ac țiuni > Import metadate.
2

În pagina Import metadate IdP, fie glisați și fixați fișierul de metadate IdP pe pagină, fie utilizați opțiunea browser de fișiere pentru a localiza și încărca fișierul de metadate . Faceți clic pe Urmă torul.

Ar trebui să utilizați opțiunea Mai sigură, dacă puteți. Acest lucru este posibil numai dacă IdP-ul dvs. a folosit un CA public pentru a-și semna metadatele.

În toate celelalte cazuri, trebuie să utilizați opțiunea Mai puțin sigură. Aceasta include dacă metadatele nu sunt semnate, auto-semnate sau semnate de o autoritate de autorizație privată.

Okta nu semnează metadatele, deci trebuie să alegeți Mai puțin sigur pentru o integrare Okta SSO.

3

Selectați Testați configurarea SSO și, atunci când se deschide o nouă filă a browserului, autentificați-vă cu IdP conectându-vă.

Dacă primiți o eroare de autentificare, este posibil să existe o problemă cu acreditările. Verificați numele de utilizator și parola și încercați din nou.

O eroare de aplicație Webex înseamnă de obicei o problemă cu configurarea SSO. În acest caz, parcurgeți din nou pașii, în special pașii în care copiați și lipiți metad atele Control Hub în configurarea IdP.

Pentru a vedea direct experiența de conectare SSO, puteți, de asemenea, să faceți clic pe Copiați adresa URL în clipboard din acest ecran și să o lipiți într-o fereastră privată a browserului. De acolo, puteți parcurge con ectarea cu SSO. Acest pas oprește rezultatele fals pozitive din cauza unui token de acces care ar putea fi într-o sesiune existentă de la conectarea dvs.

4

Reveniți la fila browserului Control Hub.

  • Dacă testul a avut succes, selectați Test de succes. Activați SSO și faceți clic pe Urmă torul.
  • Dacă testul nu a reușit, selectați Test nereușit. Dezactivați SSO și faceți clic pe Urmă torul.

Configurația SSO nu intră în vigoare în organizația dvs. decât dacă alegeți primul buton radio și activați SSO.

Ce să faci în continuare

Utilizați procedurile din Sinc ronizați utilizatorii Okta în Cisco Webex Control Hub dacă doriți să efectuați furnizarea de utilizatori din Okta în norul Webex.

Utilizați procedurile din Sinc ronizați utilizatorii Microsoft Entra ID Cisco Webex Control Hub dacă doriți să efectuați furnizarea de utilizatori din Entra ID în norul Webex.

Puteți urma procedura din Suprimarea e-mailurilor automate pentru a dezactiva e-mailurile trimise noilor utilizatori ai aplicației Webex din organizația dvs. Documentul conține, de asemenea, cele mai bune practici pentru trimiterea de comunicări către utilizatorii din organizație.

A fost util acest articol?
A fost util acest articol?