1.3. サポートされているプロトコル
Red Hat Single Sign-On は、OpenID Connect と SAML プロトコルの両方をサポートします。
1.3.1. OpenID Connect
OpenID Connect (OIDC) は、OAuth 2.0 の拡張機能である認証プロトコルです。OAuth 2.0 は認可プロトコルを構築するためのフレームワークでしかなく、主に不完全ですが、OIDC は完全な認証および認可プロトコルです。OIDC は、JWT (Json Web Token) 標準セットも多用しています。これらの標準は、アイデンティティープロバイダーの JSON 形式を定義し、そのデータをコンパクトで Web フレンドリーで暗号化する方法を定義しています。
OIDC を使用する場合は、本当に 2 つのタイプのユースケースがあります。1 つ目のアプリケーションは、Red Hat Single Sign-On サーバーがユーザーを認証するよう依頼するアプリケーションです。ログインに成功すると、アプリケーションは ID トークン と アクセストークン を受け取ります。ID トークン には、ユーザー名、電子メール、その他のプロファイル情報など、ユーザーに関する情報が含まれています。アクセストークン はレルムによってデジタル署名され、アプリケーションでユーザーがアクセスできるリソースを判別するためにアプリケーションが使用できるアクセス情報 (ユーザーロールマッピングなど) が含まれます。
2 つ目のタイプのユースケースは、リモートサービスへのアクセスを取得するクライアントのものです。この場合、クライアントはユーザーの代わりに他のリモートサービスで起動するのに使用できる アクセストークン を取得するよう Red Hat Single Sign-On に要求します。Red Hat Single Sign-On はユーザーを認証し、ユーザーに要求したクライアントにアクセスを付与するよう依頼します。その後、クライアントは アクセストークン を受け取ります。この アクセストークン はレルムによってデジタル署名されます。クライアントはこの アクセストークン を使用してリモートサービスで REST 呼び出しを行うことができます。REST サービスは、アクセストークン を抽出し、トークンの署名を検証した後、トークン内のアクセス情報に基づいて、リクエストを処理するかどうかを決定します。
1.3.2. SAML 2.0
SAML 2.0 は OIDC と同様の仕様ですが、より古く、より成熟したものです。SOAP と plethora の WS-* 仕様にはルートがあるため、OIDC よりも詳細度が少しなる傾向があります。SAML 2.0 は主に、認証サーバーとアプリケーション間の XML ドキュメント変更によって機能する認証プロトコルです。XML 署名と暗号化は、要求と応答の検証に使用されます。
Red Hat Single Sign-On SAML では、ブラウザーアプリケーションと REST 呼び出しという 2 種類のユースケースを利用できます。
SAML を使用する場合は、主に 2 つのタイプのユースケースがあります。1 つ目のアプリケーションは、Red Hat Single Sign-On サーバーがユーザーを認証するよう依頼するアプリケーションです。ログインが成功すると、アプリケーションには、ユーザーのさまざまな属性を指定する SAML アサーションが含まれる XML ドキュメントを受け取ります。XML ドキュメントはレルムによってデジタル署名され、アプリケーションでユーザーがアクセスできるリソースを判別するためにアプリケーションが使用できるアクセス情報 (ユーザーロールマッピングなど) が含まれます。
2 つ目のタイプのユースケースは、リモートサービスへのアクセスを取得するクライアントのものです。この場合、クライアントはユーザーの代わりに他のリモートサービスで起動するのに使用できる SAML アサーションを取得するよう Red Hat Single Sign-On に要求します。
1.3.3. OpenID Connect 対SAML
OpenID Connect と SAML の選択は、古い成熟したプロトコル (SAML) の代わりに新しいプロトコル (OIDC) を使用する場合でも問題はありません。
多くの場合、Red Hat Single Sign-On では、OIDC の使用を推奨します。
SAML は OIDC よりも詳細な状態である傾向があります。
交換されたデータの詳細レベルを超えた場合、SAML は Web で機能するように OIDC が Web で機能するように設計されている仕様を比較すると、Web 上で動作するように調整されました。たとえば、OIDC は、SAML よりもクライアント側に簡単に実装できるため、HTML5/JavaScript アプリケーションにも適しています。トークンは JSON 形式であるため、JavaScript による使いやすさが簡単です。また、Web アプリケーションでセキュリティーを実装するためにより優れた機能もいくつかあります。たとえば、ユーザーがログインしたままかどうかを簡単に判断するために仕様で使用されている iframe における効果的な方法 を確認してください。
SAML がその使い方もあります。OIDC 仕様が進化したように、SAML で数年以上の機能を実装することがわかります。多くの場合は、成熟度が高いため、またそれらにはセキュリティーを確保した既存のアプリケーションがすでにあるため、SAML over OIDC を選択していることがよく見られます。