こんにちは、アプリケーションサービス本部の上田です。 最近本当に寒すぎて朝起きるのも億劫なので早く暖かくなってほしいです。
さて、前回からだいぶ期間が空いてしまいましたがKeycloakを接続していきます！ ちなみに前回の記事はこちら
blog.serverworks.co.jp blog.serverworks.co.jp
今回はAWSマネジメントコンソールを紐づけてみますが、その前に頻出する用語を整理しておきます。
用語整理
SSO（Single Sign-On）
連携したサービスであれば一度のログインで他のサービスにもログインできるような仕組みのことです。 SSOのプロトコルはSAMLとOIDCの２種類存在しますが、今回はSAMLを扱います。 それぞれの違いは以下のようなものです。
SAML…XMLベース、仕様がOIDCに比べると少し複雑 OIDC…Jsonベース、仕様自体はシンプルだがアプリケーションによっては適切な認可フローを使用できない場合がある
SAML
SAML（Security Assertion Markup Language）と呼ばれ、SSOを実現するための仕組みの一つです。 図のような流れで認証のやり取りを行います。
SP (Service Provider)
サービスを提供する側（アプリケーション）のことです。 例えば、Webアプリケーション、SaaS、VPN、VDI などが該当します。 IdP から提供された認証情報に基づいて、ユーザーがサービスを利用できるようにします。
IdP（Identity Provider）
ユーザーの認証情報（ID、パスワードなど）を一元的に管理し、SP に対してユーザーの身元を証明する役割を担います。 SP からの認証要求を受け付け、ユーザーの認証を行い、その結果を SP に伝えます。
では早速実践してみましょう。 今回の作業は以下の流れとなります。
IdPの設定
IdPとなるKeycloakを準備する
まずはIdPを作成します。今回はtest_realmというレルム（Keycloakの管理の単位）を作りその中で設定・管理していきます。
メタデータを取得する
SPのメタデータを取得します。メタデータを使用することでIdPに登録するときにいい感じに情報を設定してくれます。 AWSマネジメントコンソールとSAML連携する場合はAWSが提供しているURLからメタデータを取得できます。
次のステップで使うのでローカルに保存しておきましょう。
https://signin.aws.amazon.com/static/saml-metadata.xml
IdPにクライアントを作成する
AWSコンソールをSPとして登録するためにクライアントを作成します。 通常はメタデータがない場合はCreate Clientからクライアントを作成しますが今回はメタデータを取得しているのでファイルを読み込んで作成します。
ファイルを読み込むと勝手に情報が入力されるので説明やわかりやすいように名前を付けて保存します。
作成されると自動的にクライアントの詳細画面に遷移するので、アクセス関連の値を入力します。
クライアントの設定を行う
クライアントの詳細画面にて以下を参考に値を設定します。
RootURL： http://keycloakホスト名orIPアドレス:8080
Home URL /realms/master/protocol/saml/clients/aws-saml
IDP Initiated SSO URL Name： aws-saml
ここまでで一旦クライアントの設定は終わりで、次にSP側の設定を行います。
SP側でもメタデータを使って設定を行うので、Keycloak側のメタデータを取得します
SPの設定
IDプロバイダを設定する
マネジメントコンソールからIDプロバイダの作成画面に遷移します。
プロバイダがSAMLになっていることを確認し、適当な名前を付けて先ほど取得したKeycloakのメタデータをインポートします。 インポートが完了したらプロバイダを追加します。
ロールの新規作成と割り当てを行う
先ほどの画面でプロバイダを作成すると、ロールの割り当ても行う？と通知が出てくるのでそこからロールの新規作成と割り当てを行います。
基本的に続けて作る場合は勝手に選択されているはずだが一応SAMLが選択されているかチェックします。
許可されるアクセスは「プログラムとAWSマネジメントコンソールへのアクセスを許可する」を選択します。
サインインエンドポイントでは東京リージョンを選択しておきます。
次に付与するポリシーを選択します。
今回はAdministratorAccessを選択していますが、適宜適切なアクセスポリシーを付与してください。
ロール名を設定し、紐づけ完了です。
最後にロールの信頼関係を確認し、Condition セクションに適切な saml:aud 条件 (https://signin.aws.amazon.com/saml) が設定されていることを確認します。入ってなければ追加します。
ここでIDプロバイダとロールのARNをそれぞれ控えておきます。
理由はこの後IdPの設定を行う際に使用するためです。
IdPのクライアント詳細設定を行う
さて、今度はAWS側プロバイダの情報とIdPのSPクライアント情報を紐づけるために設定を行います。
クライアントのRole設定
まずはクライアントのロール設定に移動し、「Create Role」を押下します。
Role nameの項目に「ロールのARN,プロバイダのARN」の順番で記述します。
クライアントのClient scopes設定
Client scopesのタブから設定画面に移動し、デフォルトで設定されていいる「role_list」を削除します。
その後クライアントの名前のついているスコープがあるのでクリックしてMapper編集に移ります。
スコープのMapper設定
デフォルトで入っていたMapperはAWSからダウンロードしたSaml-metadata.xmlに入っていた情報のため、一旦すべて削除します。
必須はRoleSessionNameとRoleですが、初期状態ではkeycloak側の情報をうまくSAML Responseに渡せないためこれも消しておきます。
全件削除を確認したら「Create」をクリックし新規のMapperを作成します。
必須のRoleSessionNameとRoleを作成します。 それぞれRole listとUser Propertyが相当するので作っていきます。
まずはRole listを作成します。
次につぎにUser Propertyを作成。
隣のタブの「Scope」に移って、「Full scope allowed」を「off」にします。
ユーザーグループの作成
次はオプション的な設定ですが、この設定をユーザーグループ化しておきます。
ユーザーグループ化しておくことで複数のユーザーに対して同じ設定を適用できます。
左側メニューのManage＞Groupsからグループを作成。
作成したグループの「Role mapping」から「Assign role」で先ほど作成したロールをアサインします。
IdPでユーザーの作成
最後にユーザーをIdPに作成します。 Groupsから先ほど作成したグループを設定します。
作成したままだとクレデンシャル情報が何も設定されていないので適当なパスワードを設定してやります。
お疲れさまでした！これで準備完了です！
動作確認
以下のような形になっているSAML認証URLにアクセスします。
http://（Keycloakのホストドメイン）/realms/test_realm/protocol/saml/clients/aws-saml
認証画面が出るため、先ほど作成したユーザーの情報を入力します。
マネジメントコンソールにアクセスできました！
まとめ
接続編ということで今回は実際のサービス接続の部分までを行いました。
設定することはそこそこ多いのですが、やってみるとそこまで大変ではなく一回設定してグループ化してしまえば管理はしやすいかなと考えています。
KeycloakはOSSでありながらも高機能でカスタマイズ性も高く、無料で利用できることから認証・認可に関して勉強してみたり動かしてみるには非常に良いツールだと感じました（個人的にGUIがわかりやすいのもとっつきやすいポイントかなと思います）。
今後も引き続きKeycloakの勉強のアウトプットをしていければと考えているので、何らかの記事がどなたかの学習の足掛かりになれば幸いです。
ここまでお読みいただきありがとうございました。
