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