構築事例:Keycloakを活用したオンプレSSO導入
今回は、インターネットサービスプロバイダ事業者のお客様向けに、シングルサインオン(以下、SSO)の基盤を導入した事例についての記事です。お客様は、加入者向けのWEBサービスを複数展開していましたが、サービスを利用する時にサービスごとにログインが必要で、利用者にとって不便な状態であることを課題としていました。そこでデージーネットからは、既存の加入者向けサイトと連携できるよう、オンプレミス環境に導入可能なKeycloakを利用したSSOシステムの構築をご提案しました。
- お客様が悩まれていた課題
- 加入者向けのWEBサービスごとにログインが必要なため、利用者が不便
- SSOを実装したいが、ユーザの認証情報をオンプレミスのデータベースに保管しているため、クラウドのSSOサービスとの連携が難しい
- クラウドのSSOサービスを利用すると、利用者の数などで費用算定されるため高額すぎて費用対効果が薄い
- +導入企業プロフィール
- ★
導入企業業種
情報・通信
都道府県
愛媛県
ユーザー規模
16万世帯
利用OS
Red Hat Enterprise Linux 9
導入月
2025年11月
デージーネットが提案した「Keycloakを活用したオンプレSSO導入」
![]()
![]()
オンプレミス環境で利用可能なSSOシステムの導入
お客様は、複数の会員向けサイトを独自で開発していましたが、利用者がサイトを利用する際、ユーザー名や登録したパスワードの入力などによるログインが、各サービスごとに必要な状態でした。より簡単にアクセスできるよう、一度のログインで他のサービスも利用できるSSOの導入を検討していました。しかし、利用者の認証情報を含むデータベースを内部のオンプレミス環境に保有しており、そこにアカウント情報など重要なデータも含まれるため、外部サービスの利用のリスクを感じていることが背景としてありました。
そこで今回は、オンプレミス環境で導入可能なSSOの実装ソフトウェアとして、Keycloakを選定しました。Keycloakは、Red Hat社などが主導して開発を行っており、様々なアプリケーションやサービスへのサインインを一度で実行できるSSOのオープンソースソフトウェアです。Keycloakを使うことで、オンプレミス環境に独自のSSO基盤を持つことができるようになります。

Keycloakログイン画面
既存データベースとの連携
加入者向けサイトの認証情報は、お客様が保有するデータベースの中に保管されていました。Keycloakでは、デフォルトでKeycloak用のデータベースやLDAPサービスなどを使った認証はできますが、独自に作成されたデータベースでは形式が合わず認証が行えません。この点はクラウドのSSOサービスや、その他のソフトウェアを使う場合も、対応が難しい点です。一方で、お客様のデータベースを変更することは難しく、また他に認証用のデータベースを追加で構築した場合は、ユーザ情報の二重管理が発生するため、管理者の負担が増し運用が複雑化してしまいます。
この問題を解決するため、Keycloakの機能拡張用のSPI(Service Provider Interface)(※1)を使い、お客様のデータベースで認証するためのプラグインを開発することを提案しました。
(※1)SPIとは、標準機能ではカバーしきれない独自の認証フロー、ユーザ連携、トークン処理などをJavaコードで開発し、Keycloakの動作を拡張するためのプラグインフレームワークです。

SSOシステム構成イメージ
上のシステム構成イメージの通り、開発したUser storage SPIをお客様保有DBと接続させることで、独自のDBの形式でもユーザ認証に成功することができました。
OSSを利用することでコスト低減を実現
次に、お客様は費用面を課題とされていました。今回SSOを実装したいサービスは、ユーザ規模が大きく、またユーザ数の変動も予想が難しい状態でした。
一般的なSSOのサービスは、利用ユーザの数によって価格が変動するものが多くあります。例えば、1ユーザあたり「500円/月」程度の費用が発生する場合、数千から数万規模のユーザでは、単純計算で年間数百万円から数千万円のコストが発生します。また、利用者数が変動する場合、年間のコスト算定が難しく予算取りも困難になることがあります。
このような問題に対して、今回選択したKeycloakはOSSのため、ユーザ数に連動した費用は不要であり、ランニングコストを抑えることができました。なお、今回の件では初期構築費と、導入後のデージーネットが提供する保守サービスの費用のみでご提案を行い、その後も計画的に予算取りができる形としました。
導入にあたっての工夫
導入にあたって、以下を工夫しました。
会員向けサイトのSSO対応を見据えた設計
SSOの基盤を利用した場合でも、サイト側のSSOの実装方法はいくつかのパターンがあります。設計フェーズで、サイト側をどのように改修していく予定かを事前に確認しつつ、設計を行いました。その結果、今回はリバースプロキシ方式と呼ばれる方式を採用しました。これは、シングルサインオンを実現する方法の一つで、端末とWEBシステムの間に専用のサーバーを設置して認証を行う仕組みです。
この構成の場合、Keycloakと会員サイトのSSO情報の架け橋として、リバースプロキシが必要になります。リバースプロキシはお客様側でご用意いただくことになりましたが、デージーネットからリバースプロキシの設定例などの手順を説明して、お客様側の作業をスムーズに行えるような工夫を行いました。
実際の利用を想定した試験
今回の構成の要となるのは、Keycloakのプラグインとお客様保有のデータベースを使った認証です。この点のトラブルを未然に防ぐため、設計・開発の段階からデータベースの詳細な設計情報をいただき、実際の環境と齟齬がないように試験を実施しました。また、導入の最終フェーズでは現場にお伺いして、実際のデータベースを使った認証の動作確認を行いました。
導入後の結果
![]()
【Webセミナー】ISC DHCPからKea DHCPへの移行と実践セミナー~ゼロトラスト時代のDHCP運用~
| 日程: | 6月25日(木)Webセミナー「BigBlueButton」を使用します。 |
| 内容: | 今回は、開発終了を迎えたISC DHCPを背景に、DHCP運用の見直しポイントや課題を踏まえながら、次世代DHCPサーバである「Kea DHCP」と、その運用を効率化する「Kea Keeper」をご紹介します。 |
| ご興味のあるかたはぜひご参加ください。 | |
Keycloakを活用したオンプレSSO導入の関連ページ
認証サーバ構築の事例一覧
- OpenLDAPによるLDAPサーバのユーザ統合管理システム事例
- OpenLDAPによるLDAPサーバのマルチマスタ構成事例
- LDAPサーバ冗長化事例
- RADIUSサーバ事例
- CaptivePortalを利用したSNS認証事例
- Google AuthenticatorとFreeRADIUSを使ったOTP認証事例
- daloRADIUSを使用したRADIUSサーバ事例
- 389 Directory Serverを利用したLDAPサーバ事例
- OpenXPKIを利用したプライベート認証局事例
- Nginxを利用したクライアント認証サーバ導入事例
- FreeRADIUSを利用した認証サーバ事例
- Amazon Linux 2へ認証サーバOSの移行事例
- Keycloakを利用したシングルサインオン認証サーバの導入事例
- 管理の負担を軽減したKeycloakによるシングルサインオンサーバ構築事例
- 多要素認証にTOTPを利用したKeycloakサーバ導入事例
- Keycloakを利用したRoundcubeのSSO連携事例
- FreeRADIUSとOpenXPKIで実現した電子証明書による認証システム事例
- Keycloakを活用したオンプレSSO導入事例



