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 Hubmü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.comzu 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:

  • Selbstsigniertes von Cisco –Diese Option ist empfehlenswert. Unterzeichnen Sie das Zertifikat, damit Sie es nur alle fünf Jahre erneuern müssen.
  • Von einer öffentlichen Zertifizierungsstelle signiert– Sicherer, aber Sie müssen häufig die Metadaten aktualisieren (sofern Ihr IdP-Anbieter keine Vertrauensanker unterstützt).

 

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 ist idb-meta-<org-ID>-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

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

Beispiel:

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";
};

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"
              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, aus dem Speicherort, aus dem Sie die Metadaten für Ihre Webex-Organisation hochgeladen haben.

Assertionsattribute konfigurieren

1

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

Beispiel:

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.

Beispiel:

Ordnen Sie das Attribut mail (E-Mail-Adressen-Attribut 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 in Webex das uid-Attribut an , das der E-Mail-Adresse des Benutzers zu ordnet.

Beispiel:

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 in attribute-resolver.xml erstellte Regel sollte eine Richtlinie haben, damit das mail-attr-Attribut in der EntityID veröffentlicht wird, das mit Webex in Übereinstimmung ist.
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-Organisationimportieren.

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 Control Hub zurück – Zertifikatsauswahlseite und klicken Sie auf Weiter.
  • Wenn Control Hub in der Browserregisterkarte nicht mehr geöffnet ist, wechseln Sie aus der Kundenansicht in https://admin.webex.com zu Management > Organisationseinstellungen, scrollen Sie zu Authentifizierung und wählen Sie Aktionen > Metadatenimportieren.
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.
3

Wählen Sie SSO Browser-Einrichtungtesten aus und authentifizieren Sie sich beim IdP, wenn sich eine neue Browser-Registerkarte öffnet.


 

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 den anmeldebasierten SSO können Sie von diesem Bildschirm aus auch auf URL in Zwischenablage kopieren klicken und ihn in ein privates Browserfenster einfügen. Von dort aus können Sie sich mit Ihrem Neuen SSO. 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

Sie können das Verfahren in Automatische E-Mails unterdrücken befolgen , 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.