1.3. コアとなる概念および利用規約

Web アプリケーションと REST サービスのセキュリティーを保護するには、Red Hat Single Sign-On の使用を試行する前に、いくつかの主要な概念と用語を認識する必要があります。

ユーザー
ユーザーは、システムにログインできるエンティティーです。電子メール、ユーザー名、アドレス、電話番号、および日目などの属性を関連付けることができます。グループメンバーシップを割り当てることができ、特定のロールをそれらに割り当てることができます。
認証
ユーザーを特定し、検証するプロセスです。
認可
ユーザーに付与するプロセスです。
認証情報
認証情報は、Red Hat Single Sign-On がユーザーの ID を検証するために使用するデータの一部です。たとえば、パスワード、ワンタイムパスワード、デジタル証明書、またはフィンガープリントなどが挙げられます。
ロール
ロールはユーザーのタイプまたはカテゴリーを識別します。Admin、user、manager、employee は、組織に存在する可能性のある通常のロールすべてです。アプリケーションは通常、多くの場合、個々のユーザーではなく、特定のロールにアクセスおよびパーミッションを割り当てます。これは、ユーザーの処理は複雑で、管理が困難となるためです。
ユーザーロールのマッピング
ユーザーロールのマッピングは、ロールとユーザー間のマッピングを定義します。ユーザーをゼロ以上のロールに関連付けることができます。このロールマッピング情報は、アプリケーションが管理するさまざまなリソースのアクセスパーミッションを決定することができるように、トークンとアサーションにカプセル化できます。
複合ロール
複合ロールは、他のロールに関連付けることができるロールです。たとえば、superuser の複合ロールを sales-admin ロールおよび order-entry-admin ロールに関連付けることができます。ユーザーが superuser ロールにマップされている場合は、sales-admin ロールおよび order-entry-admin ロールも継承されます。
グループ
グループはユーザーのグループを管理します。グループに対して属性を定義できます。ロールをグループにマッピングすることもできます。グループのメンバーになるユーザーは、そのグループで定義される属性とロールマッピングを継承します。
レルム
レルムは、一連のユーザー、認証情報、ロール、およびグループを管理します。ユーザーはレルムに属し、レルムにログインします。レルムは相互に分離され、制御するユーザーのみを管理および認証できます。
クライアント
クライアントは、Red Hat Single Sign-On を要求してユーザーを認証できるエンティティーです。多くの場合、クライアントは Red Hat Single Sign-On を使用して自己保護し、シングルサインオンソリューションを提供するアプリケーションとサービスです。クライアントは、ID 情報またはアクセストークンを要求するエンティティーで、Red Hat Single Sign-On によってセキュア化されるネットワーク上でその他のサービスを安全に呼び出すことができるようにすることもできます。
クライアントアダプター
クライアントアダプターは、アプリケーション環境にインストールするプラグインで、Red Hat Single Sign-On の通信およびセキュア化を可能にします。Red Hat Single Sign-On には、ダウンロード可能なさまざまなプラットフォームに多くのアダプターがあります。また、サードパーティーのアダプターも、対象外の環境で取得できます。
consent
Consent は、クライアントが認証プロセスに参加する前に、ユーザーにクライアントにパーミッションを付与する場合です。ユーザーがクレデンシャルを提供すると、Red Hat Single Sign-On がログインを要求するクライアントを特定する画面と、ユーザーの要求情報を確認する画面が表示されます。ユーザーは、要求を付与するかどうかを決定できます。
クライアントスコープ
クライアントが登録されたら、そのクライアントのプロトコルマッパーとロールスコープマッピングを定義する必要があります。多くの場合、クライアントスコープを保存し、共通の設定を共有することで新しいクライアントの作成を簡素化します。これは、一部の要求またはロールを scope パラメーターの値に基づいて条件付きで要求する場合にも便利です。Red Hat Single Sign-On では、このクライアントスコープの概念が提供されています。
クライアントロール
クライアントは、それら固有のロールを定義できます。これは基本的に、クライアント専用のロール名前空間です。
ID トークン
ユーザーに関する情報を提供するトークン。OpenID Connect 仕様の一部。
アクセストークン
呼び出されるサービスへのアクセスを付与する HTTP リクエストの一部として提供できるトークン。これは、OpenID Connect および OAuth 2.0 仕様の一部です。
アサーション
ユーザーに関する情報。これは通常、認証されたユーザーに関連するアイデンティティーメタデータを提供する SAML 認証応答に含まれる XML Blob に関連します。
サービスアカウント
各クライアントには、アクセストークンの取得を可能にする組み込み service account があります。
直接付与
REST 呼び出しでユーザーの代わりにアクセストークンを取得する方法。
プロトコルマッパー
各クライアントについて、OIDC トークンまたは SAML アサーションに保存される要求とアサーションを調整できます。プロトコルマッパーを作成および設定して、クライアントごとにこれを行います。
セッション
ユーザーがログインすると、セッションがログインセッションを管理します。セッションには、ユーザーがログインした時や、そのセッション中に単一署名に参加したアプリケーションなどの情報が含まれます。管理者およびユーザーの両方がセッション情報を表示できます。
ユーザーフェデレーションプロバイダー
Red Hat Single Sign-On はユーザーを保存して管理できます。多くの場合、ユーザーと認証情報を格納する LDAP または Active Directory サービスがすでにあります。Red Hat Single Sign-On を示すことで、外部ストアから認証情報を検証して ID 情報にプルすることができます。
アイデンティティープロバイダー
アイデンティティープロバイダー (IDP) はユーザーを認証できるサービスです。Red Hat Single Sign-On は IDP です。
ID プロバイダーフェデレーション
Red Hat Single Sign-On は、1 つ以上の IDP に認証を委譲するように設定できます。Facebook または Google+ でのソーシャルログインは、アイデンティティープロバイダーのフェデレーションの例です。また、Red Hat Single Sign-On のフックを行い、認証を他の OpenID Connect または SAML 2.0 IDP に委任することもできます。
ID プロバイダーマッパー
IDP フェデレーションを行う場合は、受信したトークンとアサーションを user および session 属性にマッピングできます。これは、外部の IDP から認証を要求するクライアントに ID 情報を伝播するのに役立ちます。
必要なアクション
必要なアクションは、ユーザーが認証プロセス中に実行する必要のあるアクションです。ユーザーは、これらのアクションが完了するまで認証プロセスを完了できません。たとえば、管理者はユーザーが毎月パスワードをリセットできるようにスケジュールすることが可能です。これらの全ユーザーに対して、update password に必要なアクションが設定されます。
認証フロー
認証フローは、システムの特定の側面と対話するときにユーザーが実行する必要のあるフローです。ログインフローは必要な認証情報タイプを定義できます。登録フローは、ユーザーが入力しなければならないプロファイル情報や、ボットをフィルターするのに reCAPTCHA などのプロファイル情報を定義します。認証情報リセットフローは、パスワードをリセットする前にユーザーが行うべきアクションを定義します。
イベント
イベントは、管理者が表示やフックを表示できる監査ストリームです。
テーマ
Red Hat Single Sign-On が提供するすべての画面は、テーマでサポートされます。テーマは、必要に応じて上書きできる HTML テンプレートとスタイルシートを定義します。