SP でのシングル サインオンの設定
目次
casso126jjp
目次
2
アイデンティティ プロバイダとサービス プロバイダの間のシングル サインオンを確立するには、SSO バインディングを指定します。
SSO 設定により、Artifact または POST バインドを使用するシングル サインオンを設定します。
シングル サインオン設定の一環として、リダイレクト モード設定を定義します。リダイレクト モードでは、
Single Sign-On
がアサーション属性(存在する場合)をターゲット アプリケーションに送信する方法が指定されます。アサーション属性は HTTP ヘッダまたは HTTP Cookie として送信できます。casso126jjp
HTTP ヘッダおよび HTTP Cookie にはサイズ制限があり、アサーション属性でそれらを超えることはできません。サイズ制限は以下のとおりです。
- HTTP ヘッダ:Single Sign-Onは、Web サーバのヘッダに関するサイズ制限までの属性をヘッダで送信できます。1 つのヘッダごとに 1 つのアサーション属性のみが許可されます。ヘッダ サイズの制限を調べるには、使用している Web サーバのドキュメントを参照してください。
- HTTP Cookie:Single Sign-Onは、Cookie のサイズ制限までの Cookie を送信できます。それぞれのアサーション属性は、それ自身の Cookie として送信されます。Cookie のサイズ制限はブラウザ固有です。また、その制限は、属性ごとではなく、アプリケーションに渡されるすべての属性に適用されます。Cookie のサイズ制限を調べるには、使用する Web ブラウザのドキュメントを参照してください。
シングル サインオンを設定する方法
- SAML 2.0 認証方式に移動します。
- [SAML 2.0 設定]-[SSO]を選択します。
- SSO フィールドに入力します。
- (オプション)シングル サインオンが動作するターゲット リソースを指定します。ターゲットとしては、宛先のサービス プロバイダ サイトにおける要求対象リソースを指定します。サービス プロバイダは、デフォルトのターゲットを使用する必要はありません。シングル サインオンを開始するリンクには、ターゲットを指定するクエリ パラメータを含めることができます。
- [バインド]セクションで、HTTP-Artifact および HTTP-POST を選択できます。HTTP-POST が選択されており、Artifact が選択されていない場合、POST バインディングのみがアイデンティティ プロバイダから受理されます。バインディングが指定されない場合、デフォルトは HTTP-artifact です。HTTP-Artifact バインドを選択する場合、以下のように操作してください。
- セッション サーバを有効化して、アサーションが取得される前にアサーションを保存するようにします。
- バックチャネルを設定します。Artifact 解決サービスとの通信を保護する認証方式のタイプを選択します。このサービスは、アイデンティティ プロバイダにおいてアサーションを取得します。
- オプションで、各バインドのインデックス エントリとして整数を指定します。複数のエンドポイントがある場合、インデックス付きのエンドポイントを設定できます。サービス プロバイダには、指定されたエンドポイント エントリが認証リクエストのクエリ パラメータとして含まれます。認証リクエストは、アイデンティティ プロバイダのシングル サインオン サービスに送信されます。
使い捨てポリシーの適用によるセキュリティ強化
使い捨てポリシーは、サービス プロバイダで別のセッションを確立するために SAML 2.0 アサーションが再利用されるのを防止します。この機能は、POST バインドの目的で送信されてくるアサーションに適用されます。
注
: HTTP-POST バインドを選択すると、使い捨てポリシー機能がデフォルトで有効化されます。アサーションを単一使用に指定することで、シングル サインオン環境全域における認証のセキュリティを強化できます。ブラウザから、
Single Sign-On
セッションを確立するために使用された SAML アサーションを攻撃者が取得する可能性があります。この攻撃者は、別のセッションを確立するために、サービス プロバイダのアサーション コンシューマ サービスにアサーションをポストする可能性があります。ただし、アサーションが 1 回使用に指定されている場合には、この種のリスクが軽減されます。Single Sign-On
では、有効期限データを使用して単一使用ポリシーを適用します。有効期限データは、アサーションに関する時間ベースのデータです。SAML 2.0 認証方式では、有効期限データがセッション ストアに保存されています。有効期限データにより、SAML 2.0 POST アサーションが 1 回だけ使用されることが確認されます。使い捨てポリシーが適用される仕組み
SAML 2.0 アサーションの検証に成功すると、認証方式は、アサーション データを有効期限データ テーブルに書き込みます。このデータには、アサーション ID キーおよび有効期限が含まれます。ポリシー サーバ内のセッション ストア管理スレッドにより、期限切れデータが有効期限データテーブルから削除されます。
認証方式がアサーション データを検証し、有効期限データ エントリに同じアサーション ID キーが存在する場合、アサーション データの書き込みは失敗します。認証方式が有効期限テーブルに書き込むことができない場合、SAML 2.0 認証方式は、無効なアサーションと同じ方法で認証を拒否します。
データベースが利用できない場合、アサーションの使い捨ては適用できません。その結果、認証方式がリクエストを拒否し、アサーションは再利用されません。
使い捨てポリシーの設定
使い捨てポリシーを設定する方法
- SAML 2.0 認証方式に移動します。[変更]-[SAML 2.0 設定]をクリックします。
- [SSO]タブを選択します。
- [HTTP-POST]セクションの[使い捨てポリシーを構成する]チェック ボックスはデフォルトで選択されています。
- セッション ストアを有効にします。
SSO の名前識別子の作成の許可
シングル サインオン リクエストの一部として、サービス プロバイダは、AllowCreate という名前の属性(true に設定)が含まれる認証リクエストを生成できます。サービス プロバイダは、ユーザの ID を取得する必要があります。認証リクエストを受信すると、アイデンティティ プロバイダはアサーションを生成します。アイデンティティ プロバイダは、[名前 ID]として使用されるアサーション属性に適したユーザ レコードを検索します。アイデンティティ プロバイダは、NameID 属性の値が見つからない場合、永続的な識別番号を生成します。Allow/Create 機能により、この識別番号の作成が有効化されます。
永続的な識別番号は、ランダムに生成された ID です。アイデンティティ プロバイダでは、この識別番号を名前 ID 属性の値として使用し、アサーション内に配置します。その後、アイデンティティ プロバイダは、アサーションをサービス プロバイダに返します。たとえば、NameID 属性が電話に設定されており、ユーザ レコードに電話の値が存在しない場合、NameID は、ランダムに生成された識別番号に設定されます。
サービス プロバイダがアサーションを受信すると、SAML 2.0 認証方式がレスポンスを処理します。その後、認証方式は、そのローカル ユーザ ストアでユーザの検索を実行します。サービス プロバイダは、ユーザ レコードを検出した場合、そのユーザにアクセス権を付与します。
アイデンティティ プロバイダが固有の識別番号を生成するには、アイデンティティ プロバイダで Allow/Create 機能を有効にします。アイデンティティ プロバイダでは、機能が有効化されている場合のみ識別番号を生成します。固有の識別番号が作成されなかったというエントリがアイデンティティ プロバイダのログ ファイルに作成された後、アサーション生成の通常フローが続行されます。
認証リクエストへの Allow/Create 属性の追加
アイデンティティ プロバイダに名前 ID の識別子の作成を許可するには、認証リクエスト メッセージに Allow/Create 属性を含めます。
注
:アイデンティティ プロバイダの管理者は、生成される識別子に対して Allow/Create 機能を有効にする必要があります。以下の手順に従います。
- SAML 2.0 認証方式に移動します。
- [SAML 2.0 設定]-[SSO]を選択します。
- [IDP による新規識別子の作成を許可する]チェック ボックスをオンにします。
- [OK]をクリックします。
HTTP-Artifact SSO に関するバックチャネルの設定
シングル サインオンに HTTP-Artifact バインドを選択する場合、Artifact 解決サービスまでのバックチャネルのセキュリティを保護する認証方式を選択します。このサービスは、アイデンティティ プロバイダにおいてアサーションを取得します。
バックチャネルを設定する方法
- SAML 2.0 認証方式に移動します。
- [SAML 2.0 設定]-[暗号化]-[署名]を選択します。
- [バックチャネル]セクションで、すべてのフィールドに入力します。重要: バックチャネル認証方式にベーシック認証を使用している場合、[SP 名]フィールドの値はサービス プロバイダの名前になります。追加の設定は不要です。クライアント証明書認証を使用している場合、[SP 名]フィールドは、証明書データ ストアに保存されたクライアント証明書のエイリアスであることが必要です。SP は、Artifact 解決サービスへのアクセスを獲得取得するための認証情報として証明書を使用します。
- [OK]をクリックして設定を保存します。
サービス プロバイダでの ECP の設定
ECP を設定するには、アイデンティティ プロバイダおよびサービス プロバイダでこの機能を有効にします。
Single Sign-On
サービス プロバイダ向けの手順を以下に示します。ECP の詳細については、「概要」を参照してください。
以下の手順に従います。
- 保護されているリソースのリクエストをサービス プロバイダの認証リクエスト サービスに送信します。以下に URL の例を示します。https://host:port/affwebservices/public/saml2authnrequest
- サービス プロバイダで管理 UI にログインします。
- 関連する SAML 2.0 認証方式オブジェクトを変更します。
- [方式のセットアップ]セクションの[SAML 2.0 設定]をクリックします。方式の設定タブが表示されます。
- [SSO]タブを選択します。
- [拡張されたクライアントとプロキシ プロファイル]チェック ボックスをオンにして、[OK]をクリックします。
- [サブミット]をクリックして変更内容を保存します。
Single Sign-On
サービス プロバイダで ECP コールを処理できるようになりました。注
: 単一の SAML サービス プロバイダ オブジェクトは、シングル サインオン リクエストの Artifact、POST、SOAP、および PAOS バインディングを処理できます。SOAP と PAOS は、ECP プロファイルのバインディングです。アイデンティティ プロバイダおよびサービス プロバイダは、リクエストのパラメータに基づいて使用するバインディングを決定します。