Einmaliges Anmelden 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) verwendet.

Profile

Die Webex -App unterstützt nur das SSO -Profil des Webbrowsers. Im SSO -Profil des Webbrowsers unterstützt die 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 Einzelabmeldungsprofil. In der Webex-App kann sich ein Benutzer von der Anwendung abmelden. Dabei wird zum Beenden der Sitzung und zum Bestätigen der Abmeldung bei Ihrem IdP das SAML-Einzelabmeldungsprotokoll verwendet. Stellen Sie sicher, dass Ihr IdP für SingleLogout konfiguriert ist.

Control Hub mit Shibboleth integrieren


 

Die Konfigurationsanweisungen zeigen ein konkretes Beispiel einer SSO-Integration, aber keine umfassende Konfiguration für alle Möglichkeiten. Zum Beispiel sind 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 or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress funktionieren für die SSO-Integration, werden jedoch nicht in unserer Dokumentation behandelt.

Richten Sie diese Integration für Benutzer in Ihrer Webex Organisation ein (einschließlich Webex App, Webex Meetings und andere Dienste, die in Control Hub verwaltet werden). Wenn Ihre Webex-Seite in Control Hub integriert ist, erbt die Webex-Seite die Benutzerverwaltung. Wenn Sie auf diese Weise nicht auf Webex Meetings zugreifen können und Webex Meetings nicht in Control Hub verwaltet wird, müssen Sie eine separate Integration vornehmen, um SSO für Webex Meetings zu aktivieren. (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:

Laden Sie die Webex -Metadaten auf Ihr lokales System herunter

1

Aus der Kundenansicht inhttps://admin.webex.com , gehen Sie zu Verwaltung > Organisationseinstellungen und blättern Sie zu Authentifizierung , und aktivieren Sie dann das Einmaliges Anmelden , um den Einrichtungsassistenten zu Wizard.

2

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

  • Selbstsigniert von Cisco – Wir empfehlen diese Auswahl. Lassen Sie das Zertifikat von uns signieren, 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 Vertrauensanker).

 

Vertrauensanker sind öffentliche Schlüssel, die als Zertifizierungsstelle zum Überprüfen des Zertifikats einer digitalen Signatur fungieren. Weitere Informationen finden Sie in der Dokumentation Ihres Identitätsanbieters.

3

Laden Sie die Metadatendatei herunter.

Der Name der Webex Metadatendatei lautet idb-meta-<org-ID> -SP.xml .

Autorisierung in Shibboleth-Dateien konfigurieren

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

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

Kommentar

<ph:LoginHandler xsi:type="ph:RemoteUser"> 
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</ph:AuthenticationMethod>
    </ph:LoginHandler>
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 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";
};

Konfigurieren von Shibboleth-Dienstanbieterkomponenten für SAML-Assertion

1

Fügen Sie die Datei, die Sie vom Webex SP heruntergeladen haben, in das Verzeichnis /opt/shibboleth-idp/metadata hinzu.

2

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

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

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

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

Konfigurieren der Assertionsattribute

1

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

Active Directory, mit der id MyLDAP.

<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

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-Adressattribut in Active Directory) der uid (UserID in Webex) zu.

<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

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

Geben Sie das uid-Attribut an Webex an, das der E-Mail-Adresse des Benutzers zugeordnet ist.

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

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

Die Regel, die Sie in attribute-resolver.xml erstellt haben, sollte eine Richtlinie enthalten, um das mail-attr-Attribut in der EntityID freizugeben, das mit Webex übereinstimmt.

5

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

Importieren Sie die IdP-Metadaten und aktivieren Sie Einzelanmeldung-On 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. Jetzt können Sie sie aus dem Control Hub in Ihre Webex -Organisation importieren.

Vorbereitungen

Testen Sie die SSO-Integration nicht über die Benutzeroberfläche des Identitätsanbieters (IdP). Es werden nur vom Dienstleister initiierte (SP-initiierte) Vorgänge unterstützt, daher müssen Sie den SSO-Test im Control Hub für diese Integration verwenden.

1

Wählen Sie eine Option:

  • Kehren Sie in Ihrem Browser zur Seite „Control Hub – Zertifikatsauswahl“ zurück und klicken Sie dann auf Weiter .
  • Wenn Control Hub nicht mehr in der Browser-Registerkarte geöffnet ist, über die Kundenansicht inhttps://admin.webex.com , gehen Sie zu Verwaltung > Organisationseinstellungen , blättern Sie zu Authentifizierung , und wählen Sie dann Aktionen > Metadaten importieren .
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 den Mehr Sicherheit Option, wenn Sie können. Dies ist nur möglich, wenn Ihr IdP eine öffentliche CA zum Signieren seiner Metadaten verwendet hat.

In allen anderen Fällen müssen Sie den Weniger sicher ein. Dazu gehört auch, ob die Metadaten nicht signiert, selbstsigniert oder von einer privaten Zertifizierungsstelle signiert sind.


 

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

3

Auswählen SSO -Einrichtung testen , und wenn eine neue Browser-Registerkarte geöffnet wird, authentifizieren Sie sich beim IdP, indem Sie sich anmelden.


 

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 Webex -App-Fehler weist normalerweise auf ein Problem mit der SSO -Einrichtung hin. 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. Durch diesen Schritt werden False-Positives aufgrund eines Zugriffstokens verhindert, das möglicherweise in einer vorhandenen Sitzung von Ihrer Anmeldung enthalten ist.

4

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

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

 

Die SSO -Konfiguration wird in Ihrer Organisation erst wirksam, wenn Sie die erste Optionsfeld auswählen und SSO aktivieren.

Nächste Schritte

Verwenden Sie die Verfahren in Okta-Benutzer mit Cisco Webex Control Hub synchronisieren wenn Sie die Benutzerbereitstellung aus Okta heraus in der Webex Cloud durchführen möchten.

Verwenden Sie die Verfahren in Synchronisieren Sie Azure Active Directory -Benutzer in Cisco Webex Control Hub wenn Sie die Benutzerbereitstellung aus Azure AD heraus in der Webex Cloud durchführen möchten.

Sie können das Verfahren in Automatisierte E-Mails unterdrücken um E-Mails zu deaktivieren, die an neue Webex App-Benutzer in Ihrer Organisation gesendet werden. Das Dokument enthält außerdem bewährte Methoden zum Senden von Mitteilungen an Benutzer in Ihrer Organisation.