Sign-on unic și Control Hub

Sign-on unic (SSO) este o sesiune sau un proces de autentificare 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 cărora li se acordă drepturi. Elimină solicitările suplimentare atunci când utilizatorii comută aplicațiile în timpul unei anumite sesiuni.

Protocolul de federalizare a limbajului de aserțiune de securitate (SAML 2.0) este utilizat pentru a furniza autentificarea SSO între cloud-ul Webex și furnizorul de identitate (IdP).

Profiluri

Webex App acceptă numai profilul SSO al browserului web. În profilul SSO al browserului web, Webex App acceptă următoarele legături:

  • SP a inițiat legarea POST-> POST

  • SP a inițiat redirect-> post obligatoriu

Format NameID

Protocolul SAML 2.0 acceptă mai multe formate NameID pentru comunicarea despre un anumit utilizator. Webex App 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

Webex App acceptă profilul de deconectare unică. În Webex App, un utilizator se poate deconecta de la aplicație, care utilizează protocolul de deconectare unică SAML pentru a încheia sesiunea și a confirma că deconectați-vă cu IdP-ul dvs. Asigurați-vă că IdP-ul 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 urna nameid-format:oasis:names:tc:SAML:2.0:nameid-format:transient sunt documentați. Alte formate, cum ar fi urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress will work for SSO integration but are outside the scope of our documentation.

Configurați această integrare pentru utilizatorii din organizația webex (inclusiv WebexApp, Webex Meetingsși alte servicii administrate în Control Hub). Dacă site-ul Webex este integrat în Control Hub, site-ul Webex moștenește gestionarea utilizatorilor. Dacă nu puteți accesa Webex Meetings în acest fel și nu este gestionat în Control Hub , trebuie să faceți o integrare separată pentru a activa SSO pentru Webex Meetings. (A se vedea Configurați Sign-On unic 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 ControlHub, IPP-urile trebuie să fie conforme cu specificațiile SAML 2.0. În plus, IPP-urile trebuie configurate în felul următor:

Descărcați metadatele Webex în sistemul local

1

Din vizualizarea client în https://admin.webex.com, accesați Gestionare > Setări organizație , apoidefilați la Autentificare , apoi comutați pe setarea Sign-on unic pentru a porni expertul de configurare.

2

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 doar să îl reînnoiți o dată la cinci ani.
  • Semnat de o autoritate de certificare publică– Mai sigur, dar va trebui să actualizați frecvent metadatele (cu excepția cazului în care furnizorul 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.

3

Descărcați fișierul de metadate.

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

Configurarea autorizării în fișierele Shibboleth

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

1

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

2

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

3

Editați fișierul de .xml rutină de tratare după cum urmează:

Neangajare

    <!--  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 Active Directory pentru a permite autentificarea. Furnizați configurația fișierului login.config.

Exemplu:

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 aserțiunea SAML

1

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

2

Editați fișierul .xml parte bazându-se; după eticheta DefaultRelyingParty, adăugați detaliile aserțiunii 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 de metadate Webex. Înlocuiți ID-ul exemplului cu EntityID al organizației dvs.

3

În interiorul metadatelor:MetadataProvider tag, 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.

Configurarea atributelor aserțiunii

1

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

Exemplu:

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 se așteaptă și definiți la ce se mapează în sursa de atribute.

Exemplu:

Mapați atributul mail (atributul adresă de e-mail în Active 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 atributul pe care să-l furnizați fiecărui acord SP din fișierul .xml atribut-filtru.

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

Exemplu:

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 atribut-resolver.xml ar trebui să aibă o politică pentru a elibera atributul mail-attr la EntityID care se potrivește cu Webex.

5

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

Importul metadatelor IdP și activarea conectării unice 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 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 Control Hub SSO pentru această integrare.

1

Alegeți una:

  • Reveniți la pagina Control Hub – de selectare a certificatelor din browser, apoi faceți clic pe Următorul.
  • Dacă Control Hub nu mai este deschis în fila browserului, din vizualizarea client din https://admin.webex.com, accesați Gestionare > Setări organizație , defilați la Autentificare , apoi alegeți Acțiuni > Import metadate.
2

Pe pagina Import metadate IdP, fie trageți și fixați fișierul de metadate IdP în pagină, fie utilizați opțiunea browserului de fișiere pentru a localiza și încărca fișierul cu 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 a utilizat 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 un CA privat.

3

Selectați Testați configurarea SSOși, atunci când se deschide o nouă filă de browser, autentificați-vă cu IdP-ul 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 Webex App î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 configurarea IdP.


 

Pentru a vedea direct experiența de conectare SSO, puteți, de asemenea, să faceți clic pe Copiere URL în clipboard din acest ecran și să îl lipiți într-o fereastră de browser privată. De acolo, puteți merge prin conectarea cu SSO. Acest pas oprește rezultatele fals pozitive din cauza unui simbol de acces care ar putea fi într-o sesiune existentă de la a fi conectat.

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 produce efecte în organizația dvs., cu excepția cazului în care alegeți primul buton radio și activați SSO.

Ce trebuie să faceți în continuare

Puteți urma procedura din Suprimarea e-mailurilor automate pentru a dezactiva e-mailurile trimise noilor utilizatori Webex App 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.