標準化でシステム間のファイル連携を考える時、標準準拠システムが AWS 同士ならば AWS の認証認可の仕組みを使ってオブジェクトストレージ S3 で比較的簡単にファイルを連携できます。しかし、標準準拠システムが AWS とその他の CSP で構成されていたり、オンプレミスと AWS との間でファイル連携が必要だったりする場合、地方公共団体情報システム認証機能・ファイル連携機能に関するリファレンス（推奨指針）ガイド によると認証認可サーバを自前で構築する必要があるとされています。
標準準拠システムのファイル連携における認証認可サーバのため、認証認可サーバは閉域内に設置する必要があります。閉域内で使える認証認可サーバとして、オープンソースの Keycloak を採用することが多いようです。
そこで、閉域内に Keycloak をテストで構築し、AWS マネージメントコンソールに SSO する手順を試すことで、Keycloak の動作を学んでみたいと思います。
なお、実際にガバメントクラウド環境で Keycloak を導入する場合、閉域内から AWS マネージメントコンソールにアクセスすることはできません。ファイル連携の認証認可サーバとして Keycloak を使うには、別途クレデンシャルから必要な情報を抜き出し、閉域内で S3 へのアクセスに使う仕組みを構築する必要があると思います。
今回は実際にガバメントクラウドで使える手順にはなっていないのでお気を付けください。また、セキュリティも一切考慮していないテストのため、実運用時はしっかりセキュリティ対策を行う必要があります。
Keycloak の事前設定
Keycloak を Docker で起動する
Keycloak をテストするのに一番簡単なのは、Keycloak は公式の Doceker イメージを使うことかと思います。
今回、プライベートサブネットのみの VPC に Amazon Linux の EC2 を立て、Docker を使えるようにしました。AWS に閉域環境を作る手順は過去に記事にしているので興味があれば参照してください。
詳細な手順は省略しますが、インターネットアクセス可能な環境で Keycloak の Doceker イメージを pull し、SCP で Docker イメージを転送し、EC2 側の Docker で load しました。公式の手順は以下のとおりです。
以下のコマンドで TCP 8080 番でサービスが上がり、ユーザー名とパスワードが admin で Keycloak の管理コンソールにアクセスできるようになります。
$ docker run -p 8080:8080 -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.1.0 start-dev
Client の設定
Doceker イメージが正常に起動したら、作業用のクライアントから、SSH ポートフォワーディングでクライアントのローカルホストから閉域の EC2 の Keycloak の TCP 8080 番ポートにアクセスできるようにし、ブラウザでアクセスし、ログインします。
https://signin.aws.amazon.com/static/saml-metadata.xml から SAML メタデータ（XML）をダウンロードしておきます。
「Clients」から「Import Client」に進み、上記の XML ファイルをアップロードして「Save」します。
次の画面で以下のとおり設定します。
| Item | Value |
|---|---|
| Root URL | http://localhost:8080 |
| Home URL | /realms/master/protocol/saml/clients/aws-saml |
| Valid Redirect URIs | https://signin.aws.amazon.com/saml |
| IDP-Initiated SSO URL name | aws-saml |
SAML 2.0 Identity Provider Metadata のダウンロード
「Realm Settings」から「SAML 2.0 Identity Provider Metadata」をダウンロードします。
次に AWS マネージメントコンソール側で ID プロバイダなどの設定をしていきます。
IAM の設定
ID プロバイダの追加
マネージメントコンソールから「IAM」→「ID プロバイダの追加」に進みます。
先の手順でダウンロードした SAML 2.0 Identity Provider Metadata の XML ファイルをアップロードします。
IAM ロールの割り当て
作成した ID プロバイダに IAM ロールを割り当てます。
テストなので、新規に S3ReadOnlyAccess ポリシーをセットしたロールを作成して割り当てました。
任意のロール名を設定します。
IAM ロールの設定が終わったら、ID プロバイダと IAM ロールのそれぞれの ARN をコピーしておきます。後で Keycloak の設定に使います。
Keycloak の 設定
Role の作成
「Clients」から「urn:amazon:webservices」→「Roles」→「Create Role」へ進みます。
「Role Name」に先ほどコピーした IAM ロールの ARN、カンマ、ID プロバイダの ARN の順で繋げた文字列を入力します。
次に「Client Scopes」に進みます。表示されている「Assigned client scope」から「role_list」を削除しておきます。
次に表示されている「Assigned client scope」から「urn:amazon:webservices-dedicated」→「Mappers」のに進みます。
表示されている一覧の項目を一旦全部消したら、「Add Mapper」→「By Configuration」に進みます。
「User Property」と「Role list」を作成していきます。
まずは「User Property」です。
| Item | Value |
|---|---|
| Mapper Type | User Property |
| Name | Session Name |
| Property | username |
| Friendly Name | Session Name |
| SAML Attribute Name | https://aws.amazon.com/SAML/Attributes/RoleSessionName |
次に「Role list」です。
| Item | Value |
|---|---|
| Mapper Type | Role list |
| Name | Session Role |
| Role Attribute Name | https://aws.amazon.com/SAML/Attributes/Role |
| Friendly Name | Session Role |
Mappers の設定が終わったら「Scope」へ進み、「Full scope allowed」を「off」にします。
Group の作成
Keycloak で認証するユーザーを作成していきます。先にユーザーを所属させるグループを作成します。
「Groups」から「Create Group」に進み、任意のグループ名でグループを作成します。
グループを作成したら、このグループの詳細設定から「Role Mapping」→「Assign Role」に進みます。
先の手順で作成した「urn:amazon:webservice」になっているロールを「Assign」します。
User の作成
「Users」から新規ユーザーを作成します。先ほど作成したグループに所属するよう設定し、任意の名前でユーザーを作成します。
ユーザーを作成したら、このユーザー詳細設定から「Credentials」→「Set password」に進み、適当なパスワードを設定します。
ここまで来たら Keycloak の設定は完了です。早速 AWS のマネージメントコンソールに Keycloak を使った SSO ができるか試してみましょう。
Keycloak の URL から作成したユーザーでログインする
一旦 Keycloak の管理コンソールからログアウトします（重要）。そのままだと admin というユーザーで SSO しようとして当然ですが失敗します。
ログアウトしたら http://localhost:8080/realms/master/protocol/saml/clients/aws-saml にブラウザでアクセスします。
AWS のマネージメントコンソールにリダイレクトされ、フェデレーテットユーザーとして紐づけられた IAM ロールの権限でアクセスできていれば成功です。
分かったことなど
SAML 2.0 を使った認証であれば、Keycloak で作成した公開鍵を AWS の ID プロバイダに設定しているので、AWS 環境から Keycloak にアクセスできなくても認証ができるため、閉域のオンプレミスなどに Keycloak を構築する方法でもよいことが分かりました。
ガバメントクラウドのファイル連携で、他 CSP やオンプレミスから S3 にアクセスするために AWS の認証認可が使えない場合は、他 CSP、オンプレミスからアクセスできる閉域内に Keycloak などの IdP を構築する必要がある理由が腹落ちしました。
実際に SAML 認証で得たクレデンシャルを使って S3 にアクセスするアクセスキーを取り出すためには、もう一歩踏み込まないとならないですが、かなり難しそうなので検証は一旦ここまでにしたいと思います。
参考サイト