Tek oturum açma ve Control Hub

Çoklu oturum açma (SSO), kullanıcının bir veya daha fazla uygulamaya erişmek için kimlik bilgileri sağlamasına izin veren bir oturum veya kullanıcı kimlik doğrulama işlemidir. Bu işlem, kullanıcılara yetkileri olan tüm uygulamalar için kimlik doğrulaması yapar. Kullanıcılar belirli bir oturum sırasında başka bir uygulamaya geçtiğinde istemlerle karşılaşmaz.

Güvenlik Onayı İşaretleme Dili (SAML 2.0) Federasyon Protokolü, Webex bulutu ile kimlik sağlayıcı (IdP) arasında SSO kimlik doğrulaması sağlamak için kullanılır.

Profil

Webex Uygulaması yalnızca web tarayıcısı SSO profilini destekler. Web tarayıcısı SSO profilinde Webex App aşağıdaki bağlamaları destekler:

  • Hizmet Sağlayıcısı tarafından başlatılan POST -> POST bağlama

  • Hizmet Sağlayıcısı tarafından başlatılan REDIRECT -> POST bağlama

Ad Kimliği biçimi

SAML 2.0 Protokolü, belirli bir kullanıcı hakkında iletişim kurmak için çeşitli NameID formatlarını destekler. Webex Uygulaması, aşağıdaki Ad Kimliği biçimlerini destekler.

  • 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

IdP'nizden yüklediğiniz meta verilerde, ilk giriş Webex kullanılmak üzere yapılandırılır.

Çoklu Oturum Kapatma

Webex Uygulaması, çoklu oturum kapatma profilini destekler. Webex Uygulamasında, bir kullanıcı uygulamada oturumu kapatabilir. Bunun için oturumu sonlandırmak ve IdP’nizle oturumu kapatmayı onaylamak için SAML çoklu oturum kapatma protokolü kullanılır. IdP'nizin Çoklu Oturum Kapatma için yapılandırıldığından emin olun.

Control Hub'ı Shibboleth ile Entegre Edin


 

Yapılandırma kılavuzları, SSO entegrasyonu için belirli bir örnek gösterir ancak tüm olasılıklar için kapsamlı yapılandırma sağlamaz. Örneğin, nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient için entegrasyon adımları nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient belgelendirilmiştir. urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified ve urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress gibi diğer biçimler, urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress SSO entegrasyonu için kullanılabilir ancak belgelerimiz kapsamında yer verilmemiştir.

Webex kuruluşunuzdaki kullanıcılar için bu entegrasyonu ayarlayın ( Webex Uygulaması, Webex Meetings ve Control Hub'da yönetilen diğer hizmetler dahil). Webex siteniz Control Hub'a entegre edilmişse Webex sitesi , kullanıcı yönetimini devralır. Webex Meetings bu şekilde erişemiyorsanız ve Control Hub'da yönetilmiyorsa, Webex Meetings için SSO etkinleştirmek için ayrı bir entegrasyon yapmanız gerekir. (Site Yönetiminde SSO entegrasyonu hakkında daha fazla bilgi edinmek amacıyla Webex İçin Çoklu Oturum Açmayı Yapılandırma bölümüne bakın.)

Entegrasyon adımları, web sunucusu olarak Tomcat 7 ile CentOS 7'deki Shibboleth 2.4.5'i ifade eder.

Başlamadan önce

SSO ve Control Hub için, IdP’lerin SAML 2.0 spesifikasyonuna uyması gerekir. Ek olarak, IdP’ler aşağıdaki şekilde yapılandırılmalıdır:

Webex meta verilerini yerel sisteminize indirin

1

Müşteri görünümündenhttps://admin.webex.com , git Yönetim > Organizasyon Ayarları öğesine gidin ve ardından kimlik doğrulama ve ardından Tek oturum açma Kurulum sihirbazını başlatmak için ayar.

2

Kuruluşunuz için sertifika türünü seçin:

  • Cisco tarafından kendinden imzalı —Bu seçimi öneriyoruz. Sertifikayı biz imzalayalım, böylece her beş yılda bir yenilemeniz yeterli.
  • Genel bir sertifika yetkilisi tarafından imzalanmış —Daha güvenlidir ancak meta verileri sık sık güncellemeniz gerekir (IdP satıcınız güven bağlantılarını desteklemediği sürece).

 

Güven çapaları, bir dijital imzanın sertifikasını doğrulamak için bir otorite görevi gören ortak anahtarlardır. Daha fazla bilgi için IDP belgelerinize bakın.

3

Meta veri dosyasını indirin.

Webex meta veri dosya adı: idb-meta-<org-ID> -SP.xml .

Shibboleth dosyalarında yetkilendirmeyi yapılandırName

Shibboleth'i yükledikten sonra, size örneklerle yapılandırma dosyaları sağlanır.

1

Örnek dosyalara erişmek için /opt/shibboleth-idp/conf dizinine gidin.

2

Hangi yetkilendirme yönteminin kullanılacağına karar verin—örneğin, LDAP Active Directory'ye bağlanır.

3

handler.xml dosyasını aşağıdaki gibi düzenleyin:

Yorumu Kaldır

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

Yorum

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

Kimlik doğrulamasına izin vermek için Active Directory ayrıntılarını doldurun. login.config dosyasına yapılandırmayı sağlayın.

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

SAML onayı için Shibboleth hizmet sağlayıcı bileşenlerini yapılandırma

1

Webex SP’den indirdiğiniz dosyayı /opt/shibboleth-idp/meta data dizinine ekleyin.

2

Düzenle bağlı-taraf.xml dosyası; DefaultRelyingParty etiketinden sonra Webex için SAML onayının ayrıntılarını ekleyin.

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

Kimlik için, Webex meta veri dosyasından EntityID değerini kullanmanız gerekir. Örneğin kimliğini kuruluşunuzun Varlık Kimliği ile değiştirin.

3

Meta veriler içinde:MetadataProvider etiketi, dosyanın konumunu ekleyin:

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

SP meta verileri, Webex kuruluşunuz için meta verileri yüklediğiniz konumdaki Shibboleth dosya sistemindeki bir dosyadan gelir.

Onaylama özniteliklerini yapılandır

1

Veri Bağlayıcı bölümünde, kullanıcılarınızla ilgili öznitelikleri nereye alacağınızı belirtin.

MyLDAP kimliğiyle Active Directory.

<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

Öznitelik tanımı bölümünde, transientID yapılandırmasında mevcut olanı saklayın.

3

SP'nin beklediği ek özniteliği ekleyin ve öznitelik kaynağında neyle eşleştiğini belirleyin.

Öznitelik postasını (Active Directory’deki e-posta adresi özniteliği) uid’le (Webex’teki UserID) eşleyin.

<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

attribute-filter.xml dosyasındaki her bir SP sözleşmesine hangi özniteliğin sağlanacağını tanımlayın.

Webex'e kullanıcının e-posta adresiyle eşleşen uid özniteliğini sağlayın.

Öznitelik kullanıcı kimliğini Webex ile SP anlaşmasına bırakın.

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

attribute-resolver.xml içinde oluşturduğunuz kuralın, mail-attr özniteliğini EntityID'ye Webex ile eşleşen bir ilkesi olması gerekir.

5

Meta veri dosyasını Shibboleth sunucusundan /opt/shibboleth-idp/meta data dosyasını indirin. Dosya adı idp-metadata.xml'dir.

IdP meta verilerini içe aktarın ve bir testten sonra tekli oturum açma etkinleştirin

Webex meta verilerini dışa aktardıktan, IdP'nizi yapılandırdıktan ve IdP meta verilerini yerel sisteminize indirdikten sonra bunları Control Hub'dan Webex kuruluşunuza aktarmaya hazırsınız.

Başlamadan önce

Kimlik sağlayıcı (IdP) arayüzünden SSO entegrasyonunu test etmeyin. Yalnızca Hizmet Sağlayıcı tarafından başlatılan (SP tarafından başlatılan) akışları destekliyoruz. Bu nedenle, bu entegrasyon için Control Hub SSO testini kullanmanız gerekir.

1

Şunlardan birini tercih edin:

  • Tarayıcınızda Control Hub – sertifika seçim sayfasına dönün ve ardından Sonraki .
  • Control Hub, tarayıcı sekmesinde artık açık değilse,https://admin.webex.com , git Yönetim > Organizasyon Ayarları , kaydır kimlik doğrulama seçin ve ardından Eylemler > Meta Verileri İçe Aktar .
2

IdP Meta Verilerini İçe Aktar sayfasında IdP meta veri dosyasını sayfaya sürükleyip bırakın veya meta veri dosyasını bulup yüklemek için dosya tarayıcı seçeneğini kullanın. İleri'ye tıklayın.

kullanmalısın Daha güvenli seçenek, eğer yapabilirsen. Bu, yalnızca IdP'niz meta verilerini imzalamak için genel bir CA kullandıysa mümkündür.

Diğer tüm durumlarda, Daha az güvenli seçenek. Bu, meta verilerin imzalanmamış, kendinden imzalı veya özel bir CA tarafından imzalanmamış olup olmadığını içerir.


 

Okta meta verileri imzalamaz, bu nedenle Daha az güvenli Okta SSO entegrasyonu için.

3

Seç SSO kurulumunu test edin ve yeni bir tarayıcı sekmesi açıldığında, oturum açarak IdP ile kimlik doğrulaması yapın.


 

Kimlik doğrulamayla ilgili bir hatayla karşılaşırsanız oturum açma bilgilerinizi yanlış girmiş olabilirsiniz. Kullanıcı adı ve parolanızı kontrol edip tekrar deneyin.

Webex Uygulaması hatası, genellikle SSO kurulumuyla ilgili bir sorun anlamına gelir. Bu durumda adımları, özellikle de Control Hub meta verilerini kopyalayıp IdP kurulumuna yapıştırmayla ilgili adımları tekrar uygulayın.


 

SSO ile giriş yapmaya doğrudan erişmek için bu ekranda URL’yi panoya kopyala seçeneğine tıklayın ve kopyaladığınız URL’yi özel bir tarayıcı penceresine yapıştırın. Burada, SSO ile giriş yapma işlemini gerçekleştirebilirsiniz. Bu adım, oturum açmanızdan sonra mevcut bir oturumda olabilecek bir erişim belirteci nedeniyle yanlış pozitifleri durdurur.

4

Control Hub tarayıcı sekmesine geri dönün.

  • Test başarılıysa, öğesini seçin. Başarılı test. SSO aç ve tıklayın Sonraki .
  • Test başarısız olursa, öğesini seçin. Başarısız test. SSO kapat ve tıklayın Sonraki .

 

İlk radyo düğmesi seçip SSO etkinleştirmediğiniz sürece, SSO yapılandırması kuruluşunuzda etkili olmaz.

Sonraki işlemler

içindeki prosedürleri kullanın. Okta Kullanıcılarını Cisco Webex Control Hub ile senkronize edin Webex bulutuna kullanıcı sağlama yapmak istiyorsanız.

içindeki prosedürleri kullanın. Azure Active Directory Kullanıcılarını Cisco Webex Control Hub ile senkronize edin Azure AD'den Webex bulutuna kullanıcı sağlama yapmak istiyorsanız.

adresindeki prosedürü takip edebilirsiniz. Otomatik E-postaları Engelle kuruluşunuzdaki yeni Webex Uygulaması kullanıcılarına gönderilen e-postaları devre dışı bırakmak için. Belgede, kuruluşunuzdaki kullanıcılarla en iyi şekilde iletişime geçme yöntemlerini de bulabilirsiniz.