Egyszeri bejelentkezés és Control Hub

Az egyszeri bejelentkezés (SSO) egy munkamenet- vagy felhasználó-hitelesítési folyamat, amely lehetővé teszi a felhasználó számára, hogy hitelesítési adatokat adjon meg egy vagy több alkalmazás eléréséhez. A folyamat hitelesíti a felhasználókat az összes olyan alkalmazás esetében, amelyhez jogosultságokat kaptak. Kiküszöböli a további felszólításokat, amikor a felhasználók alkalmazást váltanak egy adott munkamenet során.

A Security Assertion Markup Language (SAML 2.0) összevonási protokoll biztosítja az SSO -hitelesítést a Webex -felhő és az identitásszolgáltató (IdP) között.

Profilok

A Webex alkalmazás csak a webböngésző SSO -profilját támogatja. A webböngésző SSO -profiljában a Webex alkalmazás a következő összerendeléseket támogatja:

  • SP kezdeményezte POST -> POST-összerendelés

  • Az SP REDIRECT -> POST összerendelés kezdeményezte

NameID formátum

Az SAML 2.0 protokoll számos NameID formátumot támogat egy adott felhasználóval kapcsolatos kommunikációhoz. A Webex alkalmazás a következő NameID formátumokat támogatja.

  • 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

Az IdP-ről betöltött metaadatokban az első bejegyzés a Webex való használatra van konfigurálva.

SingleLogout

A Webex alkalmazás támogatja az egyszeri kijelentkezési profilt. A Webex alkalmazásban a felhasználó kijelentkezhet az alkalmazásból, amely az SAML egyszeri kijelentkezési protokollt használja a munkamenet befejezéséhez, és a kijelentkezés megerősítéséhez az Ön IdP-jével. Győződjön meg arról, hogy az IdP-je SingleLogout-ra van konfigurálva.

A Control Hub integrálása a Shibboleth alkalmazással


 

A konfigurációs útmutatók egy konkrét példát mutatnak be az SSO-integrációra, de nem adnak teljes körű konfigurációt az összes lehetőséghez. Például a következőhöz: nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient tartozó integrációs lépések dokumentálva vannak. Más formátumok, mint pl.: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress működni fognak SSO-integráció esetén, de nem tartoznak a dokumentációnk hatókörébe.

Állítsa be ezt az integrációt a Webex -szervezet felhasználói számára (beleértve a Webex alkalmazást, a Webex Meetings alkalmazást és más, a Control Hubban felügyelt szolgáltatásokat). Ha a Webex-webhely be van építve a Control Hubba, a Webex-webhely örökli a felhasználókezelést. Ha nem tudja így elérni a Webex Meetings alkalmazást, és azt nem a Control Hub kezeli, külön integrációt kell végrehajtania az SSO a Webex Meetings számára engedélyezéséhez. (Lásd Egyszeri bejelentkezés konfigurálása a Webex számára További információ az SSO -integrációról a Webes adminisztráció.)

Az integrációs lépések a Shibboleth 2.4.5-ös verzióra vonatkoznak a CentOS 7 rendszerben, ahol a Tomcat 7 a webkiszolgáló.

Mielőtt elkezdené

Az SSO és a Control Hub esetében az IdP-knek meg kell felelniük az SAML 2.0 specifikációnak. Ezenkívül az IdP-ket a következő módon kell konfigurálni:

Töltse le a Webex metaadatokat a helyi rendszerére

1

Ügyfélnézetből inhttps://admin.webex.com , menjen ide: Kezelés > Szervezeti beállítások elemre gombot, majd görgessen a lehetőséghez Hitelesítés , majd kapcsolja be a lehetőséget Egyszeri bejelentkezés beállítást a telepítővarázsló elindításához.

2

Válassza ki a tanúsítvány típusát a szervezete számára:

  • Cisco saját aláírásával — Ezt a választást javasoljuk. Írjuk alá a tanúsítványt, hogy csak ötévente kelljen megújítania.
  • Nyilvános hitelesítő hatóság írta alá — Biztonságosabb, de gyakran frissítenie kell a metaadatokat (kivéve, ha az IdP szállítója támogatja a megbízhatósági horgonyokat).

 

A megbízhatósági horgonyok nyilvános kulcsok, amelyek a digitális aláírás tanúsítványának ellenőrzésére jogosultak. További információkért olvassa el az IdP dokumentációját.

3

Töltse le a metaadatfájlt.

A Webex -metaadat fájlnév: idb-meta-<org-ID> -SP.xml .

Engedélyezés konfigurálása a Shibboleth-fájlokban

A Shibboleth telepítése után példákat tartalmazó konfigurációs fájlok jelennek meg.

1

Lépjen a címtárba /opt/shibboleth-idp/conf a példafájlok eléréséhez.

2

Döntse el, melyik hitelesítési módszert használja – például: LDAP -kötés az Active Directory.

3

Szerkessze a handler.xml fájlba a következőképpen:

Megjegyzés törlése

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

Hozzászólás

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

Töltse ki az Active Directory adatait, hogy lehetővé tegye a hitelesítést. Adja meg a konfigurációt a fájlhoz 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";
};

Konfigurálja a Shibboleth szolgáltató összetevőket az SAML érvényesítéshez

1

Adja hozzá a Webex SP-ből letöltött fájlt a könyvtárba /opt/shibboleth-idp/metadata .

2

Szerkessze a relying-party.xml fájl; a DefaultRelyingParty címke után adja hozzá a Webex SAML -igénylésének részleteit.

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

Az azonosítóhoz a Webex metaadatfájlból származó EntityID értéket kell használnia. Cserélje le a példa azonosító a szervezete EntityID azonosítójára.

3

A metadata:MetadataProvider címkén belül adja meg a fájl helyét:

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

Az SP metaadatok a Shibboleth fájlrendszer egyik fájljából származnak, azon a helyen, ahová feltöltötte a metaadatokat a Webex szervezethez.

Állítsa be az érvényesítési attribútumokat

1

Az Adatösszekötő részben adja meg, hogy honnan szeretné lekérni a felhasználókra vonatkozó attribútumokat.

Active Directory, MyLDAP azonosítóval.

<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

Az Attribútumdefiníció részben tartsa meg azt, ami már a transientID konfigurációjában van.

3

Adja hozzá az SP által várt extra attribútumot, és adja meg, hogy az attribútumforrásban mire legyen leképezve.

A mail (e- e-mail-cím attribútum az Active Directory) hozzárendelése az uid (Felhasználói azonosító a Webex) értékre.

<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

Határozza meg, hogy melyik attribútumot adja meg az egyes SP-megállapodásokhoz a attribútum-filter.xml fájlt.

Adja meg a Webex számára az uid attribútumot, amely a felhasználó e- e-mail-cím van hozzárendelve.

Engedje el az uid attribútumot a Webex kötött SP-megállapodáshoz.

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

Az Ön által létrehozott szabály: attribútum-resolver.xml rendelkeznie kell egy szabályzattal, amely felszabadítja a mail-attr attribútumot a Webexnek megfelelő Webex számára.

5

Töltse le a metaadatfájlt a Shibboleth szerverről /opt/shibboleth-idp/metadata . A fájlnév: idp-metadata.xml .

Importálja az IdP-metaadatokat, és engedélyezze az egyszeri bejelentkezés egy teszt után

Miután exportálta a Webex metaadatokat, konfigurálta az IdP-t, és letöltötte az IdP-metaadatokat a helyi rendszerre, készen áll arra, hogy importálja azokat a Webex -szervezetbe a Control Hubból.

Mielőtt elkezdené

Ne tesztelje az SSO -integrációt az identitásszolgáltató (IdP) felületről. Csak a szolgáltató által kezdeményezett (SP által kezdeményezett) folyamatokat támogatjuk, ezért ehhez az integrációhoz a Control Hub SSO tesztjét kell használnia.

1

Válasszon egyet:

  • Térjen vissza a Control Hub – tanúsítvány kiválasztó oldalára a böngészőjében, majd kattintson a gombra Következő .
  • Ha a Control Hub már nincs megnyitva a böngésző lapon, az ügyfélnézetből behttps://admin.webex.com , menjen ide: Kezelés > Szervezeti beállítások elemre , görgessen a lehetőséghez Hitelesítés , majd válassza a lehetőséget Műveletek lehetőségre > Metaadatok importálása .
2

Az IdP-metaadatok -metaadatok importálása oldalon húzza át az IdP-metaadatfájlt az oldalra, vagy használja a fájlböngészőt a metaadatfájl megkereséséhez és feltöltéséhez. Kattintson a Tovább gombra.

Használnia kell a Biztonságosabb opciót, ha teheti. Ez csak akkor lehetséges, ha az IdP nyilvános hitelesítésszolgáltatót használt a metaadatainak aláírásához.

Minden egyéb esetben a Kevésbé biztonságos opciót. Ez vonatkozik arra az esetre is, ha a metaadatok nem privát hitelesítésszolgáltató által aláírt, önaláírt vagy aláírt.


 

Az Okta nem írja alá a metaadatokat, ezért választania kell Kevésbé biztonságos Okta SSO -integrációhoz.

3

Válassza ki Az SSO beállításának tesztelése , és amikor egy új böngészőlap megnyílik, bejelentkezéssel végezzen hitelesítést az IdP-vel.


 

Ha hitelesítési hibaüzenetet kap, lehet, hogy a hitelesítő adatokkal van probléma. Ellenőrizze a felhasználónevet és a jelszót, majd próbálkozzon újra.

A Webex alkalmazás hibája általában az SSO -beállítással kapcsolatos problémát jelent. Ebben az esetben ismételje meg a lépéseket, különösen azokat, amelyeknél a Control Hub metaadatait másolja és illessze be az IdP-beállításba.


 

Ha közvetlenül szeretné megtekinteni az SSO bejelentkezési élményt, kattintson az URL másolása a vágólapra lehetőségre erről a képernyőről, és illessze be egy privát böngészőablakba. Ezután kipróbálhatja az SSO-val történő bejelentkezést. Ez a lépés leállítja a hamis pozitív üzeneteket egy olyan hozzáférési token miatt, amely egy meglévő munkamenetben lehet, hogy Ön bejelentkezett.

4

Térjen vissza a Control Hub böngésző lapjára.

  • Ha a teszt sikeres volt, válassza a lehetőséget Sikeres teszt. SSO bekapcsolása és kattintson Következő .
  • Ha a teszt sikertelen volt, válassza a lehetőséget Sikertelen teszt. Az SSO kikapcsolása és kattintson Következő .

 

Az SSO -konfiguráció csak akkor lép életbe a szervezetben, ha az első választógombot választja és aktiválja az SSO-t.

Mi a következő teendő

Használja a következő eljárásokat: Az Okta-felhasználók szinkronizálása a Cisco Webex Control Hub ha az Oktából szeretne felhasználói beüzemelést végezni a Webex felhőbe.

Használja a következő eljárásokat: Az Azure Active Directory -felhasználók szinkronizálása a Cisco Webex Control Hub ha szeretné végrehajtani a felhasználók kiépítését az Azure AD-ből a Webex -felhőbe.

Az eljárást itt követheti Automatikus e-mailek letiltása a szervezeten belüli új Webex App-felhasználóknak küldött e-mailek letiltásához. A dokumentum a szervezeten belüli felhasználóknak szóló közlemények kiküldésére vonatkozó bevált módszerek is tartalmaz.