2026.11.03 セキュリティ

ID管理のOSSを役割で選ぶ：Keycloak・midPoint・OpenLDAPの構成と連携手順

ID管理をOSSで組むとき、最初に決めるのは製品名ではなく「どの役割を任せるか」です。ログインとSSOはKeycloak、入社・異動・退職に合わせたアカウントの発行と回収はmidPoint、アカウントの保管場所はOpenLDAPというように、OSSは役割ごとに得意分野が分かれています。この記事では、主なID管理OSSの2026年11月3日時点の最新版とライセンス、OpenLDAPの利用者をKeycloakに読み込ませる設定、midPointを試す起動手順を、コマンド付きで順に示しました。無料で始められる範囲と、構築・運用で残る費用、OSSを選ばない方がよい条件まで扱います。

まとめ：ID管理のOSSは認証・IGA・ディレクトリの3役に分けて組み合わせる

1つのOSSでID管理のすべてを賄える製品はありません。Keycloakは認証とSSO、midPointはIDライフサイクル管理（IGA）、OpenLDAPや389 Directory Serverはアカウントを保管するディレクトリを担います。社内システムへのログインを1回にまとめたいだけならKeycloak単体で足ります。退職者のアカウントが各システムに残る問題を解きたいなら、midPointが本命です。

ライセンス料は0円でも、費用はかかります。Keycloakは2026年6月から10月の間にほぼ2週間おきに修正版を出しており、追従する担当者と検証の仕組みが要ります。midPointは4.10からEUPL単独のライセンスに変わったため、改変して配布する場合は条件を確かめてください。

OSSを選ぶのは、Linuxと認証の運用を担える担当者が社内にいるか、保守を継続して外部に委託できる場合に限ります。どちらも用意できないなら、IDaaSを契約する方が総額は安く収まります。

ID管理のOSSを認証・IDライフサイクル・ディレクトリの3役で切り分ける

「ID管理」という言葉には、ログインの仕組みとアカウントの台帳の両方が含まれます。OSSは役割ごとに製品が分かれているため、候補を絞るには、先に役割を切り分ける方法が有効です。ID管理の全体像は認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を解説で整理しています。

Keycloakが担う認証・SSOとmidPointが担うIGAの守備範囲の違い

Keycloakは、OpenID ConnectやSAMLでアプリにログイン画面とトークンを提供するIdP（認証サーバー）です。利用者が1回ログインすれば、つながった複数のアプリを行き来できます。一方で、人事の発令を受けて各システムにアカウントを作り、退職日に止めるといった処理は持っていません。

その部分を受け持つのがmidPointです。人事データを起点に、LDAP・Active Directory・業務システムのアカウントを作成・変更・無効化し、誰がどの権限を持っているかを定期的に見直す仕組みまで備えます。ログイン画面は提供しません。両者は競合ではなく前後の関係にあり、midPointが整えたアカウントでKeycloakがログインさせる、という順番で組み合わせます。IGAの考え方はIGAとは：IDライフサイクル管理とアクセス認証の仕組みが詳しいです。

OpenLDAPや389 Directory Serverがアカウントの保管先になる理由

ディレクトリサーバーは、利用者・所属・グループを木構造で保持し、LDAPという標準の手順で検索させる台帳です。KeycloakもmidPointもLDAPを読み書きできるため、ここを共通の保管場所にすると、製品を入れ替えても台帳は残ります。

OSSのディレクトリはOpenLDAPと、Red Hat系で使われる389 Directory Serverが代表です。Windowsのドメイン参加やグループポリシーが必要なら、どちらでもなくSamba（Active Directory互換）を検討します。違いはLDAPとは？仕組み・Active Directoryとの違いと認証実装とSambaとは｜SMBのLinux実装の仕組みとAD連携で解説しています。

主なID管理OSS6種の役割・最新版・ライセンスを並べた比較表

2026年11月3日に各プロジェクトのGitHubと公式サイトで確認した版とライセンスです。版は数週間で変わるため、導入時に必ず取り直してください。

製品	役割	最新版（公開日）	ライセンス
Keycloak	認証・SSO（IdP）	26.8.1（2026-10-13）	Apache-2.0
ZITADEL	認証・SSO（IdP）	v4.20.0（2026-10-22）	AGPL-3.0
midPoint	IGA（ライフサイクル管理）	4.11.0／LTSは4.8.14	EUPL（4.10以降）
OpenLDAP	ディレクトリ	2.6.16 LTS／2.7.2	OpenLDAP公開ライセンス2.8
389 Directory Server	ディレクトリ	3.3.1（2026-09-07）	GPLv3以降＋OpenSSL例外
LLDAP	軽量ディレクトリ	v0.6.3（2026-04-30）	GPL-3.0

出典はKeycloakのGitHubリリース、ZITADELのリリース、midPointのリリース一覧、OpenLDAPのリリースページ、389 Directory ServerのリリースとLICENSE、LLDAPのリポジトリです。LLDAPはリポジトリの説明どおり認証用途に絞った実装で、数十人規模の社内ツールやホームラボ向けです。数百人以上の台帳にはOpenLDAPか389 Directory Serverを選びます。

ID管理OSSのライセンスと版の選び方：EUPL化・LTS・修正版の周期

OSSは無料でも、ライセンスの条件と版の追い方は製品ごとに違います。社内利用だけか、改変して顧客に提供するかで、選べる製品が変わります。

midPointは4.10からEUPL単独、4.8・4.9は二重ライセンスを維持

Evolveumは2025年9月16日の発表MidPoint Adopting EUPLで、4.10以降のmidPointをEUPL単独で提供すると告げました。4.8と4.9はEUPLとApache 2.0の二重ライセンスのままです。変更の対象はmidPoint本体だけで、コネクタなどの部品は含まれません。

EUPLは弱いコピーレフトで、改変版を配布するときは改変部分の公開が求められます。社内で使うだけなら影響は小さく、midPointを組み込んだ製品やSaaSを外部に提供する場合に条件の確認が必要です。版の選択では、リリース一覧に載る4.8 LTS（2028年10月17日までサポート）と4.11.0（同2028年10月20日まで）のどちらに乗るかを決めてください。製品の詳細はmidPointとは？OSSのIGAツールの機能・最新版4.11・Docker導入手順にまとめています。

Keycloakは最新系列のみ修正され、OpenLDAPは2.6系がLTS

Keycloakは修正版を最新の系列にだけ出します。26.6.4から26.8.1までの4か月で9回の修正版が出ており、古い系列に留まる運用は成り立ちません。修正の追い方はKeycloakの脆弱性対応の手順で具体的に扱っています。長期サポートが必要なら、有償のRed Hat build of Keycloakを選ぶ形になります。

OpenLDAPは系列が2本あり、2.6.16がLTS、2.7.2が新機能を含むFeature Releaseです。本番の台帳には2.6系を使い、2.7系は検証環境で試す形で使い分けると、堅実に運用できます。ライセンスはOpenLDAP Public License 2.8で、BSD系の緩い条件です。ZITADELはAGPL-3.0なので、改変してネットワーク越しに提供すると改変部分のソース公開が求められます。

OpenLDAPの登録利用者をKeycloakのUser Federationで読む手順

ここからは、ディレクトリと認証をつなぐ作業です。OpenLDAPに入れた利用者で、Keycloak経由のSSOにログインできる状態を作ります。OpenLDAPの初期設定（dc=example,dc=comのサフィックスと管理者cn=Managerの作成）は、OpenLDAP 2.6のQuick-Start Guideの手順を済ませた前提です。

LDIFで組織単位と利用者を作りldapaddで投入するコマンド例

利用者を入れる組織単位ou=Peopleと、利用者1人をLDIFファイルに書きます。社員番号をemployeeNumberに入れておくと、後で人事データと照合するときのキーになります。

# people.ldif：利用者を入れる組織単位と、利用者1人を定義する
dn: ou=People,dc=example,dc=com
objectClass: organizationalUnit
ou: People

dn: uid=tanaka,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
uid: tanaka
cn: Taro Tanaka
sn: Tanaka
givenName: Taro
employeeNumber: 100234

# 管理者で投入する（-W でパスワードを対話入力）
ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f people.ldif

# 利用者のパスワードを設定する（-S で新しいパスワードを対話入力）
ldappasswd -x -D "cn=Manager,dc=example,dc=com" -W -S "uid=tanaka,ou=People,dc=example,dc=com"

# 登録できたかを確かめる
ldapsearch -x -b "ou=People,dc=example,dc=com" "(uid=tanaka)" cn employeeNumber

最後の検索でdn: uid=tanaka,ou=People,dc=example,dc=comが返れば投入は完了です。Keycloakが接続に使うアカウントは管理者cn=Managerではなく、ou=Peopleを読めるだけの専用アカウントを別に作って渡してください。

kcadm.shでLDAPプロバイダーを登録し、編集モードをREAD_ONLYにする

Keycloakの管理CLIkcadm.shで、レルムdemoにOpenLDAPを登録します。Server Administration GuideのLDAPプロバイダー作成例から、Kerberos関連の項目を除いて読み取り専用にした形です。

# 管理 CLI にログインする（パスワードは対話入力）
kcadm.sh config credentials --server http://localhost:8080 --realm master --user admin

# parentId に入れるレルムの id を確かめる
kcadm.sh get realms/demo --fields id

# OpenLDAP を読み取り専用の利用者ストレージとして登録する（-i で作成した id を表示）
kcadm.sh create components -r demo -i \
  -s name=openldap -s providerId=ldap \
  -s providerType=org.keycloak.storage.UserStorageProvider \
  -s parentId=上で確かめたレルムのid \
  -s 'config.vendor=["other"]' \
  -s 'config.editMode=["READ_ONLY"]' \
  -s 'config.connectionUrl=["ldap://ldap.example.internal:389"]' \
  -s 'config.usersDn=["ou=People,dc=example,dc=com"]' \
  -s 'config.usernameLDAPAttribute=["uid"]' \
  -s 'config.rdnLDAPAttribute=["uid"]' \
  -s 'config.uuidLDAPAttribute=["entryUUID"]' \
  -s 'config.userObjectClasses=["inetOrgPerson, organizationalPerson"]' \
  -s 'config.authType=["simple"]' \
  -s 'config.bindDn=["cn=keycloak-reader,dc=example,dc=com"]' \
  -s "config.bindCredential=[\"$LDAP_BIND_PW\"]" \
  -s 'config.searchScope=["1"]' \
  -s 'config.syncRegistrations=["false"]'

# 表示された id を使い、全利用者の同期を実行する
kcadm.sh create "user-storage/表示されたid/sync?action=triggerFullSync" -r demo

同期のあと、Keycloakのアカウント画面にtanakaとLDAPに設定したパスワードでログインできれば接続は成功です。パスワードの照合はKeycloakではなくOpenLDAPで行われます。本番ではldap://ではなくldaps://かStartTLSで通信を暗号化してください。Keycloak本体のデータベース設定はKeycloakのデータベース設定と使い方を参照してください。

編集モードは作成時に決める：WRITABLEとUNSYNCEDを選ぶ条件

Server Administration Guideは、編集モードを3種類定めています。READ_ONLYはKeycloakから氏名やパスワードを変えられず、WRITABLEは変更をLDAPへ書き戻し、UNSYNCEDは変更をKeycloak側のデータベースにだけ保存します。

台帳の持ち主をmidPointや人事システムにするなら、READ_ONLY一択です。Keycloakから書き戻せると、台帳が2か所で更新され、どちらが正しいか分からなくなります。WRITABLEは、Keycloakのアカウント画面で利用者が自分のパスワードを変える運用を、LDAPを正として回したい場合に限った選択肢です。注意点として、ガイドは編集モードを後から変えても初期に作られたマッパーの設定は変わらないと明記しています。作成後に変えるより、プロバイダーを作り直す方が確実です。

midPointをDocker Composeで起動しLDAPへアカウントを配布する流れ

認証がつながったら、台帳を整える側のmidPointを試します。公式のDocker Composeファイルを使えば、PostgreSQLと合わせて数分で起動できます。

公式のdocker-compose.ymlで起動し初期パスワードを取り出す手順

midPointのDocker Composeの手順では、ファイルを取得して起動するだけで、ブラウザから/midpoint/にアクセスできます。4.8.1以降は既定のパスワードがなく、初回起動時に生成されてログに出ます。

# 公式の Compose ファイルを取得して起動する
curl -O https://raw.githubusercontent.com/Evolveum/midpoint-docker/master/docker-compose.yml
docker compose up -d

# 生成された administrator の初期パスワードをログから探す
docker compose logs midpoint_server 2>&1 | grep "initial password"

# ブラウザで http://localhost:8080/midpoint/ を開き administrator でログインする

パスワードを事前に決めたい場合は、Administrator Initial Passwordのとおり、midpoint_serverのenvironmentにMP_SET_midpoint_administrator_initialPasswordを足します。8文字以上で英大文字・英小文字・数字を含まないと管理者が作られず、docker compose down -vで作り直すことになります。取得したComposeファイルにはデータベースのパスワードが平文で3か所書かれているので、検証以外で使うときは変更してください。

人事CSVを起点にmidPointがLDAPへ反映しKeycloakが読む構成

3つを組み合わせた構成では、データの流れを一方向にそろえます。

人事システムが社員番号・氏名・所属・入退社日をCSVかデータベースで出力する
midPointがそれを取り込み、所属に応じたロールを割り当てる
midPointのLDAPコネクタが、OpenLDAPのou=Peopleへアカウントを作成・変更・無効化する
KeycloakがREAD_ONLYでOpenLDAPを読み、各アプリへのSSOを提供する

この形なら、退職日にmidPointがLDAPのアカウントを止めた時点で、Keycloak経由のログインもできなくなります。Keycloakは利用者の情報をキャッシュするため、反映の遅れを左右する同期の間隔とキャッシュの設定は、事前に確認が必要です。LDAPを持たないSaaSや自社の業務システムには、midPointから標準仕様のSCIMで届ける方法があります。受け口の作り方はSCIMとは？ID自動プロビジョニングの仕組みとエンドポイント実装で解説しています。

OSSでID管理を組む構築・運用コストとOSSを採用しない方がよい条件

OSSのID管理は、ライセンス料の代わりに人の時間を払う選択です。払う時間の大きさを見積もってから決めます。

3製品を組み合わせたときに運用で抱える更新作業と担当者の人数

Keycloak・midPoint・OpenLDAPの3つを本番で動かすと、更新の周期が製品ごとに異なります。Keycloakは2週間前後で修正版が出て、midPointは4.11.1が2027年1月26日、4.8.15 LTSが2027年1月27日の予定と、四半期単位で版が進みます。OpenLDAPで追う対象は、LTS系列の更新です。

実務でまず押さえるのはKeycloakです。認証基盤は外部に公開されるため、修正版の公開から1〜2週間で本番へ出せる体制が無いと危険です。加えて、midPointはロールやコネクタを設定オブジェクトとして定義する独自の作法があり、習得に時間がかかります。休暇や異動を考えると、3製品の運用を理解した担当者は最低2人必要です。1人しかいない体制では、その人が抜けた時点で台帳を誰も直せなくなります。

従業員数とSaaS連携数でOSSを見送りIDaaSを選ぶ判断の線引き

次のどれかに当てはまるなら、OSSは採用しないと判断してください。

従業員が数百人以下で、連携先の大半がSaaSである
LinuxとLDAPの運用を担える担当者が社内に2人いない
Keycloakの修正版を1か月以内に本番へ反映する体制を作れない
midPointを改変して自社製品に組み込み、外部へ提供する予定がある（EUPLの条件確認が先）

この場合はIDaaSの標準機能を使う方が、導入は早く、総額も安く収まります。費用の比べ方はID管理システムの費用・料金：課金単位と連携数で増える総額、製品タイプごとの違いはID管理システム比較：4タイプの違いと人事連携・棚卸しで選ぶ機能要件で整理しています。反対に、従業員が数千人規模でユーザー単価のライセンス費が大きくなる組織や、オンプレミスの業務システムが多くSaaSのコネクタでは届かない組織なら、OSSを組み合わせた構成が費用面で有利です。構成の設計や業務システム側の受け口の開発を外部に任せたい場合は、一創の認証基盤・ID管理システム開発で、OSSとIDaaSの比較から構築まで支援しています。

ID管理のOSSを検討する情報システム担当者からよく受ける質問

ID管理をOSSで組むかどうかを検討する段階で、よく出る質問に答えます。

OSSのID管理システムは本当に無料で使えますか？

ライセンス料は無料です。Keycloak・midPoint・OpenLDAPはいずれも、利用者数に応じた課金がありません。ただし、サーバー費、構築の人件費、修正版への追従や障害対応の人件費は自社で負担します。商用サポートが必要なら、KeycloakはRed Hat build of Keycloak、midPointはEvolveumの有償サービスを契約する形です。無料なのはソフトウェアの入手までと考えてください。

Keycloakだけで退職者のアカウント管理までできますか？

できません。KeycloakはSSOのログインを止められますが、各システムの中にあるアカウントそのものは消しません。Keycloakを通らずにログインできるシステムや、ローカルのアカウントを持つSaaSには、退職者のアカウントが残ります。退職時に全システムのアカウントを止めて記録まで残したいなら、midPointなどのIGAツールか、プロビジョニング機能を持つIDaaSを組み合わせます。

Active Directoryの代わりにOpenLDAPを使えますか？

Webアプリの認証台帳としてなら代わりになります。Windowsパソコンのドメイン参加やグループポリシーの配布は、OpenLDAPではできません。Windows端末を集中管理したい場合は、Active Directory互換のSambaか、Microsoft Entra IDなどのクラウドのディレクトリを選びます。既にActive Directoryがあるなら、KeycloakからActive Directoryを直接読む構成の方が手戻りがありません。

midPointとKeycloakはどちらから導入すべきですか？

解きたい課題で決まります。パスワードが多すぎる、ログインがアプリごとに違うという不満が先にあるならKeycloakから入れます。監査で退職者のアカウント残存を指摘された、権限の棚卸しに数週間かかるという問題が先ならmidPointからです。どちらから始めても、両者の間に置くLDAPの設計（ツリーと照合キー）を先に決めておけば、後から足す側の作業が小さくなります。

ZITADELはKeycloakの代わりになりますか？

認証・SSOのIdPという役割は同じなので、代わりになります。違いはライセンスと構成です。ZITADELはAGPL-3.0で、改変してネットワーク越しに提供するとソースの公開が求められます。KeycloakはApache-2.0でその義務はありません。社内利用だけなら差は小さく、日本語の情報量と既存の構築事例の多さを考えると、多くの組織ではKeycloakが選びやすい候補です。