Engangspålogging og Control Hub

Single sign-on (SSO) er en økt- eller brukerautentiseringsprosess som gjør det mulig for en bruker å oppgi legitimasjon for å få tilgang til ett eller flere programmer. Prosessen autentiserer brukere for alle programmene de har rettigheter til. Det eliminerer ytterligere meldinger når brukere bytter programmer i løpet av en bestemt økt.

SAML 2.0 (Security Assertion Markup Language) Federation Protocol brukes til å gi SSO-autentisering mellom Webex-skyen og identitetsleverandøren din (IdP).

Profiler

Webex-appen støtter bare SSO-profilen til nettleseren. Webex-appen støtter følgende bindinger i nettleserens SSO-profil:

  • SP initiert POST -> POST binding

  • SP initiert OMDIRIGERING -> POST binding

Navn-ID-format

SAML 2.0-protokollen støtter flere navn-ID-formater for kommunikasjon om en bestemt bruker. Webex-appen støtter følgende Navn-ID-formater.

  • urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  • urn:oasis:names:tc:SAML:1.1:nameid-format:uspesifisert

  • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

I metadataene du laster inn fra din IdP, konfigureres den første oppføringen for bruk i Webex.

Engangsutlogging

Webex-appen støtter engangsutlogging-profilen. I Webex-appen kan en bruker logge av programmet, som bruker SAML-protokollen for engangsutlogging til å avslutte økten og bekrefte at du logger av med IdP-en din. Sørg for at din IdP er konfigurert for engangsutlogging.

Integrer Control Hub med Shibboleth

Konfigurasjonsveiledningene viser et spesifikt eksempel for SSO-integrering, men gir ikke fullstendig konfigurasjon for alle muligheter. For eksempel er integreringstrinnene for nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient dokumentert. Andre formater som urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified eller urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress fungerer for SSO-integrering, men er utenfor omfanget av vår dokumentasjon.

Konfigurer denne integreringen for brukere i Webex-organisasjonen (inkludert Webex-appen, Webex Meetings og andre tjenester administrert i Control Hub). Hvis Webex-nettstedet ditt er integrert i Control Hub, arver Webex-nettstedet brukeradministrasjonen. Hvis du ikke får tilgang til Webex Meetings på denne måten, og det ikke administreres i Control Hub, må du utføre en separat integrering for å aktivere SSO for Webex Meetings. (Se Konfigurere engangspålogging for Webex for mer informasjon om SSO-integrering i nettstedsadministrasjon.)

Integreringstrinnene refererer til Shibboleth 2.4.5 i CentOS 7 med Tomcat 7 som nettserver.

Før du begynner

IdP-er må overholde SAML 2.0-spesifikasjonen for SSO og Control Hub. I tillegg må IdP-er konfigureres på følgende måte:

Last ned Webex-metadataene til ditt lokale system

1

Fra kundevisningen i https://admin.webex.com går du til Administrasjon > Organisasjonsinnstillinger, blar deretter til Autentisering, og slår deretter på innstillingen Engangspålogging for å starte installasjonsveiviseren.

2

Velg sertifikattype for organisasjonen din:

  • Selvsignert av Cisco – Vi anbefaler dette valget. La oss signere sertifikatet slik at du bare trenger å fornye det én gang hvert femte år.
  • Signert av en offentlig sertifiseringsinstans– Sikrere, men du må oppdatere metadataene ofte (med mindre IdP-leverandøren din støtter klareringsankre).

Klareringsankre er offentlige nøkler som fungerer som en myndighet til å bekrefte sertifikatet til en digital signatur. Hvis du vil ha mer informasjon, kan du se dokumentasjonen for IdP.

3

Last ned metadatafilen.

Filnavnet for Webex-metadata er idb-meta--SP.xml.

Konfigurer autorisasjon i Shibboleth-filer

Når du har installert Shibboleth, får du konfigurasjonsfiler med eksempler.

1

Gå til katalogen /opt/shibboleth-idp/conf for å få tilgang til eksempelfilene.

2

Bestem hvilken godkjenningsmetode som skal brukes, for eksempel LDAP-binding til Active Directory.

3

Rediger filen handler.xml på følgende måte:

Fjern kommentar

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

Comment

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

Fyll ut detaljene for Active Directory for å tillate godkjenning. Angi konfigurasjonen til filen login.config.

ShibUserPassAuth { edu.vt.middleware.ldap.jaas.LdapLoginModule påkrevd 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"; };

Konfigurer komponenter fra Shibboleth-tjenesteleverandøren for SAML-påstand

1

Legg til filen du lastet ned fra Webex SP i katalogen /opt/shibboleth-idp/metadata.

2

Rediger filen relying-party.xml ; legg til detaljene for SAML-påstanden for Webex etter DefaultRelyingParty-taggen.

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

For ID må du bruke EntityID-verdien fra Webex-metadatafilen. Erstatt ID-en for eksemplet med EntityID for organisasjonen din.

3

Legg til plasseringen av filen i metadata:MetadataProvider-taggen:

 <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" />  <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" />  <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider"  <!-- Cisco CI-konfigurasjon <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>

SP-metadataene kommer fra en fil i Shibboleth-filsystemet, på stedet der du lastet opp metadataene for Webex-organisasjonen din.

Konfigurere deklarasjonsattributtene

1

I delen Datatilkobling angir du hvor du vil hente attributter om brukerne dine.

Active Directory, med en MyLDAP-ID.

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

2

Behold det som allerede er i konfigurasjonen for transientID i delen Attributtdefinisjon.

3

Legg til det ekstra attributtet som SP forventer, og definer hva det tilordnes til i attributtkilden.

Tilordne attributtposten (e-postadresseattributt i Active Directory) til uid (UserID i Webex).

4

Definer hvilket attributt som skal oppgis til hver SP-avtale i attribute-filter.xml -filen.

Oppgi uid-attributtet til Webex som tilordnes e-postadressen til brukeren.

Frigi attributtet uid til SP-avtalen med Webex.

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

Regelen du opprettet i attribute-resolver.xml skal ha en policy for å frigi attributtet mail-attr til EntityID-en som samsvarer med Webex.

5

Last ned metadatafilen fra Shibboleth-serveren i /opt/shibboleth-idp/metadata. Filnavnet er idp-metadata.xml.

Importer IdP-metadataene og aktiver engangspålogging etter en test

Når du har eksportert Webex-metadataene, konfigurert IdP-en og lastet ned IdP-metadataene til det lokale systemet, er du klar til å importere dem til Webex-organisasjonen din fra Control Hub.

Før du begynner

Ikke test SSO-integrering fra grensesnittet til identitetsleverandøren (IdP). Vi støtter kun tjenesteleverandørinitierte (SP-initierte) flyter, så du må bruke Control Hub SSO-testen for denne integreringen.

1

Velg én:

  • Gå tilbake til siden for Control Hub – sertifikatvalg i nettleseren, og klikk deretter på Neste.
  • Hvis Control Hub ikke lenger er åpen i nettleserfanen, går du til https://admin.webex.comAdministrasjon > Organisasjonsinnstillinger i kundevisningen, blar til Autentisering og velger Handlinger > Importer metadata.
2

Dra og slipp IdP-metadatafilen til siden Importer IdP-metadata, eller bruk filnettleseralternativet til å finne og laste opp metadatafilen. Klikk på Neste.

Du bør bruke alternativet Sikrere hvis du kan. Dette er bare mulig hvis IdP-en din brukte en offentlig sertifiseringsinstans til å signere metadataene.

I alle andre tilfeller må du bruke alternativet Mindre sikkert . Dette inkluderer om metadataene ikke er signert, selvsignert eller signert av en privat sertifiseringsinstans.

Okta signerer ikke metadataene, så du må velge Mindre sikker for en Okta SSO-integrering.

3

Velg Test SSO-oppsett, og når en ny nettleserfane åpnes, godkjenn med IdP-en ved å logge på.

Hvis du får en autentiseringsfeil, kan det oppstå et problem med legitimasjonen. Kontroller brukernavnet og passordet, og prøv på nytt.

En Webex-appfeil betyr vanligvis et problem med SSO-oppsettet. I dette tilfellet går du gjennom trinnene igjen, spesielt trinnene der du kopierer og limer inn Control Hub-metadataene i IdP-oppsettet.

Hvis du vil se SSO-påloggingsopplevelsen direkte, kan du også klikke på Kopier URL til utklippstavle fra dette skjermbildet og lime den inn i et privat nettleservindu. Derfra kan du gå gjennom å logge på med SSO. Dette trinnet stopper falske positiver på grunn av et tilgangstoken som kan være i en eksisterende økt fra at du er logget på.

4

Gå tilbake til nettleserfanen Control Hub.

  • Hvis testen var vellykket, velger du Vellykket test. Slå på SSO og klikk på Neste.
  • Hvis testen mislyktes, velger du Mislykket test. Slå av SSO og klikk på Neste.

SSO-konfigurasjonen trer ikke i kraft i organisasjonen med mindre du velger den første alternativknappen og aktiverer SSO.

Hva du skal gjøre nå

Bruk fremgangsmåtene i Synkroniser Okta-brukere til Cisco Webex Control Hub hvis du vil klargjøre brukere fra Okta til Webex-skyen.

Bruk fremgangsmåtene i Synkronisere Azure Active Directory-brukere til Cisco Webex Control Hub hvis du vil klargjøre brukere fra Azure AD til Webex-skyen.

Du kan følge fremgangsmåten i Undertrykk automatiserte e-poster for å deaktivere e-poster som sendes til nye brukere av Webex-appen i organisasjonen. Dokumentet inneholder også beste praksis for å sende ut kommunikasjon til brukere i organisasjonen.