Logowanie jednokrotne i Control Hub

Logowanie jednokrotne (SSO) to proces uwierzytelniania sesji lub użytkownika, który umożliwia użytkownikowi podanie poświadczeń w celu uzyskania dostępu do co najmniej jednej aplikacji. Proces ten uwierzytelnia użytkowników dla wszystkich aplikacji, do których mają prawa. Eliminuje to dalsze monity, gdy użytkownicy przełączają aplikacje podczas określonej sesji.

Protokół federacyjny SAML 2.0 (Security Assertion Markup Language) służy do uwierzytelniania jednokrotnego między chmurą Webex a dostawcą tożsamości (IdP).

Profile

Aplikacja Webex app obsługuje tylko profil logowania jednokrotnego w przeglądarce internetowej. W profilu logowania jednokrotnego przeglądarki internetowej aplikacja Webex App obsługuje następujące powiązania:

  • Sp zainicjowane powiązanie POST -> POST

  • Sp zainicjowane powiązanie REDIRECT -> POST

Format NameID

Protokół SAML 2.0 obsługuje kilka formatów NameID służących do komunikowania się o określonym użytkowniku. Aplikacja Webex app obsługuje następujące formaty NameID.

  • 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

W metadanych ładowanych od dostawcy tożsamości pierwszy wpis jest skonfigurowany do użycia w Webex.

SingleLogout

Aplikacja Webex obsługuje pojedynczy profil wylogowania. W aplikacji Webexapp użytkownik może wylogować się z aplikacji, która używa protokołu pojedynczego wylogowania SAML do zakończenia sesji i potwierdzenia wylogowania przy użyciu usługodawcy tożsamości. Upewnij się, że twój IdP jest skonfigurowany dla SingleLogout.

Integracja Control Hub z Shibboleth


Przewodniki konfiguracji pokazują konkretny przykład integracji logowania jednokrotnego, ale nie zawierają wyczerpującej konfiguracji dla wszystkich możliwości. Na przykład kroki integracji dla formatu nameid urn:oasis:names:tc:SAML:2.0:nameid-format:transient są udokumentowane. Inne formaty, takie jak urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified lub urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress będą działać w przypadku integracji logowania jednokrotnego, ale wykraczają poza zakres naszej dokumentacji.

Skonfiguruj tę integrację dla użytkowników w organizacji Webex (w tym WebexApp, Webex Meetingsi innych usług administrowanych w ControlHub). Jeśli witryna Webex jest zintegrowana z ControlHub, witryna Webex dziedziczy zarządzanie użytkownikami. Jeśli nie możesz uzyskać dostępu do Webex Meetings w ten sposób i nie jest on zarządzany w Control Hub, musisz wykonać oddzielną integrację, aby włączyć logowanie jednokrotne dla spotkańWebex. (Zobacz Konfigurowanie logowania jednokrotnego dla usługi Webex, aby uzyskać więcej informacji na temat integracji logowania jednokrotnego w administracji witryną.)

Kroki integracji odnoszą się do Shibboleth 2.4.5 w CentOS 7 z Tomcat 7 jako serwerem WWW.

Przed rozpoczęciem

W przypadku logowania jednokrotnego i centrumsterowania dostawcy tożsamości muszą być zgodni ze specyfikacją SAML 2.0. Ponadto dostawcy IdPs muszą być skonfigurowani w następujący sposób:

Pobierz metadane Webex do systemu lokalnego

1

Z widoku klienta w programie https://admin.webex.com, przejdź do pozycji Zarządzanie > Ustawienia organizacji , a następnie przewiń do pozycji Uwierzytelnianie, a następnie włącz ustawienie Logowanie jednokrotne, aby uruchomić kreatora instalacji.

2

Wybierz typ certyfikatu dla swojej organizacji:

  • Podpis własny firmy Cisco— zalecamy ten wybór. Pozwól nam podpisać certyfikat, więc musisz go odnawiać tylko raz na pięć lat.
  • Podpisane przez publiczny urząd certyfikacji— bezpieczniejsze, ale trzeba będzie często aktualizować metadane (chyba że dostawca dostawcy tożsamości obsługuje kotwice zaufania).

 

Kotwice zaufania to klucze publiczne, które działają jako urząd do weryfikacji certyfikatu podpisu cyfrowego. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją usługodawcy internetowego.

3

Pobierz plik metadanych.

Nazwa pliku metadanych Webex to idb-meta-<org-ID>-SP.xml.

Konfigurowanie autoryzacji w plikach Shibboleth

Po zainstalowaniu Shibboleth otrzymasz pliki konfiguracyjne z przykładami.

1

Przejdź do katalogu /opt/shibboleth-idp/conf, aby uzyskać dostęp do przykładowych plików.

2

Zdecyduj, której metody autoryzacji użyć — na przykład powiązania LDAP z usługą Active Directory.

3

Edytuj plik handlera.xml w następujący sposób:

Odkomentuj

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

Komentarz

<ph:LoginHandler xsi:type="ph:RemoteUser"> 
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</ph:AuthenticationMethod>
    </ph:LoginHandler>
4

Wypełnij szczegóły usługi Active Directory, aby umożliwić uwierzytelnianie. Podaj konfigurację do pliku login.config.

Przykład:

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

Konfigurowanie składników dostawcy usług Shibboleth dla asercji SAML

1

Dodaj plik pobrany z Webex SP do katalogu /opt/shibboleth-idp/metadata.

2

Edytuj plik jednostki uzależnionej.xml; po znaczniku DefaultRelyingParty dodaj szczegóły potwierdzenia SAML dla Webex.

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

W przypadku identyfikatora należy użyć wartości EntityID z pliku metadanych Webex. Zastąp identyfikator przykładu identyfikatorem EntityID swojej organizacji.

3

Wewnątrz znacznika metadata:MetadataProvider dodaj lokalizację pliku:

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

Metadane SP pochodzą z pliku w systemie plików Shibboleth, w lokalizacji, w której przesłano metadane dla organizacji Webex.

Konfigurowanie atrybutów potwierdzenia

1

W sekcji Łącznik danych określ, gdzie mają być pobierane atrybuty dotyczące użytkowników.

Przykład:

Active Directory, z identyfikatorem 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

W sekcji Definicja atrybutu zachowaj to, co jest już w konfiguracji dla transientID.

3

Dodaj dodatkowy atrybut, którego oczekuje SP, i zdefiniuj, na co jest mapowany w źródle atrybutów.

Przykład:

Zamapuj atrybut mail (atrybut adresu e-mail w usłudze Active Directory) na uid (UserID w Webex).
<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

Zdefiniuj atrybut, który ma być przypisany do każdej umowy SP w pliku attribute-filter.xml.

Podaj atrybut uid do Webex, który jest mapowany na adres e-mail użytkownika.

Przykład:

Zwolnij atrybut uid do umowy SP z Webex.

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

Reguła utworzona w programie rozpoznawania atrybutów.xml powinna mieć zasady zwalniania atrybutu mail-attr do identyfikatora EntityID zgodnego z Webex.

5

Pobierz plik metadanych z serwera Shibboleth w /opt/shibboleth-idp/metadata. Nazwa pliku to idp-metadata.xml.

Importowanie metadanych dostawcy tożsamości i włączanie logowania jednokrotnego po teście

Po wyeksportowaniu metadanych Webex, skonfigurowaniu dostawcy tożsamości i pobraniu metadanych dostawcy tożsamości do systemu lokalnego można przystąpić do importowania ich do organizacji Webex z centrumsterowania.

Przed rozpoczęciem

Nie testuj integracji logowania jednokrotnego z interfejsu dostawcy tożsamości (IdP). Obsługujemy tylko przepływy inicjowane przez dostawcę usług (inicjowane przez dostawcę usług), więc do tej integracji należy użyć testu logowania jednokrotnego usługi Control Hub.

1

Wybierz jedną z nich:

  • Wróć do strony Control Hub — wybór certyfikatu w przeglądarce, a następnie kliknij przycisk Dalej.
  • Jeśli centrum sterowania nie jest już otwarte na karcie przeglądarki, w widoku klienta w programie przejdź do https://admin.webex.compozycji Zarządzanie > Ustawieniaorganizacji, przewiń do pozycji Uwierzytelnianie, a następnie wybierzpozycję Akcje > importuj metadane.
2

Na stronie Importowanie metadanych dostawcy tożsamości przeciągnij i upuść plik metadanych dostawcy tożsamości na stronę lub użyj opcji przeglądarki plików, aby zlokalizować i przekazać plik metadanych. Kliknij przycisk Dalej.

Jeśli możesz, powinieneś użyć opcji Bardziej bezpieczne. Jest to możliwe tylko wtedy, gdy usługodawca tożsamości podpisał swoje metadane za pomocą publicznego urzędu certyfikacji.

We wszystkich innych przypadkach należy użyć opcji Mniej bezpieczne. Dotyczy to również uchyłek, jeśli metadane nie są podpisane, podpisane samodzielnie lub podpisane przez prywatny urząd certyfikacji.

3

Wybierz pozycję Testuj konfigurację logowaniajednokrotnego, a gdy otworzy się nowa karta przeglądarki, uwierzytelnij się przy użyciu usługodawcy tożsamości, logując się.


 

Jeśli zostanie wyświetlony błąd uwierzytelniania, może to być problem z poświadczeniami. Sprawdź nazwę użytkownika i hasło i spróbuj ponownie.

Błąd aplikacji Webex zwykle oznacza problem z konfiguracją logowania jednokrotnego. W takim przypadku należy ponownie wykonać kroki, zwłaszcza kroki, w których kopiujesz i wklejasz metadane centrum sterowania do konfiguracji dostawcy tożsamości.


 

Aby bezpośrednio wyświetlić logowanie jednokrotne, możesz też kliknąć opcję Kopiuj adres URL do schowka z tego ekranu i wkleić go w prywatnym oknie przeglądarki. Stamtąd możesz przejść przez logowanie się za pomocą logowania jednokrotnego. Ten krok zatrzymuje fałszywe alarmy z powodu tokenu dostępu, który może znajdować się w istniejącej sesji po zalogowaniu.

4

Wróć do karty przeglądarki Control Hub.

  • Jeśli test zakończył się pomyślnie, wybierz opcję Test pomyślny. Włącz logowanie jednokrotne i kliknij przycisk Dalej .
  • Jeśli test zakończył się niepowodzeniem, wybierz opcję Test nieudany. Wyłącz logowanie jednokrotne i kliknij przycisk Dalej .

 

Konfiguracja logowania jednokrotnego nie zostanie zrealizowana w organizacji, chyba że wybierzesz pierwszy przycisk radiowy i aktywujesz logowanie jednokrotne.

Co dalej?

Możesz wykonać procedurę opisaną w temacie Pomijanie automatycznych wiadomości e-mail, aby wyłączyć wiadomości e-mail wysyłane do nowych użytkowników aplikacji Webex App w organizacji. Dokument zawiera również najważniejsze wskazówki dotyczące wysyłania wiadomości do użytkowników w organizacji.