本ヘルプセンターは英語版を翻訳したものです。また、一部には翻訳ソフトウエアにより機械的に翻訳した内容が含まれます。翻訳については順次対応しておりますが、最新の情報になっていない場合があります。最新の情報は英語版のページでご確認ください。表示言語は、画面右上の言語名をクリックして切り替えられます。

本ヘルプセンターの一部の記事には外部リンクが含まれています。万一リンク切れなどお気づきの点がございましたら、お手数ですが弊社サポート窓口までご連絡ください。

SAMLシングルサインオン（SSO）を実装する

SAMLシングルサインオンを実装するには、 SAMLシングルサインオンを設定する または SAMLシングルサインオンをAzure Active Directoryで設定するで設定します。

SAMLとシングルサインオンとは

Security Assertion Markup Language (SAML) は、当事者間でのユーザ識別情報の安全な交換を可能にする、オープンな認証標準です。SAMLは、1回のユーザログインを複数のアプリケーションとサービスにわたって機能させる技術である、シングルサインオンをサポートしています。Deep Securityでは、SAMLシングルサインオンを実装することで、組織のポータルにログオンするユーザが、既存のDeep SecurityアカウントなしでDeep Securityにシームレスにログオンできるようになります。

Deep SecurityでのSAMLシングルサインオンの仕組み

信頼関係を確立する

SAMLシングルサインオンでは、両当事者(IDプロバイダとサービスプロバイダ) の間で信頼関係が確立されます。IDプロバイダのディレクトリサーバにはユーザID情報が保存されています。サービスプロバイダ (この場合はDeep Security) は、IDプロバイダのユーザIDを使用して独自の認証とアカウント作成を行います。

IDプロバイダとサービスプロバイダは、SAMLメタデータドキュメントを交換することで、信頼を確立します。

現時点では、Deep SecurityはSAML 2.0 IDプロバイダ (IdP) で開始されたログインフローのHTTP POSTバインディングのみをサポートし、サービスプロバイダ (SP) で開始されたログインフローはサポートしません。

ユーザIDからDeep Securityアカウントを作成する

Deep SecurityとIDプロバイダがSAMLメタデータドキュメントを交換して信頼関係を確立すると、Deep SecurityはIDプロバイダのディレクトリサーバ上のユーザIDにアクセスできるようになります。ただし、Deep Securityが実際にユーザIDからアカウントを作成する前に、アカウントの種類を定義し、データ形式を変換するための手順を導入する必要があります。これは、グループ、役割、クレームを使用して実行されます。

グループと役割は、Deep Securityユーザアカウントのテナントとアクセス許可を指定します。グループは、IDプロバイダのディレクトリサーバ上に作成されます。IDプロバイダは、1つ以上のグループにユーザIDを割り当てます。役割はDeep Security Managerで作成されます。各Deep Securityアカウントの種類にはグループと役割の両方が必要で、アクセス許可とテナントの割り当てが一致している必要があります。

各ユーザの種類に一致するグループと役割を用意したら、グループデータ形式をDeep Securityが理解できる形式に変換する必要があります。これは、IDプロバイダによりクレームを使用して実行されます。クレームには、グループデータ形式を一致するDeep Securityの役割に変換するための手順が含まれています。

Deep Securityで必要となるSAMLクレームの構造について確認してください。

このプロセスを次に示します。

Deep SecurityでSAMLシングルサインオンを実装する

SAMLメタデータドキュメントの交換により、Deep SecurityとIDプロバイダとの間で信頼関係が確立されると、一致するグループと役割が作成され、グループデータを役割に変換するためのクレームが導入されて、Deep SecurityはSAMLシングルサインオンを使用して組織のポータルからログオンするユーザに対してDeep Securityアカウントを自動的に作成できるようになります。

SAMLシングルサインオンの実装の詳細については、SAMLシングルサインオンを設定するを参照してください。