3.6.1 LDAP対応のディレクトリサービスによるユーザ管理機能を使用する場合の設定

LDAP対応のディレクトリサービスによるユーザ管理機能を使用する場合,文書空間構成定義ファイルでの設定が必要です。文書空間構成定義ファイルについては,「4.3 文書空間構成定義ファイル(docspace.properties)」を参照してください。

<この項の構成>
(1) ディレクトリサーバの設定
(2) ディレクトリサービスの情報管理の概念
(3) LDAP対応のディレクトリサービスへのバインド
(4) LDAP対応のディレクトリサービスのユーザ認証
(5) LDAP対応のディレクトリサービスでのユーザ情報取得
(6) LDAP対応のディレクトリサービスとの連携時の注意

(1) ディレクトリサーバの設定

LDAPディレクトリサーバをインストールして初期設定します。インストールと初期設定については,使用しているLDAPディレクトリサーバのマニュアルを参照してください。すでにLDAPディレクトリサーバを使用している場合には,設置する必要はありません。

(2) ディレクトリサービスの情報管理の概念

連携するLDAP対応のディレクトリサービスのデータ構造について次に示します。

フラット型
ベースDN直下にすべてのユーザエントリが登録されているデータ構造です。

図3-1 ディレクトリサービスで管理する情報の構造の例

[図データ]
階層型
ベースDN以下が分岐しており,各階層にユーザエントリが登録されているデータ構造です。定義によっては,階層構造の場合に関連付いた情報を上位にあるプロパティから取得したり,再帰的に取得することも可能です。定義例については,「3.7.3(1) ユーザ情報の取得方法」を参照してください。

図3-2 ディレクトリサービスで管理する情報の構造の例(階層型)

[図データ]
(a) DIT

ディレクトリサービスが管理する情報は,図3-1および図3-2の形式の構造図によって示されます。この構造をDITと呼びます

(b) エントリ

エントリまたはディレクトリエントリは,DITを構成する情報で,図3-1および図3-2のDITの各節に該当します(以降,エントリと呼びます)。

図3-1および図3-2の「c=jp」「o=hitachi」,「ou=PEOPLE」,「uid=Tanaka」などがエントリです。エントリは,左辺と右辺を「=」(等号)でつないでいます。左辺は属性で右辺は属性値を表します。また,エントリは一つ以上の属性によって構成されています。ディレクトリサービスでは,データをエントリおよび属性によって管理します。

(c) DN

DNは,DITの各エントリを一意に識別するための情報名です。ファイルシステム内のファイルパスのように扱われます。DNは,「,」(コンマ)で区切られたエントリの集まりで,各エントリはディレクトリ内の位置を表す相対識別名(RDN)で構成されます。相対識別名は,「属性=属性値」の形式で表現されます。例えば,uid=Tanakaやou=People1などが相対識別名に当たります。DNは,ファイルシステム内のファイルパスのように扱われますが,相対識別名の並びがファイルシステムとは逆の順番になります。つまり,ファイルシステムでは,ファイルの名称をいちばん右に指定して,左から右へパスを指定していきますが,DNでは,いちばん左の位置にDITの最下層のエントリを指定し,いちばん右側の位置にDITの最上位のエントリを指定していきます。DNの記述例を次に示します。

uid=Tanaka,ou=People1,o=hitachi,c=jp

この記述例は,図3-1に示した「jp」というディレクトリ内の,「hitachi」というサブディレクトリ内にある「PEOPLE」というサブディレクトリの「Tanaka」というエントリのDNを示します。

(3) LDAP対応のディレクトリサービスへのバインド

DocumentBrokerでLDAPディレクトリに接続(バインド)するために,情報検索用のユーザを登録してアクセス権を設定します。情報検索用ユーザのDNのことを情報検索用のバインドDNといいます。情報検索用のバインドDNには,DocumentBrokerで参照するベースDN以下すべてのエントリ,およびエントリに設定されたすべての属性に対して,読み取り権,比較権,検索権を付与してください。情報検索用のバインドDNは,LDAPディレクトリサーバからユーザ情報などを取得するときに使用します。

情報検索用のバインドDNは,文書空間構成定義ファイル(docspace.properties)の次に示すプロパティに設定します。

文書空間構成定義ファイル(docspace.properties)の設定の詳細は,「4.3 文書空間構成定義ファイル(docspace.properties)」を参照してください。

(4) LDAP対応のディレクトリサービスのユーザ認証

ユーザ管理システムとしてLDAP対応のディレクトリサービスを使用する場合は,セッションを確立するときにユーザが指定したユーザ名を基に,文書空間構成定義ファイルで指定したDITを検索してユーザエントリを特定し,そのDNによりバインドを試みます。

このため,ディレクトリ構成を意識しないでユーザを特定できます。ただし,ディレクトリ内に存在するユーザが,一意に識別できる必要があります。

(5) LDAP対応のディレクトリサービスでのユーザ情報取得

DocumentBrokerのアクセス制御機能を使用して,アクセス制御されている文書に接続する場合,DocumentBrokerはLDAP対応のディレクトリサービスに登録されているユーザに関する情報を使用して,目的の文書に対するアクセスが許可されているかどうか判断します。DocumentBrokerがアクセス制御機能で使用するユーザに関する情報は,ユーザ識別子およびグループ識別子です。ユーザ識別子およびグループ識別子について,次に説明します。

(a) ユーザ識別子

ユーザを一意に識別するための情報です。ユーザ識別子は,1~254バイト(ただし,「¥0」を含まない)のASCII半角英数字,「-」,「.」,「@」,「_」で構成されます。LDAP対応のディレクトリサービスを使用する場合,ユーザ識別子として使用する属性は,文書空間構成定義ファイルに指定する必要があります。文書空間構成定義ファイルについては,「4.3 文書空間構成定義ファイル(docspace.properties)」を参照してください。

(b) グループ識別子

グループを一意に識別する情報です。ユーザが複数のグループに所属する場合があるため,グループ識別子は,一人のユーザに対して複数存在できます。また,プライマリグループも設定できます。

グループ識別子は,1~254バイト(ただし,「¥0」を含まない)のASCII半角英数字,「-」,「.」,「@」,「_」で構成されます。

LDAP対応のディレクトリサービスでは,「組織」と「グループ」をグループとして扱えます。組織とグループについて次に説明します。

組織
オブジェクトクラス「organizationalUnit」またはそのクラスから派生したクラスのオブジェクトです。DocumentBrokerでは,ユーザの属性として格納される組織情報(例えば,ou属性やdepartmentnumber属性など)およびユーザを識別するDNに記述される組織情報をそれぞれ抽出して利用できます。
グループ
オブジェクトクラス「groupOfUniqueNames」またはそのクラスから派生したクラスのオブジェクトです。

(6) LDAP対応のディレクトリサービスとの連携時の注意