LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Keycloakとは何か・SSO認証基盤の基本像

Keycloakとは、複数の業務システムやWebアプリケーションの認証・認可を1つの基盤に集約するオープンソースのIAM（Identity and Access Management、アイデンティティ・アクセス管理）製品を指します^*1。利用者はKeycloakにログインすると、連携済みの各アプリケーションへ個別にログインし直さずにアクセスできるようになります。

この仕組みは一般にSSO（シングルサインオン）と呼ばれ、Keycloakは認証サーバーとして各アプリケーションの手前に立ち、ログイン処理を代行する構成を取ります^*1。アプリケーション側はパスワードそのものを扱わず、Keycloakが発行する署名済みトークンで利用者を識別する仕組みです。

社内の複数業務システムやグループ会社間で認証を一元化したい企業にとって、KeycloakはライセンスコストをかけずにSSO基盤を構築できる選択肢になります。ただしサーバー運用は自社（またはパートナー企業）が担うため、外注か内製かの判断が導入初期の大きな論点となります。

レルム・クライアント・ロールという3つの管理単位

Keycloakの設定を理解するうえで欠かせないのが、レルム（realm）・クライアント（client）・ロール（role）という3つの管理単位です。レルムはユーザー・認証情報・ロール・グループの集合を管理する領域で、レルムどうしは分離されており、それぞれ自分が管理するユーザーしか認証できません^*1。

1つのKeycloakサーバー内に複数のレルムを作成できるため、部門やグループ会社ごとにレルムを分けて管理することも可能です。たとえば社内向けシステム用レルムと、取引先向けポータル用レルムを分離すれば、ユーザー基盤や認証ポリシーを独立させられます。

クライアントは「Keycloakに認証を要求できるエンティティ」を指し、多くの場合はSSOで保護したいアプリケーションやサービスそのものが該当します^*1。ロールは「admin」「manager」「employee」のようなユーザーの区分で、アプリケーション側はユーザー個人ではなくロールに対して権限を割り当てる設計が一般的です^*1。グループはユーザーの集合体で、グループに属性やロールマッピングを設定すると、メンバーであるユーザーへその設定が継承されます^*1。

この3階層を正しく設計できるかどうかが、SSO基盤の運用しやすさを大きく左右します。レルム分割の粒度を誤ると、後からユーザーやクライアントの移行作業が発生し手間が増えるため、初期設計の段階で組織構造とレルムの対応を検討する必要があります。

OpenID ConnectとSAML、2つの標準プロトコル対応

Keycloakは認証プロトコルとしてOpenID Connect・OAuth 2.0・SAML 2.0を標準でサポートします^*2。OpenID Connect（OIDC）は、OAuth 2.0^*3という認可の仕組みの上に構築されたシンプルなアイデンティティ層で、クライアントが認可サーバーによる認証結果に基づいて利用者本人であることを確認し、基本的なプロフィール情報を取得できるように設計された標準です^*4。

SAML（Security Assertion Markup Language）2.0はXMLベースの認証・認可の標準規格で、OpenID Connectより古くから企業のSSO用途で使われてきました。Keycloakはクライアント登録時にプロトコルとしてOpenID ConnectまたはSAMLのいずれかを選べるため、モダンなSPA・モバイルアプリはOIDCで、レガシーな業務パッケージやSAML専用のSaaSはSAMLで接続するといった併用構成が組めます^*2。

この2プロトコル対応こそがKeycloakの実務的な強みです。新規開発のアプリケーションはOIDCで軽量に接続し、既存のSAML対応SaaS（グループウェアや人事システムなど）はそのままSAMLクライアントとして取り込めるため、システムの新旧を問わず同じ認証基盤に統合しやすくなります。

複数アプリを1回のログインでつなぐSSOの仕組み

SSOの実際の動作は、利用者が保護対象のアプリケーションにアクセスした時点でKeycloakのログイン画面にリダイレクトされ、認証が完了するとアプリケーション側へ署名済みトークンとともに戻される、という流れです。2つ目以降のアプリケーションにアクセスした際は、Keycloak側にすでに有効なセッションがあるため、再度の資格情報入力なしにトークンが発行されます。

Keycloakはブラウザアプリケーションに対するシングルサインオンとシングルサインアウトの双方を提供しており、1回のログアウト操作で連携している全アプリケーションからログアウトさせる制御も可能です^*2。これにより、退職者や異動者のアカウント無効化を一箇所で完結させられる利点があります。

一方で、SSOを導入すると認証基盤自体が単一障害点になりやすい点は見落とせません。Keycloakが停止すると連携する全アプリケーションへのログインが止まるため、可用性確保の設計は避けて通れない検討事項です。この点は本稿の後半（セルフホスト運用の章）で扱います。

ソーシャルログイン・外部IdP連携によるID統合

Keycloakには、外部のOpenID ConnectまたはSAML 2.0対応のIdP（Identity Provider、識別情報提供者）と連携する「アイデンティティブローカリング」という機能があります^*2。この機能により、GoogleやGitHub、Facebookなど外部サービスのアカウントでログインさせるソーシャルログインを設定できます^*2。

企業システムの文脈では、ソーシャルログインよりも他システムとのID連携で使われる場面が多くなります。たとえば取引先企業が別のIdPを運用している場合、そのIdPをKeycloakに登録すれば、取引先の利用者は自社アカウントのまま自社ポータルへログインできます。認証そのものは相手側のIdPが行い、Keycloakはブローカー（仲介者）としてトークンを中継する構成です。

加えて、KeycloakにはLDAPやActive Directoryと連携するユーザーフェデレーション機能もあります。既存のディレクトリサービスにあるユーザー情報を移行せずに、Keycloakがパスワード検証時にLDAP側へ問い合わせる構成や、属性を取り込んでローカルにも保持する構成を選べます。社内に既存のADがある企業では、この機能を使うことで二重管理を避けられます。

外部IdP連携やLDAP接続は、設定項目自体はさほど多くありませんが、相手システムの仕様（証明書形式・属性マッピング・SAMLのNameID形式など）に応じた調整が必要になり、切り替え時の疎通確認には相応の時間がかかります。接続先が複数ある場合は、テスト環境での事前検証を丁寧に行うことが望まれます。

多要素認証とパスワードポリシーの設定

Keycloakは二要素認証として、パスキー・リカバリーコード・Google AuthenticatorやFreeOTPを使ったTOTP/HOTP（時刻またはカウンタに基づくワンタイムパスワード）をサポートしています^*2。これらは認証フロー（Authentication Flow）という設定単位で、どのステップで多要素認証を要求するかを柔軟に組み立てられます。

パスワードポリシーについても、文字種・長さ・有効期限・履行済みパスワードの再利用禁止など複数の条件をレルム単位で設定できます。取引先や外部委託先向けのクライアントには多要素認証を必須化し、社内利用のみのクライアントは条件を緩めるといった、クライアントごとの認証要件の差別化も可能です。

多要素認証の設定自体は管理コンソールの画面操作で完結しますが、利用者への案内・登録サポート・端末を失くした場合のリカバリー手順の整備は、システム側の設定より運用面の負荷が大きくなりやすい領域です。導入初期は情報システム部門への問い合わせが増える傾向があるため、あらかじめFAQやマニュアルを準備しておくと望ましいでしょう。

セルフホスト運用で発生するアップグレードと可用性対応

Keycloakをセルフホストで運用する場合、避けられない作業がバージョンアップグレードです。公式のアップグレードガイドでは、メジャー・マイナーバージョンへの更新時は各サイトのKeycloakデプロイを一時的に停止することが前提とされており、パッチバージョンの更新であればダウンタイムなしで反映できるとされています^*5。マルチサイト構成の場合、監視やデバッグを単純にするため、サイトを1つずつ順番にアップグレードすることが推奨されています^*5。

可用性の面では、Keycloakはクラスタリングによるスケーラビリティと高可用性の実現を標準機能として備えています^*2。公式ドキュメントではシングルクラスタ構成とマルチクラスタ構成という2つの高可用性アーキテクチャが示されており、事業継続性を重視する場合はマルチクラスタでの冗長化が選択肢に入ります^*6。

認証基盤に何らかの不整合が起きた場合、影響は接続している全アプリケーションのログインに及びます。バージョンアップグレード計画・監視体制・障害時の切り戻し手順を運用ルールとして事前に定めておくことが、セルフホスト運用を選ぶ企業には欠かせません。

外注と内製、どちらを選ぶべきかの判断軸

Keycloakでのシステム構築を内製で行うには、OpenID ConnectやSAMLといった認証プロトコルの知識、レルム・クライアント設計のノウハウ、Java・コンテナ運用（Keycloakは主にDockerやKubernetesで稼働）のスキルが必要になります。加えて、外部IdPやLDAPとの連携設定、多要素認証フローの設計、障害対応や可用性設計まで一人で担うのは現実的ではなく、複数の担当者が関わる体制が求められます。

認証基盤の設定を誤ると影響は一部の機能不具合では済みません。たとえばレルム間のロール設計を誤ると、退職者のアクセス権限が意図せず残存したり、逆に必要な利用者がシステムにアクセスできなくなったりする事態が起こり得ます。認証基盤は情報セキュリティの入り口であるため、設計・設定ミスがそのまま不正アクセスや業務停止のリスクにつながる点は特に重く見る必要があります。

専門パートナーに外注する場合は、レルム設計・プロトコル選定・IdP連携・多要素認証・アップグレード計画までを一貫した体制で構築でき、内製で足りないスキル領域を補えます。一方で内製する場合は、Keycloakの学習コストと運用の継続体制を自社内に確保し続ける必要があります。すでに社内にID管理の専門知識を持つ人材がいる企業は内製が選択肢になり得ますが、そうでない場合は初期構築だけを外部に依頼し、運用は内製に引き継ぐハイブリッドな進め方も現実的な落とし所になります。

まとめ：Keycloak導入で確認すべき3つの判断軸

本稿ではKeycloakによるSSO認証基盤構築の基本概念と実務上の論点を整理しました。要点を3つに集約すると、第一にレルム・クライアント・ロールの設計が運用のしやすさを左右すること、第二にOpenID ConnectとSAMLの両対応により新旧システムを1つの基盤に統合できること、第三にセルフホスト運用ではアップグレードと可用性確保の体制づくりが欠かせないことが挙げられます。

導入方式を検討する際は、社内の認証プロトコルへの知見・運用体制の有無・セルフホストかマネージド型IDaaSかという選択を踏まえ、初期構築と継続運用のどちらを外部パートナーに委ねるかを具体的に検討する必要があります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Keycloak「Server Administration Guide – Core concepts and terms」（https://www.keycloak.org/docs/latest/server_admin/index.html）
2. *2　出典：Keycloak公式サイト「Keycloak – Open Source Identity and Access Management」機能一覧（https://www.keycloak.org/）
3. *3　出典：IETF「RFC 6749 – The OAuth 2.0 Authorization Framework」（2012年）（https://www.rfc-editor.org/rfc/rfc6749）
4. *4　出典：OpenID Foundation「OpenID Connect Core 1.0 incorporating errata set 2」（https://openid.net/specs/openid-connect-core-1_0.html）
5. *5　出典：Keycloak「Upgrading Guide」（https://www.keycloak.org/docs/latest/upgrading/index.html）
6. *6　出典：Keycloak「High availability overview」（https://www.keycloak.org/high-availability/introduction）

Tweet