第10章 SSO プロトコル

このセクションでは、認証プロトコル、Red Hat Single Sign-On 認証サーバー、および Red Hat Single Sign-On 認証サーバーでセキュア化されたアプリケーションがどのようにこれらのプロトコルと対話するかを説明します。

10.1. OpenID Connect

OpenID Connect (OIDC) は、OAuth 2.0 の拡張機能である認証プロトコルです。

OAuth 2.0 は承認プロトコルを構築するためのフレームワークで、不完全です。一方、OIDC は、Json Web Token (JWT) 標準を使用する完全な認証および承認プロトコルです。JWT 標準は、アイデンティティートークンの JSON 形式を定義し、コンパクトで Web フレンドリーにデータをデジタル署名および暗号化する方法を定義しています。

通常、OIDC は 2 つのユースケースを実装します。最初のケースは、Red Hat Single Sign-On サーバーがユーザーを認証するように要求するアプリケーションです。ログインに成功すると、アプリケーションは ID トークン と アクセストークン を受け取ります。ID トークン には、ユーザー名、電子メール、プロファイル情報などのユーザー情報が含まれています。レルムは、アクセス情報 (ユーザーロールマッピングなど) が含まれるアクセストークン にデジタル署名します。アプリケーションは、この情報を使用してユーザーがアプリケーションでアクセスできるリソースを判断します。

2 つ目のユースケースは、リモートサービスにアクセスするクライアントです。

  • クライアントは Red Hat Single Sign-On から アクセストークン を要求し、ユーザーの代わりにリモートサービスを呼び出します。
  • Red Hat Single Sign-On はユーザーを認証し、ユーザーに要求元のクライアントにアクセスを付与することに同意するよう要求します。
  • クライアントは、レルムによってデジタル署名される アクセストークン を受け取ります。
  • クライアントは、アクセストークン を使用して、リモートサービスで REST 要求を行います。
  • リモート REST サービスは アクセストークン を抽出します。
  • リモート REST サービスは、トークンの署名を検証します。
  • リモート REST サービスは、トークン内のアクセス情報に基づいて、リクエストを処理するか拒否するかを決定します。

10.1.1. OIDC 認証フロー

OIDC には、複数のメソッド (またはフロー) があり、クライアントまたはアプリケーションがユーザーを認証し、アイデンティティー および アクセス トークンを受け取るために使用できます。このメソッドは、アクセスを要求するアプリケーションまたはクライアントのタイプによって異なります。

10.1.1.1. 認可コードフロー

認可コードフローはブラウザーベースのプロトコルで、ブラウザーベースのアプリケーションの認証および承認に適しています。ブラウザーのリダイレクトを使用してアイデンティティーおよびアクセストークンを取得します。

  1. ユーザーは、ブラウザーを使用してアプリケーションに接続します。アプリケーションは、ユーザーがアプリケーションにログインしていないことを検出します。
  2. アプリケーションは、認証のためにブラウザーを Red Hat Single Sign-On にリダイレクトします。
  3. アプリケーションは、コールバック URL をブラウザーリダイレクトのクエリーパラメーターとして渡します。Red Hat Single Sign-On は、認証に成功するとパラメーターを使用します。
  4. Red Hat Single Sign-On がユーザーを認証し、1 回限りの有効期間の短い一時的なコードを作成します。
  5. Red Hat Single Sign-On はコールバック URL を使用してアプリケーションにリダイレクトし、一時コードをコールバック URL のクエリーパラメーターとして追加します。
  6. アプリケーションは一時コードを抽出し、Red Hat Single Sign-On にバックグラウンド REST 呼び出しを行い、アイデンティティー、アクセス、リフレッシュ トークンのコードを交換します。再生攻撃を防止するため、一時コードは複数回使用できません。
注記

システムは、トークンが有効な間、そのトークンの盗難に対して脆弱です。セキュリティーおよびスケーラビリティーの理由から、アクセストークンは通常すぐに期限切れになるように設定されるため、後続のトークンリクエストは失敗します。トークンの有効期限が切れると、アプリケーションはログインプロトコルによって送信される追加の 更新 トークンを使用して新しいアクセストークンを取得できます。

機密性が要求される クライアントは、トークンの一時コードを交換する際にクライアントシークレットを提供します。パブリッククライアントは、クライアントシークレットの提供を要求されません。パブリック クライアントは、HTTPS が厳格に適用され、クライアントに登録されているリダイレクト URI が厳格に制御される場合に保護されます。HTML5/JavaScript クライアントは、クライアントシークレットを HTML5/JavaScript クライアントへ安全に送信する方法がないため、パブリック クライアントである必要があります。詳細は、クライアントの管理 の章を参照してください。

Red Hat Single Sign-On は、Proof Key for Code Exchange 仕様もサポートします。

10.1.1.2. インプリシットフロー

インプリシットフローはブラウザーベースのプロトコルです。これは Authorization Code Flow と似ていますが、要求が少なく、更新トークンはありません。

注記

トークンがリダイレクト URI で送信されると、アクセス トークンがブラウザーの履歴に漏洩する可能性があります (以下を参照)。

また、このフローはクライアントに更新トークンを提供しません。したがって、アクセストークンの有効期限を長くするか、期限切れになったらユーザーを再認証する必要があります。

このフローの使用を推奨していません。このフローは OIDC および OAuth 2.0 仕様にあるためサポートされます。

このプロトコルは以下のように動作します。

  1. ユーザーは、ブラウザーを使用してアプリケーションに接続します。アプリケーションは、ユーザーがアプリケーションにログインしていないことを検出します。
  2. アプリケーションは、認証のためにブラウザーを Red Hat Single Sign-On にリダイレクトします。
  3. アプリケーションは、コールバック URL をブラウザーリダイレクトのクエリーパラメーターとして渡します。Red Hat Single Sign-On は、認証に成功するとクエリーパラメーターを使用します。
  4. Red Hat Single Sign-On はユーザーを認証し、identity および access トークンを作成します。Red Hat Single Sign-On はコールバック URL を使用してアプリケーションにリダイレクトし、さらにアイデンティティー および アクセストークンをコールバック URL のクエリーパラメーターとして追加します。
  5. アプリケーションはコールバック URL から identity および access トークンを抽出します。

10.1.1.3. リソースオーナーパスワードクレデンシャルの付与 (直接アクセスグラント)

Direct Access Grants は、ユーザーの代わりにトークンを取得するために REST クライアントによって使用されます。これは、以下の項目を含む HTTP POST リクエストです。

  • ユーザーの認証情報。認証情報はフォームパラメーターで送信されます。
  • クライアントの ID。
  • クライアントシークレット (機密性が要求されるクライアントの場合)。

HTTP 応答には、アイデンティティー、アクセス、および 更新 トークンが含まれます。

10.1.1.4. クライアント認証情報の付与

Client Credentials Grant は、外部ユーザーの代わりに機能するトークンを取得するのではなく、クライアントに関連付けられたサービスアカウントのメタデータおよびパーミッションに基づいてトークンを作成します。Client Credentials Grants は REST クライアントによって使用されます。

詳細は、サービスアカウント の章を参照してください。

10.1.1.5. デバイス承認の付与

これは、入力機能が制限されているか、適切なブラウザーがないインターネット接続デバイスで実行されているクライアントによって使用されます。以下は、プロトコルの概要です。

  1. アプリケーションは Red Hat Single Sign-On にデバイスコードとユーザーコードを要求します。Red Hat Single Sign-On は、デバイスコードとユーザーコードを作成します。Red Hat Single Sign-On は、デバイスコードおよびユーザーコードなどの応答をアプリケーションに返します。
  2. アプリケーションはユーザーにユーザーコードと検証 URI を提供します。ユーザーは検証 URI にアクセスし、別のブラウザーを使用して認証されます。
  3. アプリケーションは Red Hat Single Sign-On に繰り返しポーリングを行い、ユーザーがユーザー承認を完了たかどうかを確認します。ユーザー認証が完了すると、アプリケーションは アイデンティティー、アクセス、更新のトークンのデバイスコードを交換します。

10.1.1.6. クライアントが開始したバックチャネル認証の付与

この機能は、OAuth 2.0 の認証コード付与のように、ユーザーのブラウザーを介してリダイレクトせずに、OpenID プロバイダーと直接通信することで認証フローを開始するクライアントによって使用されます。以下は、プロトコルの概要です。

  1. クライアントは、クライアントによる認証要求を識別する auth_req_id を Red Hat Single Sign-On に要求します。Red Hat Single Sign-On は auth_req_id を作成します。
  2. この auth_req_id を受信した後、このクライアントは、ユーザーが認証されるまで、auth_req_id と引き換えに、Red Hat Single Sign-On からアクセストークン、更新トークン、および ID トークンを取得するために Red Hat Single Sign-On を繰り返しポーリングする必要があります。

管理者は、Client Initiated Backchannel Authentication (CIBA) 関連の操作をレルムごとに CIBA ポリシー として設定できます。

また、Securing Applications and Services Guide の Backchannel Authentication Endpoint section および Client Initiated Backchannel Authentication Grant section など、Red Hat Single Sign-On ドキュメントの他の箇所も参照してください。

10.1.1.6.1. CIBA ポリシー

管理者は、Admin Console で以下の操作を実行します。

  • Authentication → CIBA Policy タブを開きます。
  • 項目を設定し、Save をクリックします。

設定可能な項目とその説明を以下に示します。

設定説明

Backchannel Token Delivery Mode

CD(Consumption Device) が認証結果および関連するトークンを取得する方法を指定します。poll、ping、および push の 3 つのモードがあります。Red Hat Single Sign-On は、poll のみをサポートします。デフォルトの設定は poll です。この設定は必須です。詳細は、CIBA 仕様 を参照してください。

Expires In

認証リクエストが受信されてからの auth_req_id の有効期限 (秒単位)。デフォルト設定は 120 です。この設定は必須です。詳細は、CIBA 仕様 を参照してください。

Interval

CD (Consumption Device) がトークンエンドポイントへのポーリングリクエストを待機する必要がある間隔 (秒単位)。デフォルト設定は 5 です。この設定はオプションです。詳細は、CIBA 仕様 を参照してください。

Authentication Requested User Hint

認証が要求されているエンドユーザーを識別する方法。デフォルト設定は login_hint です。login_hint、login_hint_token、および id_token_hint の 3 つのモードがあります。Red Hat Single Sign-On は login_hint のみをサポートします。この設定は必須です。詳細は、CIBA 仕様 を参照してください。

10.1.1.6.2. プロバイダー設定

CIBA 付与は以下 2 つのプロバイダーを使用します。

  1. Authentication Channel Provider:Red Hat Single Sign-On と、AD(認証デバイス) でユーザーを実際に認証するエンティティー間の通信を提供します。
  2. User Resolver Provider: クライアントが提供する情報から Red Hat Single Sign-On の UserModel を取得し、ユーザーを特定します。

Red Hat Single Sign-On には両方のデフォルトプロバイダーがあります。ただし、管理者は以下のように Authentication Channel Provider を設定する必要があります。 

<spi name="ciba-auth-channel">
    <default-provider>ciba-http-auth-channel</default-provider>
    <provider name="ciba-http-auth-channel" enabled="true">
        <properties>
            <property name="httpAuthenticationChannelUri" value="https://backend.internal.example.com/auth"/>
        </properties>
    </provider>
</spi>

設定可能な項目とその説明を以下に示します。

設定説明

httpAuthenticationChannelUri

AD(認証デバイス) でユーザーを実際に認証するエンティティーの URI を指定します。

10.1.1.6.3. Authentication Channel Provider

CIBA 標準ドキュメントでは、AD によるユーザーの認証方法は指定されていません。したがって、製品の判断で実装される可能性があります。Red Hat Single Sign-On は、この認証を外部認証エンティティーに委譲します。認証エンティティーと通信するには、Red Hat Single Sign-On は Authentication Channel Provider を提供します。

Red Hat Single Sign-On の実装では、認証エンティティーが Red Hat Single Sign-On の管理者の制御下にあり、Red Hat Single Sign-On が認証エンティティーを信頼することを前提としています。Red Hat Single Sign-On の管理者が制御できない認証エンティティーを使用することは推奨されません。

Authentication Channel Provider は SPI プロバイダーとして提供され、Red Hat Single Sign-On のユーザーは環境を満たすために独自のプロバイダーを実装できます。Red Hat Single Sign-On は、HTTP を使用して認証エンティティーと通信する HTTP Authentication Channel Provider と呼ばれるデフォルトプロバイダーを提供します。

Red Hat Single Sign-On ユーザーのユーザーが HTTP Authentication Channel Provider を使用する場合は、以下の 2 つの部分で設定される Red Hat Single Sign-On と認証エンティティーの契約を知っている必要があります。

認証委譲リクエスト/レスポンス
Red Hat Single Sign-On は認証リクエストを認証エンティティーに送信します。
認証結果通知/ACK
認証エンティティーは、認証の結果を Red Hat Single Sign-On に通知します。

認証委譲リクエスト/レスポンスは、以下のメッセージングで設定されます。

認証委譲リクエスト
リクエストは Red Hat Single Sign-On から認証エンティティーに送信され、AD によるユーザー認証を要求します。 
POST [delegation_reception]
  • Headers
名前値説明

Content-Type

application/json

メッセージのボディーは json 形式です。

承認

Bearer [token]

[token] は、認証エンティティーが認証の結果を Red Hat Single Sign-On に通知する場合に使用されます。

  • パラメーター
タイプ名前説明

パス

delegation_reception

委譲リクエストを受信するために認証エンティティーによって提供されるエンドポイント

  • 本文
名前説明

login_hint

だれが AD で認証されるかを認証エンティティーに指示します。
デフォルトでは、ユーザーのユーザー名です。
このフィールドは必須で、CIBA 標準ドキュメントで定義されています。

scope

これは、認証されたユーザーから認証エンティティーが合意を取得するスコープを示します。
このフィールドは必須で、CIBA 標準ドキュメントで定義されています。

is_consent_required

これは、認証エンティティーがスコープについて認証済みユーザーから合意を取得する必要があるかどうかを示します。
このフィールドは必須です。

binding_message

この値は、CD と AD 両方の UI に表示され、ユーザーが AD による認証が CD によってトリガーされることを認識できるようにします。
このフィールドはオプションで、CIBA 標準ドキュメントで定義されています。

acr_values

これは、CD からの要求元の Authentication Context Class Reference を指示します。
このフィールドはオプションで、CIBA 標準ドキュメントで定義されています。

認証委譲応答

認証エンティティーから Red Hat Single Sign-On に応答が返され、認証エンティティーが Red Hat Single Sign-On から認証リクエストを受け取ったことを通知します。

  • 応答
HTTP ステータスコード説明

201

認証委譲リクエストを受信したことを Red Hat Single Sign-On に通知します。

認証結果通知/ACK は以下のメッセージングで設定されます。

認証結果通知
認証エンティティーは、認証リクエストの結果を Red Hat Single Sign-On に送信します。 
POST /auth/realms/[realm]/protocol/openid-connect/ext/ciba/auth/callback
  • Headers
名前値説明

Content-Type

application/json

メッセージのボディーは json 形式です。

承認

Bearer [token]

[token] は、認証エンティティーが認証委譲リクエストで Red Hat Single Sign-On から受け取ったトークンである必要があります。

  • パラメーター
タイプ名前説明

パス

realm

レルム名

  • 本文
名前説明

status

これは、AD によるユーザー認証の結果を示します。
以下のステータスのいずれかである必要があります。
SUCCEED: AD による認証が正常に完了しました。
UNAUTHORIZED: AD による認証が完了していません。
CANCELLED: AD による認証はユーザーによりキャンセルされています。

認証結果 ACK

Red Hat Single Sign-On から認証エンティティーに応答が返され、Red Hat Single Sign-On が認証エンティティーから AD によるユーザー認証の結果を受け取ったことを通知します。

  • 応答
HTTP ステータスコード説明

200

認証の結果の通知を受信したことを認証エンティティーに通知します。

10.1.1.6.4. User Resolver Provider

同じユーザーであっても、その表現は CD、Red Hat Single Sign-On、および認証エンティティーごとに異なる場合があります。

CD、Red Hat Single Sign-On、および認証エンティティーが同じユーザーを認識するために、この User Resolver Provider は独自のユーザー表現を 3 者の間で変換します。

User Resolver Provider は SPI プロバイダーとして提供され、Red Hat Single Sign-On のユーザーは環境を満たすために独自のプロバイダーを実装できます。Red Hat Single Sign-On は、以下の特性を持つ Default User Resolver Provider と呼ばれるデフォルトプロバイダーを提供します。

  • login_hint パラメーターのみをサポートし、デフォルトとして使用されます。
  • Red Hat Single Sign-On の UserModel の username は、CD、Red Hat Single Sign-On、および認証エンティティーのユーザーを表すために使用されます。

10.1.2. OIDC ログアウト

OIDC には、ログアウトメカニズムに関連する 3 つの異なる仕様があります。これらはすべてドラフトステータスにあります。

  1. セッション管理
  2. フロントチャンネルログアウト
  3. バックチャネルログアウト

繰り返しになりますが、これらはすべて OIDC 仕様に記載されていますが、ここでは概要のみを説明します。

10.1.2.1. セッション管理

これはブラウザーベースのログアウトです。アプリケーションは、Red Hat Single Sign-On から定期的にセッションステータス情報を取得します。Red Hat Single Sign-On でセッションが終了すると、アプリケーションは通知し、独自のログアウトをトリガーします。

10.1.2.2. フロントチャンネルログアウト

これはブラウザーベースのログアウトでもあり、Red Hat Single Sign-On でユーザーを特定のエンドポイントにリダイレクトすることでログアウトが開始されます。

ユーザーがログアウトエンドポイントにリダイレクトされると、Red Hat Single Sign-On はクライアントにログアウトリクエストを送信して、ローカルユーザーセッションを無効にし、ログアウトプロセスが終了したらユーザーを何らかの URL にリダイレクトできるようにします。

クライアントの設定に応じて、ログアウト要求はフロントチャネルまたはバックチャネルを介してクライアントに送信できます。

フロントチャネルを介してログアウト要求を受信するようにクライアントを設定するには、フロントチャネルログアウト クライアントの設定を確認してください。この方法を使用するときは、次のことを考慮してください。

  • Red Hat Single Sign-On によってクライアントに送信されるログアウト要求は、ブラウザーと、ログアウトページ用にレンダリングされる組み込み iframe に依存します。
  • iframe に基づいているため、フロントチャネルのログアウトはコンテンツセキュリティーポリシー (CSP) の影響を受け、ログアウト要求がブロックされる可能性があります。
  • ログアウトページを表示する前、またはログアウト要求が実際にクライアントに送信される前にユーザーがブラウザーを閉じた場合、クライアントでのセッションが無効にならない可能性があります。
注記

Back-Channel Logout の使用を検討してください。これは、ユーザーがログアウトしてクライアントでセッションを終了するための、信頼性が高く安全な方法を提供します。

クライアントがフロントチャネルログアウトを有効にしていない場合、Red Hat Single Sign-On は最初に、バックチャネルログアウト URL を使用してバックチャネルを介してログアウト要求を送信しようとします。定義されていない場合は、サーバーは 管理 URL を使用するようにフォールバックします。

10.1.2.3. バックチャネルログアウト

これは、Red Hat Single Sign-On とクライアント間の直接バックチャンネル通信を使用する非ブラウザーベースのログアウトです。Red Hat Single Sign-On は、ログアウトトークンが含まれる HTTP POST リクエストを、Red Hat Single Sign-On にログインしたすべてのクライアントに送信します。これらのリクエストは、Red Hat Single Sign-On で登録されたバックチャンネルログアウト URL に送信され、クライアント側でのログアウトをトリガーする想定です。

10.1.3. Red Hat Single Sign-On サーバー OIDC URI エンドポイント

以下は、Red Hat Single Sign-On がパブリッシュする OIDC エンドポイントの一覧です。Red Hat Single Sign-On 以外のクライアントアダプターが OIDC を使用して認証サーバーと通信する場合に、これらのエンドポイントを使用できます。これらはすべて相対 URL です。URL のルートは、通常 /auth の接頭辞が付けられた HTTP(S) プロトコル、ホスト名、およびパスで設定されます。例: 

https://localhost:8080/auth
/realms/{realm-name}/protocol/openid-connect/auth
Authorization Code Flow で一時的なコードを取得する場合、または Implicit Flow、Direct Grants、または Client Grants を使用してトークンを取得する際に使用されます。
/realms/{realm-name}/protocol/openid-connect/token
一時コードをトークンに変換するために認可コードフローによって使用されます。
/realms/{realm-name}/protocol/openid-connect/logout
ログアウトの実行に使用されます。
/realms/{realm-name}/protocol/openid-connect/userinfo
OIDC 仕様で説明されている User Info サービスに使用されます。
/realms/{realm-name}/protocol/openid-connect/revoke
RFC7009 で説明されているように OAuth 2.0 Token Revocation に使用されます。
/realms/{realm-name}/protocol/openid-connect/certs
JSON Web Token (jwks_uri) の検証に使用される公開鍵が含まれる JSON Web Key Set (JWKS) に使用されます。
/realms/{realm-name}/protocol/openid-connect/auth/device
デバイスコードおよびユーザーコードを取得するために Device Authorization Grant に使用されます。
/realms/{realm-name}/protocol/openid-connect/ext/ciba/auth
これは、クライアントによって行われた認証要求を識別する auth_req_id を取得するためのクライアント主導のバックチャネル認証許可の URL エンドポイントです。
/realms/{realm-name}/protocol/openid-connect/logout/backchannel-logout
これは、OIDC 仕様で説明されているバックチャネルログアウトを実行するための URL エンドポイントです。

これらすべてで、{realm-name} をレルムの名前に置き換えます。