Conectare unică și Control Hub

Autentificarea unică (SSO) este un proces de autentificare a sesiunii sau a utilizatorului care îi permite unui utilizator să furnizeze date de autentificare pentru a accesa una sau mai multe aplicații. Procesul autentifică utilizatorii pentru toate aplicațiile pentru care li se acordă drepturi. Elimină solicitările suplimentare atunci când utilizatorii comută între aplicații în timpul unei anumite sesiuni.

Protocolul de federație pentru Security Assertion Markup Language (SAML 2.0) este utilizat pentru a furniza autentificare 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 conexiuni:

  • SP a inițiat legarea POST -> POST

  • SP a inițiat legarea REDIRECT -> POST

Format NameID

Protocolul SAML 2.0 acceptă mai multe formate NameID pentru comunicarea 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 din IdP, prima intrare este configurată pentru utilizare în Webex.

SingleLogout

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

Integrați Control Hub cu Shibboleth


 

Ghidurile de configurare prezintă 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:transient sunt documentați. Alte formate precum urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress vor funcționa pentru integrarea SSO, dar nu intră în domeniul de aplicare al documentației noastre.

Configurați această integrare pentru utilizatorii din organizația dvs. Webex (inclusiv aplicația Webex , Webex Meetings și alte servicii administrate în Control Hub). Dacă site- Site Webex este integrat în Control Hub, Site 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 pentru Webex Meetings. (A se vedea Configurați Single Sign-On pentru Webex pentru mai multe informații despre integrarea SSO în Administrarea site-ului.)

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

Din vizualizarea clientului înhttps://admin.webex.com , accesați Management > Setări organizație , apoi derulați la Autentificare , apoi comutați pe Conectare unică pentru a porni expertul de configurare.

2

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

  • Semnat automat de Cisco —Recomandăm această alegere. Permiteți-ne să semnăm certificatul, așa că 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 verificarea certificatului unei semnături digitale. Pentru mai multe informații, consultați documentația IdP.

3

Descărcați fișierul cu metadate.

Numele fișierului cu metadate Webex este idb-meta-<org-ID> -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 ce metodă de autorizare de utilizat – de exemplu, LDAP se leagă de Active Directory.

3

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

Nu se comentează

    <!--  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 din 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 afirmația SAML

1

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

2

Editați relying-party.xml fișier ; 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-ul organizației dvs.

3

În interiorul metadatelor:MetadataEticheta furnizorului, 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 Webex.

Configurați atributele afirmației

1

În secțiunea Conector de date, specificați unde să preluați atribute 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 atribute, 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 ce face în sursa atributului.

Plasați e-mailul atributului (atribut de adresă de e-mail în Active Directory) pe 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 atributul care trebuie furnizat fiecărui acord SP în fișierul attribute-filter.xml .

Furnizați atributul Uid pentru Webex pe care îl hărțuiește 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-solve.xml trebuie să aibă o politică de eliberare a atributului mail-attr către EntityID care se potrivește cu Webex.

5

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

Importați metadatele IdP și activați conectare singură după un test

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

Înainte de a începe

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

1

Alegeți una:

  • Reveniți la pagina de selecție a certificatului Control Hub din browserul dvs., apoi faceți clic În continuare .
  • Dacă Control Hub nu mai este deschis în fila browserului, din clientul vizualizați înhttps://admin.webex.com , accesați Management > Setări organizație , derulați la Autentificare , apoi alegeți Acțiuni > Import metadate .
2

Pe pagina Import metadate furnizor de identități , fie glisați și plasați fișierul cu metadate IdP pe pagină, fie utilizați opțiunea browser fișier pentru a localiza și încărca fișierul cu metadate. Faceți clic pe Înainte.

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

În toate celelalte cazuri, trebuie să utilizați Mai puțin sigure opțiune. Aceasta include dacă metadatele nu sunt semnate, autosemnate sau semnate de un CA privat.


 

Okta nu semnează metadatele, așa că trebuie să alegeți Mai puțin sigure pentru o integrare Okta SSO .

3

Selectați Testați configurarea SSO , iar când se deschide o nouă filă de browser, autentificați-vă la IdP prin conectare.


 

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

O eroare în aplicația 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 metadatele Control Hub în configurația IdP.


 

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

4

Reveniți la fila browserului Control Hub.

  • Dacă testul a reușit, selectați Test reușit. Activați SSO și faceți clic În continuare .
  • Dacă testul nu a reușit, selectați Test nereușit. Dezactivați SSO și faceți clic În continuare .

 

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

Ce este de făcut în continuare

Utilizați procedurile din Sincronizați utilizatorii Okta în Cisco Webex Control Hub dacă doriți să efectuați configurarea utilizatorilor din Okta în cloud-ul Webex .

Utilizați procedurile din Sincronizați utilizatorii Azure Active Directory în Cisco Webex Control Hub dacă doriți să efectuați configurarea utilizatorilor din Azure AD în Webex .

Puteți urma procedura în Eliminați e-mailurile automate pentru a dezactiva e-mailurile care sunt trimise către noii 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ția dvs.