シングル サインオンと Control Hub

シングル サインオン (SSO) は、1 つまたは複数のアプリケーションにアクセスするための証明書の提出をユーザーに許可するセッションないしはユーザー認証プロセスです。 このプロセスは、権限を与えられたすべてのアプリケーションに対してユーザーを認証します。 ユーザーが特定のセッション中にアプリケーションをスイッチする際、以降のプロンプトを不要にします。

Security Assertion Markup Language (SAML 2.0) フェデレーションプロトコルは、Webex クラウドとお使いの ID プロバイダー (IdP) の間で SSO 認証を提供するために使用されます。

プロファイル

Webex アプリは Web ブラウザーの SSO プロファイルのみをサポートします。 Web ブラウザーの SSO プロファイルでは、Webex アプリ は以下のバインドをサポートします。

  • SP 初期化済み POST -> POST バインディング

  • SP 初期化済み REDIRECT -> POST バインディング

NameID 形式

SAML 2.0 プロトコルは、特定のユーザーについての通信を目的として多くの NameID 形式をサポートします。 Webex アプリは次の 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

IdP から読み込んだメタデータで、最初のエントリは Webex で使用するために設定されます。

SingleLogout

Webex アプリは、シングル ログアウト プロファイルをサポートします。 Webex アプリでは、ユーザーは SAML シングル ログアウト プロトコルを使用するアプリケーションからサインアウトすることによりセッションを終了し、IdP でのサインアウトを確認できます。 IdP が SingleLogout に対して構成されていることを確認してください。

Control Hub を Shibboleth と統合する


 

この設定ガイドでは、SSO インテグレーションの具体的な例を示しますが、すべての可能性に対し網羅的な設定を提供するものではありません。 たとえば、 nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient のインテグレーション手順が掲載されています。 その他のフォーマット (例: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress) は SSO インテグレーションで機能しますが、Cisco のドキュメントでは取り上げていません。

Webex 組織のユーザーについて、このインテグレーションをセットアップします (Webex アプリ、Webex Meetings、その他の Control Hub で管理されるサービスなど)。 Webex サイトが Control Hub で統合されている場合、その Webex サイトはユーザー管理を引き継ぎます。 この方法で Webex Meetings にアクセスできず、Control Hub で管理されていない場合、Webex Meetings で SSO を有効にするには、個別にインテグレーションを実行する必要があります。 (サイト管理の SSO インテグレーションの詳細については、「Webex のシングル サインオンの設定」を参照してください)

統合手順はウェブサーバーとして Tomcat 7 を持つ Shibboleth 2.4.5 in CentOS 7 を参照します。

始める前に

SSO および Control Hub では、IdP は SAML 2.0 の仕様を満たす必要があります。 加えて、IdP は以下のように設定されている必要があります。

Webex メタデータをローカル システムにダウンロードする

1

https://admin.webex.com の顧客ビューから、[管理] > [組織の設定] に移動し、[認証] までスクロールして、[シングル サインオン] 設定に切り替えて、セットアップ ウィザードを開始します。

2

組織の証明書タイプを選択します。

  • Cisco による自己署名 - この選択を推奨します。 当社が証明書に署名すれば、5 年に 1 回更新するだけで済みます。
  • パブリック認証局による署名 - より安全ですが、メタデータを頻繁に更新する必要があります (IdP ベンダーが信頼アンカーをサポートしていない限り)。

 

信頼アンカーとは、デジタル署名証明書を確認する役目を持つ公開鍵です。 詳細については、IdP ドキュメントを参照してください。

3

メタデータ ファイルをダウンロードします。

Webex メタデータのファイル名は idb-meta--SP.xml です。<org-ID>

Shibboleth ファイルの認証を設定する

Shibboleth をインストールした後、構成ファイルがサンプルと共に提供されます。

1

ディレクトリ /opt/shibboleth-idp/conf を開いてサンプルファイルにアクセスしてください。

2

例えば Active Directory に紐付けされた LDAP など、どちらの認証方法を使用するかを決めてください。

3

handler.xml ファイルを以下の通り編集します。

コメント解除

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

コメント

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

認証を許可するため、お使いの Active Directory の詳細を入力してください。 ファイル login.config に構成を追加します。

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 アサーションのために Shibboleth サービス プロバイダー のコンポーネントを設定する

1

Webex SP からディレクトリ /opt/shibboleth-idp/metadata にダウンロードしたファイルを追加します。

2

relying-party.xml ファイルを編集し、DefaultRelyingParty タグの後に、Webex の SAML アサーションの詳細を追加します

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

Id については、Webex メタデータ ファイルからの EntityID 値を使用する必要があります。 サンプルの ID を所属組織の EntityID に置き換えてください。

3

metadata:MetadataProvider タグで、以下の通りファイルの場所を追加してください。

 <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 メタデータは、Shibboleth ファイル システム内の、Webex 組織のためにメタデータをアップロードした場所にあるファイルから取り込まれます。

アサーション属性を設定する

1

Data Connector セクションで、ユーザーに関する属性を検索する場所を指定します。

Active Directory 、 MyLDAP の id で

<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

属性定義のセクションで、transientID の構成に既にあるものを保存してください。

3

SP が期待している追加属性を追加し、それが属性ソースにマッピングするものを定義します。

属性メール (Active Directory のメール アドレス属性) を uid (Webex のユーザー ID) にマッピングします。

<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 ファイルの各 SP 合意に提供する属性を定義します。

uid 属性をユーザーのメール アドレスにマッピングする Webex に提供します。

uid 属性を Webex の SP 合意にリリースします。

<!--  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 に作成したルールには、mail-attr 属性を Webex にマッチする EntityID にリリースするポリシーを持たせてください。

5

/opt/shibboleth-idp/metadata の Shibboleth サーバーからメタデータ ファイルをダウンロードします。 ファイル名は idp-metadata.xml です。

IdP メタデータをインポートし、テスト後にシングル サインオンを有効にする

Webex メタデータをエクスポートし、IdP を設定して IdP メタデータをローカルのシステムにダウンロードすると、お使いの Webex 組織に Control Hub からインポートする準備が整います。

始める前に

ID プロバイダ (IdP) インターフェイスからの SSO 統合をテストしないでください。 サービス プロバイダーにより開始された (SP 主導) フローのみをサポートしているため、この統合には Control Hub SSO テストを使用する必要があります。

1

1 つを選択します。

  • Control Hub に戻る - ブラウザーの証明書選択ページに戻り、[次へ] をクリックします。
  • ブラウザー タブに Control Hub が開いていない場合は、 の顧客ビューから、[管理] > [組織の設定] に進み、[認証] までスクロールして、[アクション] > [メタデータをインポート] を選択します。https://admin.webex.com
2

[IdP メタデータのインポート] ページ上で IdP メタデータファイルをこのページにドラッグアンドドロップするか、ファイルブラウザオプションを使用してメタデータファイルを見つけてアップロードします。 [次へ] をクリックします。

可能な場合は [安全性が高い] オプションを使用してください。 これは、IdP がパブリック CA を使用してメタデータに署名した場合にのみ可能です。

それ以外のすべての場合、[安全性が低い] オプションを使用する必要があります。 たとえば、メタデータに署名がない場合、自己署名の場合、プライベート CA が署名した場合などです。


 

Okta はメタデータに署名しないため、Okta SSO インテグレーションには [安全性が低い] を選択する必要があります。

3

[SSO セットアップのテスト] を選択し、新しいブラウザー タブが開いたら、サインインすることで IdP の認証を受けます。


 

認証エラーを受け取った場合、証明書に問題がある可能性があります。 ユーザー名とパスワードを確認して再度試してください。

通常、Webex アプリのエラーは SSO セットアップの問題です。 この場合は、この手順、特に Control Hub メタデータを IdP セットアップにコピーおよび貼り付けを行った手順のウォークスルーを再度実施します。


 

SSO サインイン エクスペリエンスを直接見るには、この画面から [URL をクリップボードに貼り付け] をクリックして、それをプライベート ブラウザ ウィンドウに貼り付けることもできます。 そこから、SSO のサインインをウォークスルーできます。 このステップにより、既存セッションに存在する可能性があるアクセストークンによる誤判定でサインインできなくなるのを回避できます。

4

Control Hub ブラウザー タブに戻ります。

  • テストが成功した場合は、[テストに成功しました] を選択します。 SSO をオンにし[次へ] をクリックします。
  • テストが失敗した場合、[テストに失敗しました] を選択します。 SSO をオフにし[次へ] をクリックします。

 

最初のラジオ ボタンを選択して SSO を有効にしない限り、SSO 設定は組織で有効に機能しません。

次に行うこと

[Okta ユーザーを Cisco Webex Control Hub に同期する] の手順を使用して、Webex クラウドに Okta からのユーザー プロビジョニングを実行します。

Azure AD から Webex クラウドにユーザープロビジョニングを実行する場合、Azure Active Directory ユーザーを Cisco Webex Control Hub に同期するための手順を使用します。

「自動化されているメールを抑制する」の手順に従って、組織の新しい Webex アプリ ユーザーに送信されるメールを無効にできます。 この文書もまた、組織のユーザーにコミュニケーションを送信するためのベストプラクティスも含みます。