CASE SD-02

現行基盤は OpenAM に依存し、対応する Java のバージョン制約から数年以内に維持が難しくなる見通しでした。一方で、認証基盤は全社の業務システムの入口にあたるため、「止めずに入れ替える」ことが前提条件でした。

連携システムは約 20。SAML／OIDC の標準連携だけでなく、代理認証やパスワード有効期限のチェック、ユーザー情報のプロビジョニングなど、現行基盤に作り込まれた固有機能を Keycloak 側で引き継ぐ必要がありました。

要件定義は「現行の設計書に記載された機能を確認する」ことが起点です。記載と実際の挙動の差分や、記載のない運用上の前提をどこまで拾えるかが、移行後のトラブルを左右します。

移行方式は「Keycloak を OpenAM の SP（サービスプロバイダー）として SAML 連携させ、連携システムを 1 つずつ Keycloak 側へ付け替える」段階切替を採用。全システムの移行が完了した時点で Keycloak を IdP として独立させ、最後にデスクトップ SSO（Windows 統合認証）を設定する流れとしました。切替の途中でも利用者は同じ入口からログインでき、問題が出たシステムだけを戻せます。

要件定義・基本設計は、現行基盤の設計書と元請け SIer の提案書を突き合わせ、機能ごとに「Keycloak 標準で実現」「拡張開発で実現」「移行時に廃止」を仕分けする形で進めています。記載にない前提はヒアリングで確認し、記載外の機能は別途扱いとして範囲を明確にしました。

開発・ステージング環境は当社の Azure 上に構築。Keycloak サーバー 2 台（PostgreSQL 同居）、ロードバランサー、リバースプロキシの 4 台構成で、接続元 IP 制限、個人別アカウント、平日日中のみの自動起動・停止（祝日判定あり）を設定し、コストと統制の両方を確保しています。本番は、お客様のオンプレミス仮想基盤上に RHEL／Keycloak／PostgreSQL の HA 構成（Pacemaker＋Corosync）で構築する計画です。

検収は要件定義、設計、開発、移行設計、移行の 5 フェーズに分割し、フェーズごとに成果物を確定させながら進めています。