こんにちはアプリケーションサービス本部の上田です。
GWはいかがお過ごしでしたでしょうか？ 私はどこ行っても混むだろうなと思ってGW中に家の大掃除をしたり積みゲーを崩したりインドアに過ごしていました。
今回は前回導入したKeycloak使う前に、用語の整理をしておこうと思います。
ちなみに前回の記事はこちら
- Realm（レルム）
- User（ユーザー）
- Role（ロール）
- Group（グループ）
- Client（クライアント）
- Protocol Mapper（プロトコルマッパー）
- Client Scope（クライアントスコープ）
- まとめ
Realm（レルム）
Keycloak内で使用されている用語でユーザー、ロール、接続するデータストア（LDAPなど）をまとめるための独立した管理領域を意味しています。
ユーザーはレルム内に作成することができ、認証の方法などをレルム単位で定義することができます。 デフォルトでは「master」レルムが作られています（前回管理ユーザーを設定していたのもここ）。
Masterレルムは最も高いレベルのレルムであり、基本的には別レルムを作成しその中でユーザー情報を管理するようにする必要があります。
例えるなら、マンションの各部屋 のようなものです。
- マンション全体 (Keycloak サーバー) が、認証・認可の機能を提供する Keycloak サーバー本体です。
- 個々の部屋 (レルム) は、それぞれ独立した住人 (ユーザー)、ルール (ロール)、サービス (クライアント) を持っています。ある部屋の住人は、別の部屋の住人に直接影響を与えません。Masterレルムは管理人室みたいな感じですね。
User（ユーザー）
認証の対象となるユーザーのことです。Keycloak内ではユーザーそれぞれに一意に識別するためのユーザーIDが割り当てられており、ユーザーに関する情報はすべてこのユーザーIDに関連付けられて管理されています。
ユーザー属性としてはユーザー名、メールアドレスなどが標準で用意されており任意の属性を追加することも可能です。
ユーザー管理のための画面は2種類あり、管理コンソールから各ユーザーの情報を確認・編集できる「User」画面と、ユーザー自身が自分の情報を管理するアカウント管理コンソールの2種類があります。
例えるならマンションに住む 住人 そのものです。
- 住人（ユーザー） は、マンション (Keycloak) のサービスを利用するために登録された個人です。
- 各住人 は、自分の部屋 (レルム内のアカウント) を持ち、名前や連絡先などの個人情報（ユーザー属性）を持っています。
- マンションのルール (レルムの設定) に従って、共用スペース (アプリケーション) を利用したり、特定の役割 (ロール) を持ったりします。
Role（ロール）
Keycloakのロールは同じアクセス制御を行うユーザーを識別するために使います。
典型的な例としてはAdmin（システム管理者）、ユーザー（利用者）、Manager（管理者）などです。ちなみに、このロールを使ってアクセス制御する方法はRBAC（Role-Based Access Control）と呼ばれます。
このロールには以下の3種類があります。
・レルムロール（レルム単位に定義できるロール＝全クライアント共通のロール）
・クライアントロール（クライアント単位に定義できるロール）
・複合ロール（他のロールを継承した複合的なロール）
例えるならマンション内での 役割や権限 です。
- 役割（ロール） は、例えば「管理人」「清掃員」「居住者」のように、マンション内で特定の行動やアクセスが許可される立場を表します。
- 住人 は、複数の 役割 を持つことができます。例えば、「居住者」でありながら「自治会長」の役割を持つ人もいます。
- 役割 によって、利用できる共用施設 (アプリケーションの機能) や、操作できる範囲が異なります。
Group（グループ）
グループを設定することで、そのグループに設定された属性やロールをまとめてユーザーにマッピングすることが可能です。グループ同士は親子関係も設定することができます。
例えるならマンション内の 特定の集団やコミュニティ です。
- グループ は、例えば「居住者グループ」「管理者グループ」のように、共通の属性や目的を持つ 住人 の集まりです。
- グループ に所属することで、そのグループに共通の 役割 をまとめて付与したり、特定の情報やリソースへのアクセス権を一括で管理したりできます。
Client（クライアント）
Keycloakにおけるクライアントは認証・認可サーバーであるKeycloakのサービスを利用する各アプリケーションのことを指します。
クライアントは利用するプロトコルに応じてClient Type（クライアントタイプ）が異なり、それぞれOIDC（OpenID Connect）とSAMLの2種類があります。
例えるならマンション内の 様々なサービスや設備 です。
- クライアント は、例えば「共用広場」「宅配ボックス」「フィットネスジム」「掲示板」のように、住人 が利用するアプリケーションやサービスを表します。
- 各サービス は、誰が利用できるのか、どのような操作ができるのかといったアクセス制御が必要です。
- Keycloak は、これらの クライアント に対して、誰が (ユーザー)、どのような権限で (ロール) アクセスできるのかを管理します。
Protocol Mapper（プロトコルマッパー）
Keycloak の内部的なユーザー情報やロール情報を、OAuth 2.0 や OpenID Connect などの標準プロトコルでやり取りされる トークン内の情報に変換する仕組み です。
プロトコルマッパーはクライアント単位で設定します。
- 例えるなら、「住人情報リスト (Keycloak 内部情報)」を「宅配便の宛名ラベル (トークン内の情報)」や「ジムの会員証に記載される情報 (トークン内のクレーム)」のように、外部のサービスが理解できる形式に翻訳する役割です。「氏名」という情報を、あるサービスには「name」という項目で伝え、別のサービスには「full_name」という項目で伝えるといった具合に、情報の形式を調整します。
- プロトコルマッパー の設定によって、トークンに含めるユーザー属性 (名前、メールアドレスなど) やロール情報を細かく制御できます。これにより、各 クライアント (サービス) は、必要なユーザー情報を適切な形式で安全に受け取ることができます。
Client Scope（クライアントスコープ）
クライアント が ユーザー の情報にアクセスする際の 範囲や許可 です。
先ほどのプロトコルマッパーはクライアント単位に設定することが可能ですが、逆に言うと複数のクライアントに設定する場合は一つ一つ行う必要があります。
そこで複数のクライアントで共通のマッピング設定を行う方法としてクライアントスコープを設定できます。クライアントスコープはプロトコルとしてOAuth／OIDC用とSAML用があり、各スコープにプロトコルマッパーを設定することができます。
なので共通する設定はクライアントスコープにまとめて、固有の要件がある場合は個別のプロトコルマッパーをクライアントに設定する、といった運用に使用できます。
- クライアントスコープ は、例えば「氏名とメールアドレスのみ」「氏名、メールアドレス、電話番号」のように、クライアント (サービス) が ユーザー (住人) のどの個人情報まで取得できるかを定義するものです。
- サービスごとに必要な情報だけを開示することで、プライバシー保護を高めることができます。
- クライアント は、利用する クライアントスコープ を指定することで、必要な範囲のユーザー情報を取得できます。
まとめ
というわけで今回は自分の中での整理もかねて用語の解説を行いました。
次回はいよいよ各サービスと繋げてSSOを実現してみます。
ここまでお読みいただきありがとうございました。
