- ホーム
- /
- 投稿記事
Shibboleth と統合された Control Hub でシングル サインオンを設定する
Control Hub と、Shibboleth を ID プロバイダー (IdP) として使用する展開の間で、シングル サインオン (SSO) インテグレーションを設定できます。
シングル サインオンと 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 または urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
のようなその他の形式は、SSO インテグレーションで動作しますが、当社のドキュメントの対象外にあります。
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 |
組織の証明書タイプを選択します。
信頼アンカーとは、デジタル署名証明書を確認する役目を持つ公開鍵です。詳細については、IdP ドキュメントを参照してください。 |
3 |
メタデータ ファイルをダウンロードします。 Webex メタデータのファイル名は idb-meta--SP.xml です。 |
Shibboleth ファイルの認証を設定する
Shibboleth をインストールした後、構成ファイルがサンプルと共に提供されます。
1 |
ディレクトリ /opt/shibboleth-idp/conf を開いてサンプルファイルにアクセスしてください。 |
2 |
例えば Active Directory に紐付けされた LDAP など、どちらの認証方法を使用するかを決めてください。 |
3 |
handler.xml ファイルを以下の通り編集します。 コメント解除 Comment |
4 |
認証を許可するため、お使いの Active Directory の詳細を入力してください。ファイル login.config に構成を追加します。
|
SAML アサーションのために Shibboleth サービス プロバイダー のコンポーネントを設定する
1 |
Webex SP からディレクトリ /opt/shibboleth-idp/metadata にダウンロードしたファイルを追加します。 |
2 |
relying-party.xml ファイルを編集します。DefaultRelyingParty タグの後で、Webex の SAML アサーションの詳細を追加します。
Id については、Webex メタデータ ファイルからの EntityID 値を使用する必要があります。サンプルの ID を所属組織の EntityID に置き換えてください。 |
3 |
metadata:MetadataProvider タグで、以下の通りファイルの場所を追加してください。
SP メタデータは、Shibboleth ファイル システム内の、Webex 組織のためにメタデータをアップロードした場所にあるファイルから取り込まれます。 |
アサーション属性を設定する
1 |
Data Connector セクションで、ユーザーに関する属性を検索する場所を指定します。 Active Directory 、 MyLDAP の id で
|
2 |
属性定義のセクションで、transientID の構成に既にあるものを保存してください。 |
3 |
SP が期待している追加属性を追加し、それが属性ソースにマッピングするものを定義します。 属性メール (Active Directory のメール アドレス属性) を uid (Webex のユーザー ID) にマッピングします。
|
4 |
attribute-filter.xml ファイルの各 SP 合意に提供する属性を定義します。 uid 属性をユーザーのメール アドレスにマッピングする Webex に提供します。 uid 属性を Webex の SP 合意にリリースします。
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 つを選択します。
|
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 設定は組織で有効に機能しません。 |
次に行うこと
[Okta ユーザーを Cisco Webex Control Hub に同期する] の手順を使用して、Webex クラウドに Okta からのユーザー プロビジョニングを実行します。
Azure AD から Webex クラウドにユーザープロビジョニングを実行する場合、Azure Active Directory ユーザーを Cisco Webex Control Hub に同期するための手順を使用します。
[自動メールを抑制する] の手順に従って、組織の新しい Webex アプリユーザーに送信されるメールを無効にすることができます。この文書もまた、組織のユーザーにコミュニケーションを送信するためのベストプラクティスも含みます。