Einmalige Anmeldung und Control Hub

Die einmalige Anmeldung ist ein Sitzungs- oder Benutzerauthentifizierungsvorgang, bei dem ein Benutzer für den Zugriff auf eine oder mehrere Anwendungen Anmeldeinformationen angeben kann. Bei dem Vorgang werden Benutzer für alle Anwendungen authentifiziert, für die sie über Berechtigungen verfügen. Dadurch werden weitere Eingabeaufforderungen vermieden, wenn Benutzer während einer bestimmten Sitzung zwischen Anwendungen wechseln.

Das Security Assertion Markup Language (SAML 2.0) Federation-Protokoll wird für die SSO-Authentifizierung zwischen der Webex-Cloud und Ihrem Identitätsanbieter (IdP) eingesetzt.

Profile

Die Webex-App unterstützt nur den Webbrowser SSO Profil. Im Webbrowser- und SSO unterstützt Webex App die folgenden Bindungen:

  • SP initiierte POST -> POST-Bindung

  • SP initiierte REDIRECT -> POST-Bindung

NameID Format

Das SAML 2.0-Protokoll unterstützt mehrere NameID-Formate für die Kommunikation über einen bestimmten Benutzer. Die Webex-App unterstützt die folgenden NameID-Formate.

  • 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 den von Ihrem IdP geladenen Metadaten ist der erste Eintrag für die Verwendung in Webex konfiguriert.

SingleLogout

Die Webex-App unterstützt das Einzel-Abmeldeprofil. In der Webex-Appkann sich ein Benutzer von der Anwendung abmelden, die zum Beenden der Sitzung und zum Bestätigen der Abmeldedatei bei Ihrem IdP das SAML-Einzel-Abmeldeprotokoll verwendet. Stellen Sie sicher, dass Ihr IdP für SingleLogout konfiguriert ist.

Integrieren von Control Hub in Shibboleth

Die Konfigurationsanweisungen zeigen ein konkretes Beispiel einer SSO-Integration, aber keine umfassende Konfiguration für alle Möglichkeiten. So sind beispielsweise die Integrationsschritte für nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient dokumentiert. Andere Formate wie urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified oder urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress sind für die SSO-Integration geeignet, aber nicht in der Dokumentation enthalten.

Richten Sie diese Integration für Benutzer in Ihrer Webex-Organisation ein (einschließlich webex App, Webex Meetingsund andere Dienste, die im Control Hub verwaltet werden). Wenn Ihre Webex-Site in Control Hubintegriert ist, erbt die Webex-Site die Benutzerverwaltung. Wenn Sie auf diese Weise nicht auf Webex Meetings zugreifen können und dies nicht in Control Hubverwaltet wird, müssen Sie eine separate Integration tun, um SSO-Benutzer Webex Meetings . (Weitere Informationen über die SSO-Integration in der Site-Administration finden Sie unter Configure Single Sign-On for Webex[Konfigurieren von Single Sign-On für Cisco WebEx Site].)

Die Integrationsschritte beziehen sich auf Shibboleth 2.4.5 in CentOS 7 mit Tomcat 7 als Webserver.

Vorbereitungen

Für SSO und Control Hub müssen die IdPs der SAML 2.0-Spezifikation entsprechen. Außerdem müssen die IdPs folgendermaßen konfiguriert werden:

Herunterladen der Webex-Metadaten auf Ihr lokales System

1

Wechseln Sie aus der Kundenansicht in https://admin.webex.com zu Management > Organisationseinstellungen, scrollen Sie zu Authentifizierung und aktivieren Sie die Einstellung Einmalige Anmeldung, um den Einrichtungsassistenten zu starten.

2

Wählen Sie den Zertifikattyp für Ihre Organisation aus:

  • Selbstsigniert von Cisco – Diese Auswahl wird empfohlen. Unterzeichnen Sie das Zertifikat, damit Sie es nur alle fünf Jahre erneuern müssen.
  • Signiert von einer öffentlichen Zertifizierungsstelle – Sicherer, aber Sie müssen die Metadaten häufig aktualisieren (es sei denn, Ihr Identitätsanbieter unterstützt Anchors für Vertrauensstellung).

Vertrauensanker sind öffentliche Schlüssel, die als Berechtigung fungieren, das Zertifikat einer digitalen Signatur zu überprüfen. Weitere Informationen finden Sie in Ihrer IdP-Dokumentation.

3

Laden Sie die Metadatendatei herunter.

Der Name der Webex-Metadatendatei lautet idb-meta--SP.xml.

Konfigurieren der Autorisierung in Shibboleth-Dateien

Nach der Installation von Shibboleth erhalten Sie die Konfigurationsdateien mit Beispielen.

1

Navigieren Sie zu dem Verzeichnis /opt/shibboleth-idp/conf, um auf die Beispieldateien zuzugreifen.

2

Entscheiden Sie sich für eine Autorisierungsmethode – beispielsweise LDAP-Bindung mit Active Directory.

3

Ändern Sie die handler.xml-Datei wie folgt:

Kommentierung aufheben

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

Kommentar

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

Tragen Sie die Details zu Ihrem Active Directory für die Authentifizierung ein. Geben Sie die Konfiguration in der Datei login.config an.

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

Konfiguration von Shibboleth-Dienstanbieterkomponenten für die SAML-Assertion

1

Fügen Sie die aus dem Webex SP heruntergeladene Datei zum Verzeichnis /opt/shibboleth-idp/metadata hinzu.

2

Bearbeiten Sie die Datei relying-party.xml , und fügen Sie die Details der SAML-Assertion für Webex nach dem DefaultRelyingParty-Tag hinzu.

 <rp:RelyingParty id="https://idbroker.webex.com/ea7c1420-711d-4916-95f8- 22de53230d1e" Anbieter="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"/>

Für "id" müssen Sie den EntityID-Wert aus der Webex-Metadatendatei verwenden. Ersetzen Sie die ID des Beispiels durch die EntityID Ihrer Organisation.

3

Fügen Sie innerhalb des metadata:MetadataProvider-Tag den Speicherort der Datei hinzu:

 <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" xmlns  <!-- Cisco CI-Konfiguration <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>

Die SP-Metadaten stammen aus einer Datei im Shibboleth-Dateisystem, aus dem Speicherort, aus dem Sie die Metadaten für Ihre Webex-Organisation hochgeladen haben.

Assertionsattribute konfigurieren

1

Geben Sie im Datenconnector-Bereich an, wo die Attribute über Ihre Benutzer abgerufen werden sollen.

Active Directory, mit der id MyLDAP.

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

2

Behalten Sie im Bereich Attributdefinition den bereits in der Konfiguration vorhandenen Wert für transientID bei.

3

Fügen Sie das zusätzliche Attribut hinzu, das der SP erwartet und definieren Sie die Zuordnung in der Attributquelle.

Ordnen Sie das Attribut mail (E-Mail-Adressen-Attribut in Active Directory) der uid (UserID in Webex) zu.

4

Definieren Sie das Attribut, das bei den einzelnen SP-Vereinbarungen in der attribute-filter.xml-Datei angegeben werden soll.

Geben Sie in Webex das uid-Attribut an , das der E-Mail-Adresse des Benutzers zu ordnet.

Geben Sie das uid-Attribut mit Webex in der SP-Vereinbarung frei.

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

Die in attribute-resolver.xml erstellte Regel sollte über eine Richtlinie verfügen, damit das mail-attr-Attribut in der EntityID freigegeben wird, die mit Webex übereinstimmt.

5

Laden Sie die Metadatendatei vom Shibboleth-Server in /opt/shibboleth-idp/metadata herunter. Der Dateiname lautet idp-metadata.xml.

Importieren der IdP-Metadaten und Aktivieren einmaliges Anmelden nach einem Test

Nachdem Sie die Webex-Metadaten exportiert haben, konfigurieren Sie Ihren IdP und laden Sie die IdP-Metadaten auf Ihr lokales System herunter, nun können Sie sie aus Control Hub in Ihre Webex-Organisation importieren.

Vorbereitungen

Testen Sie die SSO-Integration nicht über die Benutzeroberfläche des Identitätsanbieters (IdP). Wir unterstützen nur Dienstleister initiierten (mit SP initiierten) strömen, daher müssen Sie den Control Hub SSO Test für diese Integration verwenden.

1

Wählen Sie eine Option:

  • Kehren Sie zur Control Hub – Zertifikatsauswahlseite in Ihrem Browser zurück und klicken Sie auf Weiter.
  • Wenn Control Hub nicht mehr in der Browser-Registerkarte geöffnet ist, wechseln Sie aus der Kundenansicht in https://admin.webex.com zu Verwaltung > Organisationseinstellungen, blättern Sie zu Authentifizierung und wählen Sie Aktionen > Metadaten importieren aus.
2

Ziehen Sie die idP-Metadatendatei auf der Idp-Metadatenimportseite entweder per Drag & Drop auf die Seite oder verwenden Sie den Dateibrowser, um zur Metadatendatei zu navigieren und sie hochzuladen. Klicken Sie auf Weiter.

Sie sollten die Option "Sicherer" verwenden , wenn dies möglich ist. Dies ist nur möglich, wenn Ihr IdP zum Signieren seiner Metadaten eine öffentliche Zertifizierungsstelle verwendet hat.

In allen anderen Fällen müssen Sie die Option Weniger sicher verwenden. Dies beinhaltet, wenn die Metadaten nicht signiert, selbstsignierte oder von einer privaten Zertifizierungsstelle signiert sind.

Okta signieren die Metadaten nicht. Sie müssen daher für eine Okta-Integration Weniger sicher SSO auswählen.

3

Wählen Sie SSO-Einrichtung testen aus und authentifizieren Sie sich in dem neu geöffneten Browserfenster durch Anmeldung beim IdP.

Wenn Sie einen Authentifizierungsfehler erhalten, kann es ein Problem mit den Anmeldeinformationen geben. Überprüfen Sie Nutzernamen und Passwort und versuchen Sie es erneut.

Ein Fehler in der Webex-App bedeutet in der Regel ein Problem mit der SSO Einrichtung. Gehen Sie in diesem Fall erneut die Schritte durch, insbesondere die Schritte, in denen Sie die Cisco Control Hub-Metadaten kopieren und in die IdP-Einrichtung einfügen.

Um die SSO-Anmeldung direkt anzuzeigen, können Sie auch auf URL in die Zwischenablage kopieren von diesem Bildschirm aus klicken und in ein privates Browserfenster einfügen. Von dort aus können Sie sich mit SSO anmelden. Bei diesem Schritt werden die falschen Positives aufgrund eines Zugriffstokens, das sich möglicherweise in einer bestehenden Sitzung von Ihrer angemeldeten Sitzung bewegt, beendet.

4

Kehren Sie zur Registerkarte Control Hub im Browser zurück.

  • Wenn der Test erfolgreich war, wählen Sie Erfolgreicher Test aus. Aktivieren Sie SSO , und klicken Sie auf Weiter.
  • Wenn der Test nicht erfolgreich war, wählen Sie Nicht erfolgreich aus. Deaktivieren Sie SSO , und klicken Sie auf Weiter.

Die SSO-Konfiguration wird in Ihrer Organisation erst wirksam, wenn Sie die erste Option Optionsschaltfläche wählen und diese SSO.

Nächste Schritte

Verwenden Sie die Verfahren zum Synchronisieren von Okta-Benutzern in Cisco Webex Control Hub, wenn Sie die Benutzerbereitstellung über Okta in der Webex-Cloud tun möchten.

Verwenden Sie die Verfahren zum Synchronisieren von Azure Active Directory-Benutzern in Cisco Webex Control Hub , wenn Sie die Benutzerbereitstellung von Azure AD in der Webex-Cloud tun möchten.

Anhand des Verfahrens unter Automatische E-Mails unterdrücken können Sie E-Mails deaktivieren, die an neue Benutzer der Webex-App in Ihrer Organisation gesendet werden. Das Dokument enthält außerdem bewährte Methoden zum Senden von Mitteilungen an Benutzer in Ihrer Organisation.