IBM iのシングルサインオン（SSO）について調べる中で、 Enterprise Identity Mapping（EIM） について確認する機会がありました。
EIMは以前からIBM iに実装されている仕組みですが、調べ始めると、次のような点が少し分かりにくく感じます。
- Active DirectoryとIBM iはどのようにつながるのか
- KerberosとEIMは何が違うのか
- LDAPサーバーは何のために必要なのか
- EIMを設定すればSSOになるのか
そこで、IBM公式ドキュメントを参照しながら調査し、その結果をIBM Bobにも整理してもらいましたので、備忘録として作成してみました。
本記事では、IBM iにおけるEIMの役割と仕組みをできるだけシンプルに整理します。
本記事はIBM i DocumentationおよびIBM Security Verify Directory Documentationを参考に作成しています。
製品バージョンや構成によって、利用可能な機能や設定方法が異なる場合があります。実際のシステム設計・構築時には、使用するIBM iおよびディレクトリー・サーバーのバージョンに対応した公式ドキュメントを確認してください。
1. EIMとは何か
Enterprise Identity Mapping（EIM）は、異なるシステムやアプリケーションで使用されるユーザーID間の対応関係を管理する仕組みです。
企業システムでは、1人の利用者がシステムごとに異なるユーザーIDを持っていることが珍しくありません。
例えば、ある利用者が次のIDを持っているとします。
- Kerberosプリンシパル：
jday@MYCO.COM - IBM iユーザープロファイル：
JOHND
EIMでは、これらのIDが同じ人物を表しているという関係を定義できます。
Kerberosレジストリー
jday@MYCO.COM
│
│ Source association
▼
┌─────────────────┐
│ EIM Identifier │
│ John Day │
└─────────────────┘
│
│ Target association
▼
IBM iレジストリー
JOHND
EIM対応アプリケーションは、この関係を利用して、あるユーザーレジストリーの既知のユーザーIDから、別のユーザーレジストリーで使用するユーザーIDを検索できます。
📌 EIMと認証は別の役割
EIMそのものがユーザーを認証するわけではありません。
EIMの中心的な役割は、 「このIDとこのIDは、同じ人物またはエンティティーを表している」 という関係を管理し、必要に応じてIDをマッピングすることです。
IBM iのSSOでは、Kerberosを使用するネットワーク認証サービスとEIMを組み合わせる構成が代表的ですが、EIMそのものにKerberosが必須というわけではありません。
2. EIMを利用するメリット
EIMを利用する代表的な目的は、異なるユーザーレジストリー間のIDマッピングです。
| メリット | 内容 |
|---|---|
| 🔑 SSO構成への活用 | Kerberosなどの認証方式と組み合わせ、ユーザーに認証情報を繰り返し入力させない構成に活用できる |
| 🔗 異なるIDの関連付け | 異なるシステム上のユーザーIDを、同じ人物またはエンティティーとして関連付けられる |
| 🗂️ IDマッピングの集中管理 | システムごとに個別の変換ロジックを持つのではなく、EIMドメインで対応関係を管理できる |
| 🛡️ 既存IDの活用 | 各システムで既に使用しているユーザーIDを維持しながら、システム間のID連携を設計できる |
ポイントは、すべてのシステムでユーザーIDを同じ名前に統一するのではなく、異なるIDの対応関係を管理するという考え方です。
3. EIMを構成する主な要素
EIMを理解するうえでは、次の要素を押さえておくと、より分かりやすくなります。
| 構成要素 | 説明 |
|---|---|
| EIMドメイン | EIM ID、レジストリー定義、アソシエーションなどを管理する単位 |
| EIMドメインコントローラー | 1つ以上のEIMドメインを管理するように構成されたLDAPディレクトリー・サーバー |
| EIM ID（Identifier） | 人物またはエンティティーを表すEIM上の識別子 |
| レジストリー定義 | EIMに参加するユーザーレジストリーを表す定義 |
| IDアソシエーション | EIM IDと各ユーザーIDとの関係 |
| ポリシー・アソシエーション | 複数のユーザーIDに適用するマッピング規則 |
| EIMクライアント | EIM APIなどを使用してドメインに接続し、マッピング情報を利用するシステムまたはアプリケーション |
EIMでは、EIMドメイン内でユーザーIDとEIM IDの関係を定義し、その情報をIDマッピングに利用します。
4. Kerberosを利用したSSO構成の一例
以下は、Active DirectoryのKerberos認証とEIMを組み合わせた構成の概念図です。
役割を単純化すると、次のように整理できます。
Active Directory / Kerberos
│
│ Authentication
▼
認証されたIdentity
│
▼
EIM
│
│ Identity Mapping
▼
IBM i User Profile
│
│ Authorization
▼
IBM i Resource
- Active Directory / Kerberos：利用者の認証
- EIM：認証されたIDとIBM i側のユーザーIDのマッピング
- IBM iユーザープロファイル：権限に基づくIBM iリソースへのアクセス制御
ここで重要なのは、認証、IDマッピング、認可を分けて考えることです。
KerberosとEIMはどちらもSSO構成の中に登場しますが、それぞれ異なる役割を担います。
5. IDマッピングの仕組み
基本的なIDマッピングは、次の関係で考えることができます。
Source → EIM ID → Target
jday@MYCO.COM
│
│ Source association
▼
John Day
│
│ Target association
▼
JOHND
マッピングの流れ
Kerberosを利用したSSO構成の一例では、次のように処理されます。
- 利用者がKerberosで認証される
- 認証されたユーザーIDを起点にEIMマッピングを照会する
- 対応するEIM IDを特定する
- ターゲット側のユーザーIDを取得する
- EIM対応のサービスまたはアプリケーションが、取得したユーザーIDを利用する
- IBM iユーザープロファイルに設定された権限に基づいて、リソースへのアクセスが制御される
EIMのIDアソシエーションには、次の3種類があります。
| 種類 | 役割 |
|---|---|
| Source | EIMルックアップの起点として使用するユーザーID |
| Target | マッピング結果として返されるユーザーID |
| Administrative | EIM IDとユーザーIDの関係を管理目的で定義するアソシエーション。マッピング・ルックアップには使用されない |
さらにEIMには、個別のEIM IDに基づくIDアソシエーションとは別に、ポリシー・アソシエーションがあります。
そのため、EIMを単純な「SourceからTargetへの変換テーブル」と考えるよりも、企業内に存在する複数のIDの関係やマッピング規則を管理し、必要に応じて適切なIDを解決する仕組みと理解する方が実態に近いと考えられます。
6. IBM iでSSOを構成する場合
IBM iでは、EIMとネットワーク認証サービスを組み合わせて、KerberosベースのSSO環境を構成できます。
構成を検討するときの大まかな流れは、次のとおりです。
- SSOとEIMの構成を計画する
- EIMドメインコントローラーを用意する
- EIMドメインを作成する、または既存ドメインに参加する
- ネットワーク認証サービスを構成する
- Kerberos KDC側に必要なサービス・プリンシパルを構成する
- EIM IDを作成する
- Source、Targetなどのアソシエーションを定義する
- EIMを利用するIBM iのサービスまたはアプリケーションを構成する
- IDマッピングとSSOの動作を確認する
これは構成全体を理解するための概要です。サービス・プリンシパル名、キータブ、レジストリー定義、必要なアソシエーションなどは、SSOを利用するIBM iのインターフェースやアプリケーションによって異なります。
💡 EIMを設定しただけではSSOにはならない
EIMを構成しただけで、すべてのIBM iアクセスが自動的にSSOになるわけではありません。
KerberosベースのSSOでは、ネットワーク認証サービスによる認証、EIMによるIDマッピング、SSOに対応したサービスまたはアプリケーションを組み合わせて構成します。
7. Active DirectoryとEIMの関係
IBM iのSSOを検討するとき、特に混同しやすいのがActive DirectoryとEIMの役割です。
Kerberosを利用した代表的な構成では、次のように整理できます。
- Active Directory：Kerberos KDCおよびWindows側のユーザー認証基盤
- EIM：Kerberos側のIDとIBM i側のユーザーIDの対応付け
- IBM iユーザープロファイル：IBM i上で使用するユーザーIDと権限の保持
つまり、Active DirectoryとEIMは、同じものを置き換える関係ではありません。
Active Directoryで認証されたユーザーを、IBM i上でどのユーザープロファイルとして扱うのかを解決する部分でEIMを利用します。
8. EIMドメインコントローラーとLDAP
EIMドメインコントローラーは、1つ以上のEIMドメインを管理するように構成されたLDAPサーバーです。
EIMドメインコントローラーはIBM i上にも構成できる
EIMドメインコントローラーとして使用するDirectory Serverは、IBM i上に構成できます。そのため、EIMを利用するために、必ず外部のLDAPサーバーを別途用意しなければならないわけではありません。
IBM公式ドキュメントでは、EIMクライアントとEIMドメインコントローラーが同一システムで稼働する場合をローカル、別システムで稼働する場合をリモートと説明しています。
【ローカル構成の例】
┌──────────────────────────────┐
│ IBM i │
│ │
│ ┌────────────────────────┐ │
│ │ Directory Server │ │
│ │ EIM Domain │ │
│ │ (Domain Controller) │ │
│ └───────────▲────────────┘ │
│ │ EIM lookup │
│ ┌───────────┴────────────┐ │
│ │ EIM Client / Service │ │
│ └───────────┬────────────┘ │
│ ▼ │
│ IBM i User Profile │
└──────────────────────────────┘
一方、EIMドメインコントローラーは、EIMを利用するIBM iと同じシステム上に置かなければならないわけではありません。EIMをサポートするリモートのDirectory ServerにEIMドメインを配置し、IBM iをEIMクライアントとして参加させる構成も可能です。
【リモート構成の例】
Directory Server
└─ EIM Domain
▲
│ EIM lookup over LDAP
│
IBM i
└─ EIM Client / Service
どちらの配置を選ぶ場合も、本番環境では可用性、ネットワーク構成、運用管理、製品のサポート条件を含めて検討します。
LDAPサーバーなら何でも利用できるわけではない
ただし、LDAPサーバーであれば何でもEIMドメインコントローラーとして使用できるわけではありません。
IBM公式ドキュメントでは、EIMドメインコントローラーをホストするディレクトリー・サーバーについて、次の要件が示されています。
- LDAP Version 3をサポートしていること
- EIM LDAPスキーマを受け入れられること
- EIMに必要な属性とオブジェクトクラスを扱えること
EIMでは、ibm-eimDomain、ibm-eimIdentifier、ibm-eimSourceRelationship、ibm-eimTargetRelationshipなどの属性やオブジェクトクラスが使用されます。
既存のディレクトリー・サーバーをEIMドメインコントローラーとして利用したい場合は、次の点を確認する必要があります。
- 使用するIBM iのバージョン
- 使用するディレクトリー・サーバーの製品とバージョン
- EIM LDAPスキーマへの対応
- IBMによるサポート条件
⚠️ Active Directoryの役割と混同しない
Active DirectoryがKerberos KDCやWindows側のユーザー認証基盤として使われることと、EIMドメインの情報を保持するディレクトリー・サーバーの役割は、分けて考える必要があります。
「Active Directoryを使っているからEIMは不要」「LDAPに対応しているから、そのままEIMドメインコントローラーとして使える」と単純化せず、構成要素ごとの役割とサポート条件を確認することが重要です。
9. 運用時の注意点
EIMドメインコントローラーの可用性
EIMクライアントは、EIMドメインコントローラーに保持された情報を利用してIDマッピングを解決します。
そのため、本番環境ではEIMドメインコントローラーの可用性と性能を考慮する必要があります。マッピング要求が多い環境では、ディレクトリー・サーバーの配置やレプリカ構成も含めて検討します。
ディレクトリー接続のセキュリティー
EIMドメインコントローラーへの接続では、認証情報やIDマッピング情報を扱います。
実際の構築時には、使用するIBM iおよびディレクトリー・サーバーのバージョンに対応した公式ドキュメントを確認し、通信の保護、接続ユーザーの権限、資格情報の管理方法を検討する必要があります。
マッピング設計
Source、Target、Administrativeの各アソシエーションは、用途を区別して設計する必要があります。
特に、認証に使用するIDと認可に使用するIDの関係、同一人物に複数のターゲットIDが存在する場合の扱い、退職・異動・ID変更時のメンテナンス方法を事前に整理しておくことが重要です。
10. EIMの管理とマッピングテスト
EIMの管理では、例えば次の操作を行います。
- EIMドメインの管理
- レジストリー定義の管理
- EIM IDの管理
- Source、Target、Administrativeアソシエーションの管理
- ポリシー・アソシエーションの管理
- EIMアクセス制御の管理
- EIMマッピングのテスト
マッピングテストでは、次の変換が期待どおりに行われるかを確認します。
Source user ID
│
▼
EIM
│
▼
Target user ID
この確認により、問題がKerberos認証にあるのか、EIMのレジストリー定義やアソシエーションにあるのか、アプリケーション側のSSO設定にあるのかを切り分けやすくなります。
11. 結局、EIMは何をしているのか
KerberosベースのIBM i SSO構成では、次のように考えると分かりやすくなります。
Kerberosが利用者を認証し、EIMが認証されたIDに対応するIBM i側のユーザーIDをマッピングする。そして、マッピングされたIBM iユーザープロファイルの権限に基づいて、IBM iリソースへのアクセスが制御される。
Authentication Identity Mapping Authorization
│ │ │
▼ ▼ ▼
Kerberos → EIM → IBM i User Profile
この3つを分けて考えることが、IBM iのSSOを理解するうえで重要なポイントです。
12. まとめ
EIMを一言で表すなら、次のようになります。
異なるシステムに存在するユーザーIDを、同じ人物またはエンティティーとして関連付けるIDマッピングの仕組み
EIMは認証機能そのものではなく、SSOを構成する要素の一つです。
特にIBM iとActive Directoryを組み合わせたKerberosベースのSSOを検討する場合は、次の3点を分けて整理すると、構成を理解しやすくなります。
- 認証は誰が行うのか
- IDマッピングは誰が行うのか
- IBM i上では最終的にどのユーザープロファイルを使用するのか
調査前はEIMを「IBM iのSSO機能」と大まかに捉えていました。
しかし、実際にはSSOそのものではなく、異なる認証基盤やシステムのIDをつなぐ仕組みと理解する方が、EIMの役割を正確に捉えられます。
参考資料
- IBM i Documentation
- IBM i 7.6：Enterprise Identity Mapping
- IBM i 7.6：EIM（エンタープライズ識別マッピング）の概要
- IBM i 7.6：EIM（エンタープライズ識別マッピング）の管理
- IBM i 7.6：EIM（エンタープライズ識別マッピング）API
- IBM i 7.6：Creating EIM associations
- IBM i 7.6：EIM registry definitions
- IBM i 7.5：EIMドメイン・コントローラー
- IBM i 7.5：EIMのLDAPスキーマとその他の考慮事項
- IBM i 7.4：Identifier associations
- IBM i 7.5：EIMおよびネットワーク認証サービスの構成
- IBM Security Verify Directory Documentation