Een single sign-on en Control Hub

Eenmalige aanmelding (SSO) is een sessie- of gebruikersverificatieproces waarbij een gebruiker aanmeldgegevens kan verstrekken om toegang te krijgen tot een of meer toepassingen. Het proces verifieert gebruikers voor alle toepassingen waarvoor ze rechten hebben gekregen. Gebruikers krijgen geen prompts meer te zien wanneer ze tijdens een bepaalde sessie tussen toepassingen schakelen.

Het Security Assertion Markup Language (SAML 2.0)-federatieprotocol wordt gebruikt voor SSO-verificatie tussen de Webex-cloud en uw identiteitsprovider (IdP).

Profielen

De Webex-app ondersteunt alleen de webbrowser SSO profiel. In het profiel van de SSO webbrowser ondersteunt de Webex-app de volgende bindingen:

  • SP-gestarte POST -> POST-binding

  • SP-gestarte OMLEIDING -> POST-binding

Indeling naam-ID

Het SAML 2.0-protocol ondersteunt verschillende NameID-indelingen voor communicatie over een specifieke gebruiker. De Webex-app ondersteunt de volgende NameID-indelingen.

  • 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

In de metagegevens die u vanuit uw IdP laadt, wordt de eerste invoer geconfigureerd voor gebruik in Webex.

Eenmalige afmelding

De Webex-app ondersteunt het profiel van een enkele aanmelding. In de Webex-appkan een gebruiker zich afloggen bij de toepassing, die gebruikmaakt van het SAML-protocol voor eenmalig aanmelden om de sessie te beëindigen en om het af te melden met uw IdP. Zorg ervoor dat uw identiteitsprovider is geconfigureerd voor eenmalige afmelding.

Control Hub integreren met Shibboleth

De configuratiehandleidingen geven een specifiek voorbeeld van SSO-integratie weer, maar bieden geen volledige configuratie voor alle mogelijkheden. De integratiestappen voor nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient worden bijvoorbeeld gedocumenteerd. Andere indelingen als urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified of urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress ondersteunen SSO-integratie, maar vallen buiten het bereik van onze documentatie.

Stel deze integratie in voor gebruikers in uw Webex-organisatie ( inclusief Webex-app , Webex Meetingsen andere services die in Control Hub worden beheerd). Als uw Webex-site is geïntegreerd in Control Hub, neemt de Webex-site het gebruikersbeheer over. Als u op deze manier geen toegang hebt tot Webex Meetings en deze niet wordt beheerd in Control Hub, moet u een afzonderlijke integratie doen om toegang SSO voor gebruikers Webex Meetings. (Raadpleeg Eenmalige aanmelding configureren voor Webex voor meer informatie over SSO-integratie in Sitebeheer.)

De integratiestappen verwijzen naar Shibboleth 2.4.5 in CentOS 7 met Tomcat 7 als de webserver.

Voordat u begint

Voor SSO en Control Hub moeten IdP's voldoen aan de SAML 2.0-specificatie. Daarnaast moeten IdP's op de volgende manier worden geconfigureerd:

Download de Webex-metagegevens naar uw lokale systeem

1

Ga vanuit de klantweergave in https://admin.webex.com naar Beheer > -organisatie-instellingen , scrol vervolgens naar Verificatie en schakel in met de instelling Voor eenmalig aanmelden om de installatiewizard te starten.

2

Kies het certificaattype voor uw organisatie:

  • Zelfondertekend door Cisco: we raden deze keuze aan. Laat ons het certificaat ondertekenen zodat u het slechts eens per vijf jaar hoeft te vernieuwen.
  • Ondertekend door een openbare certificeringsinstantie: dit is veiliger, maar u moet de metagegevens vaak bijwerken (tenzij uw IdP-leverancier vertrouwensankers ondersteunt).

Vertrouwensankers zijn openbare sleutels die optreden als bevoegdheid om het certificaat van een digitale handtekening te verifiëren. Raadpleeg de IdP-documentatie voor meer informatie.

3

Download het bestand met metagegevens.

De bestandsnaam van de Webex-metagegevens is idb-meta--SP.xml.

Autorisatie in Shibboleth-bestanden configureren

Nadat u Shibboleth hebt geïnstalleerd, worden configuratiebestanden met voorbeelden geleverd.

1

Ga naar de directory /opt/shibboleth-idp/conf om toegang te krijgen tot de voorbeeldbestanden.

2

Bepaal welke autorisatiemethode moet worden gebruikt, bijvoorbeeld LDAP-binding aan Active Directory.

3

Bewerk het bestand handler.xml als volgt:

Uncomment

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

Opmerking

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

Vul de gegevens van uw e-Active Directory in om de verificatie toe te staan. Geef de configuratie voor het bestand login.config op.

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 serviceprovidercomponenten configureren voor SAML-bevestiging

1

Voeg het bestand dat u van de Webex SP hebt gedownload toe aan de directory /opt/shibboleth-idp/metadata.

2

Bewerk het bestand relying-party.xml ; voeg na de tag DefaultRelyingParty de details van de SAML-verklaring voor Webex toe.

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

Voor id moet u de EntityID-waarde uit het Webex-metagegevensbestand gebruiken. Vervang de id van het voorbeeld door de EntityID van uw organisatie.

3

Voeg de locatie van het bestand toe in de metadata:MetadataProvider-tag:

 <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="FilesystemMetadataProvider" xmlns="/opt/shibboleth-idp/metad ata/ucxn9a-single-agreement.xml" />  <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m ace:shibboleth-idp/metad ata/cucm  <!-- Cisco CI-configuratie <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>

De SP-metagegevens zijn afkomstig van een bestand in het Shibboleth-bestandssysteem, op de locatie waar u de metagegevens voor uw Webex-organisatie hebt geüpload .

De assertykenmerken configureren

1

Geef in het gedeelte Gegevensconnector op waar de kenmerken van uw gebruikers moeten worden opgehaald.

Active Directory, met een id van MyLDAP.

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

2

Bewaar in het gedeelte Kenmerkdefinitie wat er al in de configuratie voor de tijdelijkeID staat.

3

Voeg het extra kenmerk toe dat de SP verwacht en definieer wat het toevoegt aan in de kenmerkbron.

Wijs het kenmerk mail (kenmerk e-mailadres in Active Directory) toe aan uid (UserID in Webex).

4

Definieer welk kenmerk moet worden gebruikt voor elke SP-overeenkomst in het bestand attribute-filter.xml .

Geef het uid-kenmerk aan Webex op dat wordt verbonden met het e-mailadres van de gebruiker.

Het kenmerk uid vrijgeven in de SP-overeenkomst met 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>

De regel die u hebt gemaakt in attribute-resolver.xml moet een beleid hebben om het kenmerk mail-attr vrij te geven aan de entiteits-id die overeenkomt met Webex.

5

Download het bestand met metagegevens van de Shibboleth-server in /opt/shibboleth-idp/metadata. De bestandsnaam is idp-metadata.xml.

Importeer de IdP-metagegevens en schakel eenmalige aanmelding na een test in

Nadat u de Webex-metagegevens hebt geëxporteerd, uw IdP hebt geconfigureerd en de IdP-metagegevens naar uw lokale systeem hebt gedownload, bent u klaar om deze vanuit Control Hub in uw Webex-organisatie te importeren.

Voordat u begint

Test de SSO-integratie niet vanuit de interface van de identiteitsprovider (IdP). We ondersteunen alleen door serviceprovider geïnitieerde overdrachts stromen, dus u moet de Control hub gebruiken SSO test voor deze integratie.

1

Kies een van de opties:

  • Keer terug naar de pagina Control Hub - certificaatselectie in uw browser en klik op Volgende.
  • Als Control Hub niet meer op het browsertabblad is geopend, gaat u vanuit de klantweergave in https://admin.webex.com naar Beheer > Organisatie-instellingen, bladert u naar Verificatie en kiest u Acties > Metagegevens importeren.
2

Sleep op de pagina Metagegevens van de identiteitsprovider importeren het metagegevensbestand van de identiteitsprovider naar de pagina of gebruik de bestandsbrowser om het metagegevensbestand te zoeken en te uploaden. Klik op Volgende.

Gebruik de optie Veiliger , als dat mogelijk is. Dit is alleen mogelijk als uw IdP een openbare ca heeft gebruikt om de metagegevens te ondertekenen.

In alle andere gevallen moet u de optie Minder veilig gebruiken. Dit geldt ook als de metagegevens niet zijn ondertekend, zelfonder ondertekend of zijn ondertekend door een privé-CA.

Okta ondertekent de metagegevens niet. Daarom moet u Minder veilig kiezen voor een Okta SSO integratie.

3

Selecteer SSO-instelling testen en als er een nieuw browsertabblad wordt geopend, verifieert u zich met de identiteitsprovider door u aan te melden.

Als u een verificatiefout ontvangt, is er mogelijk een probleem met de aanmeldgegevens. Controleer de gebruikersnaam en het wachtwoord en probeer het opnieuw.

Een Fout in Webex-app betekent meestal een probleem met de SSO installatie. In dit geval moet u de stappen opnieuw doorlopen, met name de stappen waarbij u de Control Hub-metagegevens kopieert en plakt in de configuratie van de identiteitsprovider.

Als u de SSO-aanmeldingservaring rechtstreeks wilt bekijken, kunt u ook klikken op URL naar klembord kopiëren vanuit dit scherm en deze in het venster van een privébrowser plakken. Vanaf daar kunt u het aanmelden met SSO doorlopen. Deze stap stopt met false positives vanwege een toegangs token die mogelijk in een bestaande sessie is van uw aangemelde.

4

Keer terug naar het Control Hub-browsertabblad.

  • Als de test is geslaagd, selecteert u Succesvolle test. Schakel de SSO en klik op Volgende.
  • Selecteer Mislukte test als de test is mislukt. Schakel de SSO en klik op Volgende.

De SSO configuratie wordt niet van kracht in uw organisatie, tenzij u eerst keuzerondje activeren en activeren SSO.

De volgende stap

Gebruik de procedures in Okta-gebruikers synchroniseren Cisco Webex Control Hub als u gebruikers provisioning uit Okta in de Webex-cloud wilt uitvoeren.

Gebruik de procedures in Azure Active Directory synchroniseren in Cisco Webex Control Hub als u gebruikers provisioning uit Azure AD wilt uitvoeren in de Webex-cloud.

U kunt de procedure volgen in Geautomatiseerde e-mails onderdrukken om e-mails uit te schakelen die naar nieuwe gebruikers van de Webex-app in uw organisatie worden verzonden. Het document bevat ook aanbevolen procedures voor het verzenden van communicatie naar gebruikers in uw organisatie.