3.2.2 リポジトリ項目の検討

ここでは,アクセス制御やパーソナライズに使用する識別子に対応させるリポジトリの項目(ディレクトリサーバのエントリ属性やDBのテーブルのカラム)について説明します。

<この項の構成>
(1) ユーザ情報
(2) グループ情報
(3) 組織単位情報

(1) ユーザ情報

ユーザ情報はログインするユーザ単位にユーザエントリを作成します。ユーザ情報で使用する項目を次に示します。

表3-1 ユーザ情報で使用する情報

ユーザ情報で使用する項目説明必須
ユーザIDログインするユーザのIDです。ユーザ識別子として使用します。
ユーザ表示名ログインするユーザの表示名です。運用管理ポートレットでユーザ管理を行う場合に必要な項目です。×
パスワードログインするユーザのパスワードです。ユーザIDとパスワードでログインする場合に必要な項目です。×
パーソナライズ情報を表すキーユーザのパーソナライズ情報を格納する項目です。ユーザごとにパーソナライズをする場合に必要な項目です。×
役職情報ユーザの役職情報です。役職識別子として使用します。役職識別子を使用する場合に必要な項目です。×
所属情報ユーザの所属組織を示します。組織単位識別子を使用する場合に,ユーザが所属する組織の組織単位識別子を格納します。複数の組織に所属することはできません。×

(凡例) ○:必須 ×:任意


ユーザ情報には,上記のほかに任意の項目を追加することができます。任意に追加した項目をユーザ定義項目と呼びます。ユーザ定義項目は,アクセス制御やパーソナライズに使用することができます。

(2) グループ情報

uCosminexus Portal Frameworkがサポートしているグループ情報の仕様を次に示します。

グループ情報で使用する項目を次に示します。

表3-2 グループ情報で使用する項目

グループ情報で使用する項目説明必須
グループ名グループの名称です。グループ識別子として使用します。
所属メンバーグループに所属するメンバの情報です。
上位グループを表すキー上位グループの情報です。ディレクトリサーバの場合に指定できます。×

(凡例) ○:必須 ×:任意


グループ情報はディレクトリサーバとDBで作成方法が異なります。ディレクトリサーバとDBでグループ情報を作成する例を次に説明します。

(a) リポジトリにディレクトリサーバを使用する場合

リポジトリにディレクトリサーバを使用する場合,グループ単位にグループエントリを作成します。グループエントリの作成例を次の図に示します。

図3-3 ディレクトリサーバ構成

[図データ]

各グループエントリには,オブジェクトクラスgroupOfUniqueNamesの属性であるuniquememberに,ユーザエントリのDNを設定します。複数のメンバを配置する場合は,複数のユーザエントリのDNを設定します。

(b) リポジトリにDBを使用する場合

リポジトリにDBを使用する場合,グループ識別子はグループ情報が格納されているテーブルのグループ名を表すカラムを使用します。

グループ情報が格納されているテーブルの例を次の図に示します。

図3-4 グループ情報が格納されているテーブル例

[図データ]

グループエントリに所属するメンバを表すカラムに,ユーザ識別子を格納します。例えば,上の図の例では,所属するメンバを表すカラム(所属メンバー)でユーザ(taro)を検索すると,project1およびproject2がグループ識別子として作成されます。

(3) 組織単位情報

uCosminexus Portal Frameworkがサポートしている組織階層の仕様を次に示します。

組織単位情報で使用する項目を次に示します。

表3-3 組織単位情報で使用する項目

組織単位情報で使用する項目説明必須
組織単位ID組織情報のIDです。組織単位識別子として使用します。
組織表示名組織の表示名として使用します。運用管理ポートレットで組織ツリーを表示する場合に必要な項目です。×
上位組織を表すキーこの組織が所属する上位の組織情報の組織単位識別子の情報です。

(凡例) ○:必須 ×:任意


ディレクトリサーバとDBで組織単位情報を作成する場合の例を次に説明します。

(a) リポジトリにディレクトリサーバを使用する場合

ディレクトリサーバでの組織単位の例を次の図に示します。

図3-5 ディレクトリサーバでの組織単位の例

[図データ]

組織単位エントリには,組織階層を表現するために,上位組織を表すキーに上位組織を示すDNを格納します。最上位の組織には,上位組織を示すDNを格納しません。例えば,eigyou1とeigyou2は,図3-4の営業部に所属するので,eigyou1とeigyou2の組織単位エントリにはeigyouの組織単位エントリのDNを格納します。また,honsyaは最上位組織なので,ほかの組織単位エントリのDNを格納しません。

ユーザエントリには,ユーザが所属する組織単位の組織単位エントリのDNを格納します。これによって,ユーザとそのユーザが所属する組織単位を結び付けます。例えば,図3-5のuid=taroのユーザはeigyou1に所属するので,eigyou1の組織単位エントリのDNを格納します。eigyou1は,組織階層でeigyouおよびhonsyaに所属するので,eigyou1に所属するuid=taroのユーザは,eigyou1,eigyou,およびhonsyaの三つの組織に所属していると考えます。そのため,uid=taroのユーザエントリに格納したeigyou1の組織単位エントリのDNを基に,eigyou1,eigyou,およびhonsyaの三つの組織単位識別子が生成されます。同様にuid=hanakoのユーザはeigyou2に所属するので,eigyou2,eigyouおよびhonsyaの三つの組織単位識別子が生成されます。

組織単位識別子はユーザが所属するすべての組織に対して生成されるため,上位組織のhonsyaやeigyouに設定したアクセス制御やパーソナライズを,下位組織のeigyou1やeigyou2に所属するユーザに適用できます。

(b) リポジトリにDBを使用する場合

組織単位情報を格納するテーブルと,ユーザ管理のための情報が格納されているテーブルの関係の例を次の図に示します。

図3-6 組織単位情報を格納するテーブルとユーザ管理のための情報が格納されているテーブルの関係の例

[図データ]

組織単位エントリには,組織階層を表現するために,上位組織を表すキーに上位組織を表すカラムを格納します。最上位の組織の場合,上位組織を表すカラムには何も格納しません。例えば,図3-6の「組織単位情報を格納するテーブル」で,営業1課(eigyou1)と営業2課(eigyou2)は営業部に所属するので,上位組織を表すカラムに営業部の組織単位(eigyou)を格納します。また,本社(honsya)は最上位組織なので,上位組織には何も格納しません。

ユーザエントリには,ユーザが所属する組織単位の組織単位エントリの値を格納します。これによって,ユーザとそのユーザが所属する組織単位を結び付けます。例えば,図3-6の「ユーザ管理のための情報が格納されているテーブル」で,ユーザ(taro)はeigyou1に所属するので,eigyou1の組織単位エントリのキー値を格納します。eigyou1は,組織階層でeigyouおよびhonsyaに所属するので,eigyou1に所属するユーザ(taro)は,eigyou1,eigyou,およびhonsyaの三つの組織に所属していると考えます。このため,ユーザ(taro)のユーザエントリに格納したeigyou1の組織単位エントリのキー値を基に,eigyou1,eigyou,およびhonsyaの三つの組織単位識別子が生成されます。同様に,ユーザ(hanako)はeigyou2に所属するので,eigyou2,eigyou,およびhonsyaの三つの組織単位識別子が生成されます。

組織単位識別子はユーザが所属するすべての組織に対して生成されるため,上位組織のhonsyaやeigyouに設定したアクセス制御やパーソナライズを,下位組織のeigyou1やeigyou2に所属するユーザに適用できます。