LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

OpenAMは開発が終わったと聞いたが、いまの版はいつまで使えるのか。後継の候補が多くて違いが分からない——。社内のシングルサインオンをOpenAMで組んできた会社では、こうした迷いが起こりがちです。OpenAMは、複数のシステムへのログインを1か所にまとめるオープンソースの認証基盤です。

移行先には、OpenAMの系譜を使い続ける道も、Keycloakのような別の製品に移る道もあります。ただし万能な答えはなく、何をどうつないでいるかで向き不向きが分かれます。本記事では、情報システムの担当者に向けて、開発終了の経緯、移行先の違い、Keycloakが向く場面、移行の進め方、そして外部に頼むときに確認したい点を整理します。

OpenAMの開発終了とは

「OpenAMの開発終了」は、1つの出来事を指す言葉ではありません。OpenAMは提供元が何度か変わってきた製品で、どの系譜の話かによって意味が違います。Ping Identityの資料によると、元はSun Microsystemsの製品で、2010年にOracleがSunを買収して開発が止まったあと、ForgeRockが引き継いでOpenAMと名付けました。^*1

• OpenAMの名前で出た最後の版は、2016年の13.0.0と13.5.0です^*1
• 2017年からはAccess Managementの名前で版を重ね、ForgeRockは2023年にPing Identityの一員になりました^*1
• 2024年以降はPingAMの名前で新しい版が出ています^*1
• 国内ではOSSTech（オープンソース・ソリューション・テクノロジ）が自社版のOpenAMを提供し、修正の版を出し続けています^*2

つまり、OpenAMの名前での開発は元の開発元ではすでに終わっています。OSSTechの2026年7月のお知らせでは、脆弱性（セキュリティ上の弱点）の修正をOpenAM 14向けに出す一方、OpenAM 9・11・13と、サポートが終わったOSの上で動かしているOpenAM 14には修正を出さないとしています。^*2 対象のOSのメンテナンス期間が終わっているためです。

動かす土台にも期限があります。OpenAM 14が使っていたOpenJDK 11（Javaの実行環境）は、Red Hat Enterprise Linux同梱のものが2024年10月にサポート終了の予定だったため、OpenJDK 21で動く版が用意されました。^*3 自社のOpenAMが「どこの何番の版を、どのOSとJavaで動かしているか」を確かめることが出発点です。

移行先の選択肢の違い

自社でサーバーを持つ前提なら、OpenAMからの移り先は大きく4つに分かれます。同じ系譜を使い続ける道が3つ、別の製品に移る道が1つです。どれが合うかは、つないでいるシステムの数と種類、社内の運用体制で変わります。

表は事実の違いを並べたもので、優劣の評価ではありません。版上げを選ぶ場合も、修正が出る版とOSの組み合わせを保ち続けられるかまで見て決めます。サーバーを持たずにクラウドの認証サービス（IDaaS）へ移す道もあり、その考え方は認証基盤・IDaaS連携開発の外注で扱っています。

Keycloakへの移行が向いている場面

Keycloakは、アプリにログインの機能を付けるためのオープンソースの認証基盤です。2023年4月10日に、クラウド向けのオープンソースを育てる団体であるCNCFのプロジェクトとして、Incubating（育成段階）の位置づけで受け入れられました。^*8 公式サイトでは、主な機能を次のように説明しています。^*6

• SSO（シングルサインオン）：一度ログインすれば別のアプリに入り直さずに済み、ログアウトも1回で全部のアプリに及ぶ
• 標準の連携方式：OpenID Connect、OAuth 2.0、SAML 2.0に対応する
• 既存の利用者情報とつなぐ：LDAPやActive Directoryのサーバーに接続できる
• 外部の認証との連携：ほかのOpenID ConnectやSAML 2.0の認証基盤でログインさせられる

SAMLやOpenID Connectでクラウドサービスとつなぎ、利用者をLDAPで管理している構成なら、Keycloakの機能と重なる部分が多く、移行先の候補に挙げやすいと言えます。一方、OpenAMの代理認証（標準の連携方式に対応しない古いアプリへのログインを肩代わりする機能）^*4 に頼っているアプリがある場合は、移行先で同じつなぎ方ができるかを先に確かめます。構築の進め方はKeycloakでSSO認証基盤を外注構築で詳しく扱っています。

移行の進め方

認証基盤の移行は、社内のほぼすべてのシステムのログインに関わります。一度に全部を切り替えず、アプリを1つずつ移すと、問題が起きたときの影響を小さく抑えられます。

• ステップ1：いまのOpenAMにつないでいるアプリと、つなぎ方（SAML・OpenID Connect・代理認証など）を一覧にする
• ステップ2：利用者情報の置き場所、多要素認証やパスワードの決まりを確かめ、移行先を決める
• ステップ3：新しい認証基盤を立て、影響の小さいアプリから順に切り替えて動きを確かめる
• ステップ4：全部のアプリを移し終えたら、OpenAMを止めて、残った設定や鍵を片づける

つまずきやすいのはステップ1です。長く使ってきたOpenAMには、経緯が分からなくなった連携が残っていることがあります。切り替え後に「あのシステムに入れない」と気づかないよう、設定の一覧とアクセスの記録の両方から洗い出します。利用者情報をLDAPに置いている場合は、そのLDAPにつなぐのか、利用者情報ごと移すのかもここで決めます。

外部に頼むときに確認しておきたい点

認証基盤の移行を外部に頼む場合、作業の量よりも、切り替えの順番と止められない時間帯の扱いで結果に差が出ます。見積もりの前に次の点を確かめます。

• 調査の範囲：OpenAMにつないでいるアプリの洗い出しを、設定とアクセスの記録の両方から行うか
• 移行先の決め方：OpenAMの版上げとKeycloakなど別の製品への移行を、同じ基準で比べたうえで提案するか
• 切り替えの手順：アプリごとの切り替えの順番、元に戻すときの手順、利用者への案内を誰が作るか
• 検証の方法：多要素認証やパスワードの決まりが移行前と同じように働くことを、どう確かめるか
• 運用後の見直し：新しい版や脆弱性の修正が出たときに、誰がいつ適用するか

特に最後の点は欠かせません。移行先がKeycloakでもOpenAMの新しい版でも、版の更新が止まれば数年後に同じ悩みに戻ります。導入の時点で更新の担当と頻度を決め、運用の手順書に書いておきます。

まとめ：OpenAM移行で確かめたい3つの点

OpenAMの開発終了を受けて移行先を選ぶうえで、確かめておきたい点は3つに整理できます。第一に、自社のOpenAMがどこから入手した何番の版で、修正がまだ出ているかを確かめること。第二に、つないでいるアプリとつなぎ方を洗い出し、版上げと別の製品への移行を同じ基準で比べること。第三に、移行先でも修正の適用を誰が受け持つかを決めておくことです。この3点を踏まえておけば、「移行したのに数年後にまた同じ問題で悩む」という事態を避けやすくなります。移行先や切り替え方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：Ping Identity「PingAM Documentation：History」（https://docs.pingidentity.com/pingam/8/deployment-planning/openam-history.html）。出典：OpenSSOからOpenAM、Access Management、PingAMへの経緯と、各年の版（2016年のOpenAM 13.0.0・13.5.0など）の記述を参照（2026年10月確認）
2. *2　参考：オープンソース・ソリューション・テクノロジ株式会社（OSSTech）「OpenAM のセキュリティ脆弱性について [am2026-3-2]」（https://www.osstech.co.jp/support/am2026-3-2/）。出典：2026年7月29日のサポートニュース。OpenAM 14向けの修正の提供と、OpenAM 9・11・13およびサポート終了OS上のOpenAM 14に修正を提供しない旨の記述を参照（2026年10月確認）
3. *3　参考：OSSTech「OpenJDK 11 のサポート終了に伴う OpenAM 14 のアップデートについて [am2024-3-1]」（https://www.osstech.co.jp/support/am2024-3-1/）。出典：OpenJDK 11のサポート終了予定（2024年10月）とOpenJDK 21で動作するOpenAM 14の提供の記述を参照（2026年10月確認）
4. *4　参考：OSSTech「OSSTech OpenAM」製品紹介（https://www.osstech.co.jp/product/openam/）。出典：代理認証、OpenLDAPとの親和性などの機能説明を参照（2026年10月確認）
5. *5　参考：OpenIdentityPlatform/OpenAM（GitHub）（https://github.com/OpenIdentityPlatform/OpenAM）。出典：リポジトリの説明とライセンス（CDDL）を参照（2026年10月確認）
6. *6　参考：Keycloak 公式サイト（https://www.keycloak.org/）。出典：シングルサインオン、OpenID Connect・OAuth 2.0・SAML 2.0への対応、LDAP・Active Directoryとの接続、外部の認証基盤との連携の記述を参照（2026年10月確認）
7. *7　参考：keycloak/keycloak（GitHub）（https://github.com/keycloak/keycloak）。出典：ライセンス（Apache-2.0）を参照（2026年10月確認）
8. *8　参考：Cloud Native Computing Foundation（CNCF）「Keycloak」（https://www.cncf.io/projects/keycloak/）。出典：2023年4月10日にIncubatingの段階で受け入れられた旨の記述を参照（2026年10月確認）

Tweet