Single sign-on ja Control Hub

Single sign-on (SSO) on istunnon tai käyttäjän todennusprosessi, jonka avulla käyttäjä voi antaa tunnistetiedot yhden tai useamman sovelluksen käyttämiseksi. Prosessi todentaa käyttäjät kaikkien niiden sovellusten osalta, joihin heille on annettu oikeudet. Se poistaa lisäkehotukset, kun käyttäjät vaihtavat sovelluksia tietyn istunnon aikana.

SAML 2.0 (Security Assertion Markup Language) -liittymäprotokollaa käytetään SSO-todennuksen tarjoamiseen Webex-pilven ja identiteetin tarjoajan (IdP) välillä.

Profiilit

Webex App tukee vain verkkoselaimen SSO-profiilia. Webex App tukee verkkoselaimen SSO-profiilissa seuraavia sidoksia:

  • SP aloitti POST -> POST-sidonnan

  • SP aloitti REDIRECT -> POST-sidonnan

NameID-muoto

SAML 2.0 -protokolla tukee useita NameID-muotoja, joiden avulla voidaan viestiä tietystä käyttäjästä. Webex App tukee seuraavia NameID-muotoja.

  • 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

IdP:ltäsi lataamissasi metatiedoissa ensimmäinen merkintä on määritetty käytettäväksi Webexissä.

SingleLogout

Webex App tukee yksittäistä uloskirjautumisprofiilia. Webex App -sovelluksessa käyttäjä voi kirjautua ulos sovelluksesta, joka käyttää SAML single logout -protokollaa istunnon lopettamiseen ja uloskirjautumisen vahvistamiseen IdP:lläsi. Varmista, että IdP:si on määritetty SingleLogout.

Integroi Control Hub Shibbolethin kanssa

Määritysoppaat esittävät tietyn esimerkin SSO-integraatiosta, mutta ne eivät tarjoa tyhjentävää määritystä kaikille mahdollisuuksille. Esimerkiksi integraatiovaiheet nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient on dokumentoitu. Muut muodot, kuten urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified tai urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress , toimivat SSO-integroinnissa, mutta ne eivät kuulu dokumentaatiomme piiriin.

Määritä tämä integraatio Webex-organisaatiosi käyttäjille (mukaan lukien Webex App, Webex Meetings ja muut Control Hubissa hallinnoidut palvelut). Jos Webex-sivusto on integroitu Control Hubiin, Webex-sivusto perii käyttäjähallinnan. Jos et voi käyttää Webex Meetings -palvelua tällä tavoin eikä sitä hallita Control Hubissa, sinun on tehtävä erillinen integrointi Webex Meetingsin SSO:n käyttöön ottamiseksi. (Katso Configure Single Sign-On for Webex lisätietoja SSO-integraatiosta sivuston hallinnassa.)

Integrointivaiheet koskevat Shibboleth 2.4.5:tä CentOS 7:ssä ja Tomcat 7:ää verkkopalvelimena.

Ennen kuin aloitat

SSO:n ja Control Hubin osalta id-palveluntarjoajien on oltava SAML 2.0 -määrittelyn mukaisia. Lisäksi IdP:t on määritettävä seuraavalla tavalla:

Lataa Webexin metatiedot paikalliseen järjestelmään.

1

Siirry asiakasnäkymässä osoitteessa https://admin.webex.com kohtaan Hallinta > Organisaatioasetukset ja selaa sitten kohtaan Todennus ja vaihda sitten Single sign-on -asetus käynnistääksesi ohjatun asennuksen.

2

Valitse organisaatiollesi sopiva varmenteen tyyppi:

  • Ciscon itse allekirjoittama- Suosittelemme tätä vaihtoehtoa. Anna meidän allekirjoittaa todistus, jotta sinun tarvitsee uusia se vain kerran viidessä vuodessa.
  • Julkisen varmentajan allekirjoittama- Turvallisempi, mutta metatiedot on päivitettävä usein (ellei IdP-toimittaja tue luottamusankkureita).

Luottamusankkurit ovat julkisia avaimia, jotka toimivat auktoriteettina digitaalisen allekirjoituksen varmenteen varmentamisessa. Lisätietoja on IdP:n dokumentaatiossa.

3

Lataa metatietotiedosto.

Webexin metatietotiedoston nimi on idb-meta--SP.xml.

Valtuutuksen määrittäminen Shibboleth-tiedostoissa

Kun olet asentanut Shibbolethin, saat esimerkkejä sisältäviä konfiguraatiotiedostoja.

1

Siirry hakemistoon /opt/shibboleth-idp/conf päästäksesi esimerkkitiedostoihin.

2

Päätä, mitä valtuutusmenetelmää käytät - esimerkiksi LDAP-sidonta Active Directoryyn.

3

Muokkaa handler.xml -tiedostoa seuraavasti:

Uncomment

   urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

Kommentti

 urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
4

Täytä Active Directory -hakemiston tiedot, jotta todennus voidaan suorittaa. Anna asetukset tiedostoon 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"; };

Shibboleth-palveluntarjoajan komponenttien määrittäminen SAML-vakuutusta varten

1

Lisää Webex SP:stä lataamasi tiedosto hakemistoon /opt/shibboleth-idp/metadata.

2

Muokkaa relying-party.xml -tiedostoa; lisää DefaultRelyingParty-tagin jälkeen Webexin SAML-vakuutuksen tiedot.

 <rp:RelyingParty id="<span data-id="1"></span> 22de53230d1e" provider="<span data-id="2"></span> 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> <span data-id="3"></span>https://idbroker.webex.com/ea7c1420-711d-4916-95f8-https://shib9a.cisco.net/idp/shibboleth"

id:n kohdalla on käytettävä Webexin metatietotiedoston EntityID-arvoa. Korvaa esimerkin ID organisaatiosi EntityID:llä.

3

Lisää tiedoston sijainti metadata:MetadataProvider-tunnisteen sisälle:

        <!-- 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" /><span data-id="2"></span> </metadata:MetadataProvider> <span data-id="3"></span>

SP-metatiedot tulevat Shibboleth-tiedostojärjestelmässä olevasta tiedostosta, joka sijaitsee paikassa, johon olet ladannut Webex-organisaation metatiedot.

Määritä väitteen attribuutit

1

Määritä Data Connector -osiossa, mistä käyttäjiä koskevat attribuutit haetaan.

Active Directory, jonka tunniste on MyLDAP.

  <![CDATA[ (sAMAccountName=$requestContext.principalName) ]]>

2

Säilytä attribuutin määrittelyosassa se, mikä on jo olemassa kokoonpanossa transientID:n osalta.

3

Lisää ylimääräinen attribuutti, jota SP odottaa, ja määritä, mitä se vastaa attribuuttilähteessä.

Yhdistä attribuutti mail (sähköpostiosoiteattribuutti Active Directoryssä) attribuuttiin uid (UserID Webexissä).

4

Määritä, mikä attribuutti annetaan kullekin SP-sopimukselle attribute-filter.xml -tiedostossa.

Anna Webexille uid-attribuutti, joka vastaa käyttäjän sähköpostiosoitetta.

Vapauta attribuutti uid Webexin kanssa tehtyyn SP-sopimukseen.

  <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="<span data-id="1"></span> /> <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> <span data-id="2"></span>https://idbroker.webex.com/ea7c1420-711d-4916-95f8-22de53230d1e"

Säännössä, jonka olet luonut osoitteessa attribute-resolver.xml , pitäisi olla käytäntö, joka vapauttaa mail-attr-attribuutin EntityID:lle, joka vastaa Webexiä.

5

Lataa metatietotiedosto Shibboleth-palvelimelta osoitteesta /opt/shibboleth-idp/metadata. Tiedoston nimi on idp-metadata.xml.

Tuo IdP-metatiedot ja ota kertakirjautuminen käyttöön testin jälkeen.

Kun olet vienyt Webex-metatiedot, määrittänyt IdP:n ja ladannut IdP-metatiedot paikalliseen järjestelmään, voit tuoda ne Webex-organisaatioon Control Hubista.

Ennen kuin aloitat

Älä testaa SSO-integraatiota identiteetin tarjoajan (IdP) käyttöliittymästä. Tuemme vain palveluntarjoajan (SP) käynnistämiä virtoja, joten sinun on käytettävä Control Hub SSO -testiä tätä integrointia varten.

1

Valitse yksi:

  • Palaa selaimessasi Control Hub - varmenteen valintasivulle ja napsauta sitten Next.
  • Jos Control Hub ei ole enää avoinna selaimen välilehdellä, siirry asiakasnäkymästä https://admin.webex.com, valitse Hallinta > Organisaatioasetukset, selaa kohtaan Todennus ja valitse sitten Toiminnot > Tuo metatiedot.
2

Tuo IdP-metatiedot -sivulla joko raahaa ja pudota IdP-metatietotiedosto sivulle tai käytä tiedostoselaimen vaihtoehtoa metatietotiedoston etsimiseen ja lataamiseen. Napsauta Next.

Sinun kannattaa käyttää More secure -vaihtoehtoa, jos voit. Tämä on mahdollista vain, jos tunnistuspalveluntarjoajasi on käyttänyt julkista varmentajaa metatietojensa allekirjoittamiseen.

Kaikissa muissa tapauksissa on käytettävä Vähemmän suojattua -vaihtoehtoa. Tämä koskee myös sitä, jos metatietoja ei ole allekirjoitettu, jos niitä on allekirjoitettu itse tai jos niitä on allekirjoittanut yksityinen varmentaja.

Okta ei allekirjoita metatietoja, joten sinun on valittava Less secure Okta SSO -integraatiota varten.

3

Valitse Test SSO setup, ja kun uusi selainvälilehti avautuu, tunnistaudu IdP:n kanssa kirjautumalla sisään.

Jos saat todennusvirheen, tunnuksissa voi olla ongelma. Tarkista käyttäjätunnus ja salasana ja yritä uudelleen.

Webex App -virhe tarkoittaa yleensä ongelmaa SSO-asetuksissa. Käy tässä tapauksessa vaiheet uudelleen läpi, erityisesti vaiheet, joissa kopioit ja liität Control Hubin metatiedot IdP-asetuksiin.

Jos haluat nähdä SSO-sisäänkirjautumiskokemuksen suoraan, voit myös napsauttaa Kopioi URL-osoite leikepöydälle tästä näytöstä ja liittää sen yksityiseen selainikkunaan. Sieltä voit käydä läpi kirjautumisen SSO:lla. Tämä vaihe estää vääriä positiivisia tuloksia, jotka johtuvat kirjautumisen yhteydessä mahdollisesti olemassa olevassa istunnossa olevasta käyttöoikeustunnuksesta.

4

Palaa Control Hub -selainvälilehdelle.

  • Jos testi onnistui, valitse Onnistunut testi. Ota SSO käyttöön ja napsauta Seuraava.
  • Jos testi ei onnistunut, valitse Epäonnistunut testi. Ota SSO pois käytöstä ja napsauta Seuraava.

SSO-konfiguraatio ei tule voimaan organisaatiossasi, ellet valitse ensimmäistä valintaruutua ja aktivoi SSO:ta.

Mitä tehdä seuraavaksi

Käytä menettelyjä osoitteessa Synkronoi Okta-käyttäjät Cisco Webex Control Hubiin , jos haluat tehdä käyttäjien käyttöönoton Oktasta Webex-pilveen.

Käytä menettelyjä osoitteessa Synkronoi Azure Active Directory -käyttäjät Cisco Webex Control Hubiin , jos haluat tehdä käyttäjien käyttöönoton Azure AD:stä Webex-pilveen.

Voit poistaa organisaatiosi uusille Webex App -käyttäjille lähetettävät sähköpostiviestit käytöstä kohdassa Suppress Automated Emails kuvatun menettelyn mukaisesti. Asiakirjassa on myös parhaita käytäntöjä viestinnän lähettämiseen organisaatiosi käyttäjille.