図1は、文書管理システムの概略構成の例を示すブロック図である。このシステムは、インターネットやローカル・エリア・ネットワーク等のネットワーク30を介して接続された文書管理サーバ10とクライアント20−1,20−2,・・・(以下、クライアント20と総称する)とから構成される。
文書管理サーバ10は、本発明の1つの実施形態のアクセス権情報管理装置として機能する。文書管理サーバ10は、クライアント20からの処理要求に応じて処理を行う。例えば、文書管理サーバ10は、クライアント20から文書の出力要求を受けると、要求対象の文書に設定されたアクセス権に基づいて当該文書の出力の可否を決定し、クライアント20に対して、当該文書又は文書出力要求を拒否する旨を表す情報を出力する。
文書管理サーバ10は、処理要求受付部100、制御部110、処理結果出力部120、オブジェクト情報管理部130、ACLグラフ管理部140、ACLツリー表示部150、検索処理部160、及びアクセス制御部170を備える。また、文書管理サーバ10は、文書DB(データベース)40、オブジェクト情報DB50、ACL情報DB60、及びユーザ情報DB70、を参照可能である。これら各種DBは、文書管理サーバ10にネットワークを介して接続されていてもよいし、文書管理サーバ10が備える記憶装置(図示しない)上に構築されていてもよい。
処理要求受付部100は、ネットワークを介して接続されたクライアント20からの処理要求を受け付けて、受け付けた要求の内容を制御部110に渡す。
制御部110は、文書管理サーバ10の各部における処理を制御する。制御部110は、クライアント20からの処理要求を処理要求受付部100から受け取ると、受け取った要求の内容に応じた処理を行うよう文書管理サーバ10の各部を制御し、その処理結果を取得して処理結果出力部120に渡す。
処理結果出力部120は、クライアント20からの処理要求に応じた処理の結果を制御部110から取得して、取得した処理結果をクライアント20に対して出力する。
オブジェクト情報管理部130は、文書管理サーバ10が管理する各オブジェクトに関する情報を管理する。以下の説明において、「オブジェクト」とは、文書や画像などのデータを含むファイル、及びファイルを格納するフォルダなど、アクセス制限の対象となる情報の一単位を表す。例えば、オブジェクト情報管理部130は、文書管理サーバ10の管理対象の文書ファイルのオブジェクトを管理する。文書管理サーバ10の管理対象の文書ファイルは、文書DB40に格納される。文書DB40は、一般的なファイルシステムであってよい。また例えば、オブジェクト情報管理部130は、各オブジェクトのアクセス権の設定情報を管理する。本実施形態では、各オブジェクトのアクセス権は、ACLの形式で表される。
また、オブジェクト情報管理部130は、各オブジェクトに対してシステム内で一意なオブジェクトID(識別子)を付与し、各オブジェクトのオブジェクトIDと、そのオブジェクトの属性情報と、を関連付けてオブジェクト情報DB50に登録する。オブジェクトの属性情報には、オブジェクトの名前、オブジェクトの種類(文書ファイルオブジェクト、画像ファイルオブジェクト、及びフォルダオブジェクトなど)、オブジェクトの作成者、オブジェクトの実体データのデータベースにおける格納位置、及び、オブジェクトに対するアクセス権を表すACLなどがある。
図2に、オブジェクト情報DB50のデータ内容の一例を示す。図2の表の1行は、1つのオブジェクトに対応する。図2を参照し、オブジェクト情報DB50には、各オブジェクトのオブジェクトIDに関連付けて、「オブジェクト名」、「オブジェクトタイプ」、「作成者」、「格納位置」、及び「ACL_ID」の各項目が登録される。オブジェクト名は、対応するオブジェクトに対して、例えばユーザ又はシステムの管理者などが付与した名称である。オブジェクトタイプは、オブジェクトの種類を表す。作成者は、オブジェクトを作成したユーザを表す。格納位置は、オブジェクトが格納されているデータベース上の格納位置を表す。格納位置の項目には、例えば、ファイルシステムにおけるオブジェクトの格納位置を表すパス情報が登録される。文書管理サーバ10は、この格納位置の項目の値を参照することでオブジェクトの実体データを取得する。ACL_IDは、オブジェクトに対する操作権限を表すACLの識別情報である。ACL_IDに対応するACLの内容は、後述のACL情報DB60に記憶される。
図2の例の表において各オブジェクトIDに関連付けられる各項目のうち、ACL_ID以外の項目は必須ではない。オブジェクト情報DB50には、オブジェクトIDとACL_IDとの組を登録しておけば、その他の各項目は、システムの管理目的上必要なければ登録しなくてもよい。あるいは、例えばオブジェクトの作成日時など、図2に例示する項目以外の項目を各オブジェクトIDに関連付けて登録してもよい。
ACLグラフ管理部140は、オブジェクトに設定されるACLに関する情報を管理する。例えば、ACLグラフ管理部140は、ACL情報DB60に新規にACLを登録したり、ACL情報DB60からACLを削除したりする。また例えば、ACLグラフ管理部140は、ACL情報DB60内に登録されたACLについて、後述するACL間の関係に基づくグラフ構造を生成して管理する。
図3に、ACL情報DB60のデータ内容の一例を示す。図3を参照し、ACL情報DB60には、各ACLのACL_IDに対応づけて、「ACL名」、「ACE」、「上位ACL」、「下位ACL」、及び「オブジェクトID」の各項目が登録される。ACL_IDは、各ACLに付与されるシステム内で一意な識別情報であり、オブジェクト情報DB50にオブジェクトIDと関連付けて登録されるACL_IDと同様である。ACL名は、対応するACLに対して、例えばユーザ又はシステムの管理者などが付与した名称である。ACL名が付与されていない場合は、ACL名の項目の値は「NULL」に設定される。
ACEは、ACLにおいて、各ユーザ又はユーザグループに対して許可される操作の種類を表す。ACEの項目は、「主体」及び「権限」の各項目を下位項目に含む。主体の項目には、ユーザ又はユーザグループの識別情報(ユーザID又はグループID)が登録される。権限の項目には、対応するユーザ又はユーザグループに対して許可される操作の種類が登録される。図3の例では、文字「m」は「管理権限」、文字「w」は「書き込み権」、及び文字「r」は「読み込み権」を表す。1つの主体と対応する権限との組み合わせが1つのACEである。各ACLは、1以上のACEを含む。図3の例では、ACL_ID"acl1"のACLは、主体「全ユーザ」に対して、権限「r(読み込み権)」を許可する旨を表すACEを1つ含む。また例えば、ACL_ID"acl7"のACLは、主体「鈴木太郎」に対して、権限「m(管理権),w(書き込み権),r(読み込み権)」を許可する旨を表すACEと、主体「営業一課」に対して、権限「w(書き込み権),r(読み込み権)」を許可する旨を表すACEと、の2つのACEを含む。
上位ACL及び下位ACLの各項目には、対応するACLとの間に後述の所定の関係を有するACLのACL_IDが登録される。また、ACL_IDと上位ACL又は下位ACLとの組は、後述するACL間の関係に基づくグラフ構造中の辺を表す情報である。
オブジェクトIDの項目には、対応するACLを参照してアクセスの可否を決定するオブジェクトのオブジェクトIDが登録される。したがって、ACL情報DB60において互いに関連付けられるACL_IDとオブジェクトIDとの組は、オブジェクト情報DB50においても互いに関連付けられる。なお、後述のように、ACL情報DB60内には、いずれのオブジェクトからも参照されないACLが登録される場合もある。いずれのオブジェクトからも参照されないACLに関しては、オブジェクトIDの項目の値は「NULL」に設定される。
なお、図3の例の表の各項目は単なる例示であり、必要に応じて、図3の例の項目の一部を省略したり、図3に例示しない項目を追加したりしてもよい。例えば、上位ACLの項目を登録しておけば、下位ACLの項目は登録しなくてもよい。ACL情報DB60において下位ACLの項目を登録しない場合、各ACL_IDに対応するACLの下位ACLは、そのACL_IDを上位ACLの項目の値として含むACL_IDを検索することで取得される。また例えば、図3の例のオブジェクトIDの項目は、ACL情報DB60においては必須ではない。上述のようにオブジェクト情報DB50においてオブジェクトIDに関連付けてACL_IDを登録しておけば、ACL情報DB60においてオブジェクトIDの項目を登録しなくても、オブジェクト情報DB50を参照することで、各ACL_IDに関連付けられたオブジェクトIDが取得される。
ACLツリー表示部150は、ACLグラフ管理部140が管理するACL間の関係に基づいて、ACLを図式的に表示させる表示情報を生成する。ACLツリー表示部150が生成する表示情報の詳細は後述する。
検索処理部160は、制御部110が示す検索条件を満たすオブジェクトを検索する処理を行う。例えば、検索処理部160は、ユーザIDと操作の種類とを指定する検索指示を制御部110から受けた場合に、指定されたユーザIDのユーザに対して、指定された種類の操作の実行が許可又は禁止されるオブジェクトを検索する処理を行う。
ユーザ情報DB70は、ユーザに関する情報を記憶するデータベースである。ユーザ情報DB70には、例えば、ユーザグループのグループIDと、そのユーザグループに所属するユーザのユーザIDと、が関連付けられて登録される。
アクセス制御部170は、文書又はフォルダなどのオブジェクトに対するクライアント20からの操作要求を受けた場合に、その操作の実行の可否を決定する。例えば、アクセス制御部170は、処理要求受付部100及び制御部110を介して、要求元のクライアント20のユーザのユーザIDと、操作要求の対象のオブジェクトのオブジェクトIDと、を受け取ると、オブジェクト情報管理部130を介してオブジェクト情報DB50を参照し、対象のオブジェクトIDに関連付けられるACL_IDを取得する。そして、このACL_IDに対応するACLに含まれるACEについて、ACLグラフ管理部140を介してACL情報DB60を参照し、要求元のクライアント20のユーザに対して要求された種類の操作の実行が許可されているか否かを判定する。そして、この判定結果に従って、要求された操作の実行の可否を決定する。
以下、ACLグラフ管理部140によるACLの管理について説明する。ACLグラフ管理部140は、ACL中のACEに基づいて定義されるACL間の関係を用いてACLを管理する。また、ACLグラフ管理部140は、ACL間の関係に基づいてグラフ構造を生成して管理する。ACL間の関係及びACLからなるグラフ構造(ACLグラフ)は、後に例示する数学的モデルによって表現されるものであってよい。
ACL間の関係及びACLグラフの数学的モデルの例について述べる前に、まず、説明で用いる集合論及びグラフ理論の用語を説明する。
<集合論の用語>
・同値関係
集合A上の関係〜が、次の条件(反射律、対称律、及び推移律)を満たす場合、関係〜は同値関係であるという。
反射律:任意の元x∈Aに対して、x〜x
対称律:任意の元x,y∈Aに対して、x〜yならばy〜x
推移律:任意の元x,y,z∈Aに対して、x〜yかつy〜zならばx〜z
・半順序関係
集合A上の関係〜が、次の条件(反射律、推移律、及び反対称律)を満たす場合、関係〜は半順序関係であるという。半順序関係は、単に「順序関係」と呼ばれる場合もある。
反射律:任意の元x∈Aに対して、x〜x
推移律:任意の元x,y,z∈Aに対して、x〜yかつy〜zならばx〜z
反対称律:任意の元x,y∈Aに対して、x〜yかつy〜xならばx=y
・同値類
集合A上の同値関係〜について、a∈Aに対するAの部分集合{x∈A|a〜x}を、
aを代表元とする同値類と呼び、[a]と記載する。
・商集合
集合A上の同値関係〜について、同値類全体のなす集合{[x]|x∈A}を、Aの〜
による商集合と呼び、A/〜と表す。
<グラフ理論の用語>
・有向グラフ
集合V,Eと、関数f:E→V×Vにおいて、対(f,V,E)を有向グラフという。Vの要素を頂点(ノード)と呼び、Eの要素を辺(エッジ)と呼ぶ。
・ループ
辺の両端点が等しいとき、その辺をループ(自己ループ)という。
・多重辺
任意の2頂点間に複数の辺が存在するとき、これら複数の辺を多重辺という。
・単純グラフ
ループ及び多重辺のいずれも含まないグラフを単純グラフという。
・隣接
辺と辺とがある頂点を共有しているとき、その辺同士は隣接しているという。
・パス
2頂点間(始点と終点)を隣接している辺で辿った系列のうち、頂点も辺も重複しない系列をパス(道、経路)という。
以下、ACL間の関係を表現する数学的モデルの例について述べる。
<ACLのモデル表現>
空でない有限集合U、空でない有限集合P、及び有限集合Aについて、関数fAを、
fA:A→U×2P
とするとき、組(fA,U,P,A)を権限定義と呼ぶ。また、u∈Uを主体と呼び、また、ρ∈Pを権限と呼ぶ。集合Aの要素は、上述のACEを表す。ACE:α∈AについてfA(α)=(u,p)であるとき、ρ∈p⊆Pなる権限ρに関して、ACE:αは主体uに対して権限ρを許可することを表す。以下、ACEを単に(u,p)と表記し、fA(α)=(u,p)となるα∈Aを指す場合もある。
[権限定義及びACEの例]
U={鈴木太郎,山田花子,佐藤次郎,開発1グループ,管理責任者,全ユーザ}
P={読み込み権,書き込み権,管理権}
u=鈴木太郎,p={書き込み権,読み込み権}
ACE:(u,p)=(鈴木太郎,{書き込み権,読み込み権})
また、主体を抽出する関数prn:U×2P→Uを次のように定義する。
任意のx=(u,p)∈U×2Pに対してprn(x)=prn(u,p)=u
ACE:a∈Aの主体prn(fA(a))を略してprn(a)と表記する場合がある。
さらに、権限定義(fA,U,P,A)及び有限集合£において、関数fLを、
fL:£→{A´⊆A|∀a,b∈A´;prn(a)=prn(b)⇒fA(a)=fA(b)}
とするとき、組(fA,U,P,A,fL,£)をアクセス権と呼ぶ。£の要素は、上述のACLを表す。集合£をACL集合と呼ぶ。
また、ACLの取りうる値の集合、すなわち関数fLの値域全体を、fL(£)と表す。
fL(£)={A´⊆A|∀a,b∈A´;prn(a)=prn(b)⇒fA(a)
=fA(b)}
さらに、fL(L)=φとなるようなL∈£を空のACLと呼ぶ。図3の例のACL情報DB60では、ACL_ID"acl0"のACLが空のACLに該当する。
なお、ACL:Lの主体の集合{prn(a)|a∈L}を略してprn(L)と表記する場合がある。
また、関数FL:£→{x|x⊆U×2P}を次のように定義する。
FL(L)={(u,p)|∃a∈fL(L)⊆A(u,p)=fA(a)}⊆U×2P
以下、ACLを単に{α,β,…}又は{(u1,p1),(u2,p2),…}のように表記し、fL(L)={α,β,…}又はFL(L)={(u1,p1),(u2,p2),…}となるL∈£を指す場合もある。
[ACLの例]
ACL:L1={(鈴木太郎,{書き込み権,読み込み権}),(山田花子,{管理権,書き込み権,読み込み権}),(開発1グループ,{読み込み権})}
[ACLとしての条件を満たさない例]
M={(鈴木太郎,{書き込み権,読み込み権}),(鈴木太郎,{管理権,読み込み権})}
以上で説明したACL:L∈£は、図3の例を参照して説明したACL情報DB60に登録されるACLに対応する。ACL情報DB60におけるACL_IDは、各ACL:L∈£に対して付与される識別情報である。さらに、ACL情報DB60において、ACEの項目中の主体及び権限の各下位項目の値の組は、(u,p)∈FL(L)を表す。
上述のACL集合£に関し、例えば、次に述べるACL間の関係を定義する。
<ACL間の同値関係>
アクセス権(fA,U,P,A,fL,£)のACL集合£上に、次の条件を満たす二項関係〜を定義する。
(条件)L1,L2∈£について、FL(L1)=FL(L2)であるとき、L1〜L2
この条件の定義により、関係〜は、ACL集合£上の同値関係である。
<ACL間の半順序関係>
アクセス権(fA,U,P,A,fL,£)の上述の同値関係〜によるACLの商集合£/〜上に次の条件を満たす二項関係≦を定義する。
(条件)ACLの同値類[L1],[L2]⊆£について、任意の(u,p)∈FL(L1)に対して、あるp⊆p´⊆Pが存在して、(u,p´)∈FL(L2)であるとき、[L1]≦[L2]
この条件の定義より、関係≦は半順序関係である。この定義は、L1≠L2かつL1〜L2であっても、反対称律[L1]≦[L2]かつ[L2]≦[L1]ならば[L1]=[L2]が成立することに注意されたい。アクセス権(fA,U,P,A,fL,£)における組(£/〜,≦)をACL空間と呼ぶ。ACL空間は半順序集合である。
[半順序関係≦を有するACLの具体例]
ACL:L1={(鈴木太郎,{書き込み権,読み込み権}),(山田花子,{管理権,書き込み権,読み込み権}),(開発1グループ,{読み込み権})}
ACL:L2={(鈴木太郎,{書き込み権,読み込み権}),(山田花子,{読み込み権})}
のとき、[L2]≦[L1]である。
[半順序関係≦を有しないACLの具体例]
ACL:L1={(鈴木太郎,{書き込み権,読み込み権}),(山田花子,{管理権,書き込み権,読み込み権})}
ACL:L2={(鈴木太郎,{管理権,書き込み権,読み込み権}),(山田花子,{書き込み権,読み込み権})}
のとき、[L1]と[L2]との間に半順序関係≦は成り立たない。
なお、本実施形態の説明では、[L2]≦[L1]が成立するとき、ACL:L1をACL:L2の「下位のACL」と呼び、逆に、ACL:L2をACL:L1の「上位のACL」と呼ぶ。
<Allow-Denyモデル>
以上で説明したACLのモデルの例は、主体に対して操作(権限)を許可するモデルである。他の例では、主体に対して操作を明示的に禁止するモデルとしてもよい。このようなACLのモデルにおける半順序関係は、例えば、次のように定義すればよい。
次の条件をすべて満たすアクセス権(fA,U,P,A,fL,£)のACL空間(£/〜,≦)をAllow−DenyACL空間と呼ぶ。
(条件1)アクセス権(fA,U,P,A,fL,£)の部分集合P´⊆Pに対して、条件「任意のρ∈P´に対して、ρ≠g(ρ)かつρ=g(g(ρ))」を満たすP´上の全単射g:P´→P´が存在する。
(条件2)任意の(u,p)∈FL(£)に対して、ρ∈pならば¬(g(ρ)∈p)
(条件1)及び(条件2)より、P´を次のように分割できる。
P´=P+∪P-かつP+∩P-=φであり、
任意のρ∈P+に対して、g(ρ)∈P-
ACE(u,p)について、ρ∈pかつρ∈P+であればACE(u,p)は、主体uに対して権限ρを許可するといい、ω=g(ρ)∈pかつω∈P-であれば、ACE(u,p)は主体uに対して権限ρを禁止するという。
[Allow-DenyモデルによるACLの具体例]
P={読み込み許可,読み込み禁止,書き込み許可,書き込み禁止,管理許可,管理禁止}
g:P→P
g(読み込み許可)=読み込み禁止
g(読み込み禁止)=読み込み許可
g(書き込み許可)=書き込み禁止
g(書き込み禁止)=書き込み許可
g(管理許可)=管理禁止
g(管理禁止)=管理許可
P+={読み込み許可,書き込み許可,管理許可}
P-={読み込み禁止,書き込み禁止,管理禁止}
ACL:L1={(鈴木太郎,{書き込み許可,読み込み許可}),(山田花子,{管理許可,書き込み許可,読み込み許可}),(開発1グループ,{読み込み許可,管理禁止})}
なお、本具体例において、例えば、M={(鈴木太郎,{書き込み許可,読み込み許可,管理禁止,書き込み禁止})}などは、(条件1)及び(条件2)を満たさないため、ACLであるとはいえない。
以上、ACL間の半順序関係についての数学的モデルの例を示した。以下、ACLグラフの数学的モデルの例を示す。
<ACLグラフ>
アクセス権(fA,U,P,A,fL,£)のACL空間(£/〜,≦)におけるACL集合S⊆£に対し、辺集合Eを、
E={([L1],[L2])|[L1]≦[L2]かつ[L1]≠[L2];L1,L2∈S}⊆S/〜×S/〜
とする有向グラフG:(S/〜,E)を、ACL集合SのACLグラフと呼ぶ。
以上より、ACLグラフG:(S/〜,E)について、辺集合EはS/〜×S/〜の部分集合として定められる。したがって、例えば、関数fG:E→S/〜×S/〜を、
任意のe=([L1],[L2])∈Eに対してfG(e)=e=([L1],[L2])
と定義し、G:(S/〜,E)を、G:(fG,S/〜,E)と表現してもよい。
ACLグラフGの辺集合Eの定義より、ACLグラフGは、ループや多重辺を含まない単純グラフである。
また、辺集合Eの定義より、辺e=([L1],[L2])∈Eは、半順序関係≦に関し、上位のACL:L1から下位のACL:L2へ向かう辺であると解釈してよい。
図4に、ACLグラフの一例を示す。図4は、図3の例のデータ内容がACL情報DB60に登録されている場合のACLグラフの例である。図4において、ACL間を結ぶ矢印は、辺e∈Eを表し、図4中の矢印の向きは、半順序関係≦に関して、上位から下位へ向かう方向を表す。図3及び図4を参照し、ACL情報DB60において各ACL_IDの「上位ACL」及び「下位ACL」の各項目の値は、ACLグラフにおいて各ACL_IDに対応するACLを一方の端点とする辺の他方の端点となるACLを表す。さらに、「上位ACL」及び「下位ACL」の各項目の値は、それぞれ、各ACL_IDに対応するACLに対して半順序関係≦に関して上位及び下位のACLを表す。例えば、図4の例のACLグラフにおいて、ACL_ID"acl2"のACLに着目すると、"acl2"を一方の端点とする辺は、ACL_ID"acl0"のACLから"acl2"へ向かう辺、及び、"acl2"からACL_ID"acl3"のACLへ向かう辺である。図3の例の表において、ACL_ID"acl2"の「上位ACL」の項目の値は"acl0"であり、「下位ACL」の項目の値は"acl3"である。
<制約付きACLグラフ>
ACL空間(£/〜,≦)上のACLグラフ(S/〜,E)が次の条件を満たすとき、ACLグラフ(S/〜,E)を「制約付きACLグラフ」と呼ぶ。
(条件G1)あるL0∈Sが存在して、FL(L0)=φ
(条件G2)L1,L2∈Sに対して、[L1]≦[L2]ならば、[L1],e1,[L´],e2,…,en,[L2]となるような有向のパスが存在する。
すなわち、E´⊆Eが存在して次の条件を満たす。
(条件G2−1)あるL´∈Sが存在して、([L1],[L´])∈E´
(条件G2−2)あるL´´∈Sが存在して、([L´´],[L2])∈E´
(条件G2−3)([Lx],[Ly])∈E´に対してLy〜L2でなければ、あるLz∈Sが存在して、([Ly],[Lz])∈E´
(条件G1)は、制約付きACLグラフが空のACLを含むことを表す。空のACLは、ACL空間(£/〜,≦)における最小元である。
なお、(条件G2)に関し、定義より辺集合Eは有限集合であることに注意されたい。
(条件G1)及び(条件G2)より、制約つきACLグラフは連結グラフであって、任意の頂点に対して、空のACLに対応する頂点[L0]を始点とする有向のパスが存在することがわかる。したがって、ACL情報DBに空のACLを登録すると、ACL情報DB内のすべてのACLが1つのACLグラフに含まれることになる。図4に例示するACLグラフは、(条件G1)及び(条件G2)を満たす制約付きACLグラフである。
<最適化ACLグラフ>
上述の(条件G1)及び(条件G2)を満たす制約付きACLグラフであって、さらに、次の(条件G3)〜(条件G5)を満たすACLグラフ(S/〜,E)を、最適化ACLグラフと呼ぶ。
(条件G3)L1,L2∈Sに対して、あるL3∈Sが存在して、[L1]≦[L3]≦[L2]かつ[L1]≠[L3]≠[L2]ならば、([L1],[L2])∈Eではない
(条件G4)[L1]≦[L2]でも[L2]≦[L1]でもないようなL1,L2∈S⊆£に対して、あるu∈Uが存在して、(u,p1)∈FL(L1)かつ(u,p2)∈FL(L2)かつp1∩p2≠φであるならば、あるL≠φ∈Sが存在して、[L]≦[L1]かつ[L]≦[L2]
(条件G5) 任意のL∈Sの任意のx∈FL(L)に対して、あるL´∈Sが存在して、FL(L´)≠φかつ∀y∈FL(L´)に対してprn(y)=prn(x)
(条件G3)は、ACLグラフにおいて、任意の辺e∈Eの両端点を始点及び終点とするパスは、その辺e唯一つであることを表す。言い換えると、ACLグラフにおいて、任意の2つのACL:Li,Lj∈Sの間に、他のACL:Lk∈Sを通るパスが存在する場合、当該2つのACL:Li,Ljを両端とする辺が存在しない、つまり、Liから直接Ljへ向かうショートカットの辺が存在しないことを表す。
(条件G4)は、互いに半順序関係の成立しない任意の2つのACLについて、両者が共通の主体を含むACEを有し、かつ、そのACEに共通する権限が含まれる場合に、その2つのACLに対して上位のACLであって空でないACLがACLグラフ中に存在することを表す。
(条件G5)は、Sに関連する任意の主体u(=prn(x))に対して、ACEをただ1つだけ有し、その主体がuであるようなL´が必ず存在することを表す。
図4の例のACLグラフは、(条件G3)〜(条件G5)を満たす最適化ACLグラフである。
<ACLの積>
また、アクセス権(fA,U,P,A,fL,£)において、£上の演算*を定義する。L1,L2∈£に対しL1*L2∈£は次の条件を満たす。
(条件)FL(L1*L2)={(u,p1∩p2)|u∈prn(L1)∩prn(L2),(u,p1)∈FL(L1),(u,p2)∈FL(L2),p1∩p2≠φ}
定義より、任意のL∈£に対してL*φ=φ*L=φである。
<最適化ACLグラフへのACLの追加>
アクセス権(fA,U,P,A,fL,£)のACL空間(£/〜,≦)上の最適化ACLグラフG:(S/〜,E)に対して、[L+]∈S/〜でないACL:L+∈£が与えられたとき、次の(条件ADD1)〜(条件ADD4)を満たすS+の最適化ACLグラフG+:(S+/〜,E+)を、L+を追加した最適化ACLグラフと呼ぶ。
(条件ADD1)[L]∈S/〜ならば[L]∈S+/〜(元のグラフのノードをすべて含む)
(条件ADD2)[L+]∈S+/〜(追加するACLのノードを含む)
(条件ADD3)[L]∈S/〜ならば[L*L+]∈S+/〜(積のノードを含む)
(条件ADD4)あるu∈prn(L+)が存在して、u∈prn(L)となるL∈Sが存在しないならば、uの権限p:(u,p)∈FL(L+)に対し、FL(Lu)={(u,p)}となる[Lu]∈S+/〜が存在する(新しい主体のACE1つだけからなるACLを含む)
上記(条件ADD3)及び(条件ADD4)は、それぞれ、L+を追加した結果のACLグラフが最適化ACLグラフについての(条件G4)及び(条件G5)を満たすようにするための条件である。
ACLグラフ管理部140は、例えば、ACL情報DB60内の複数のACLが最適化ACLグラフG:(S/〜,E)を構成するときに、ACL情報DB60に未登録のACL:L+を新規登録する場合、上記(条件ADD1)〜(条件ADD4)を満たすようにACL情報DB60内のデータ内容の変更等を行うことで、L+を登録した後のACL情報DB60内の複数のACLが最適化ACLグラフを構成するようにする。
以下、ACLグラフに関連して文書管理サーバ10が行う処理の例を説明する。以下で説明する処理の例では、ACLグラフ管理部140は、ACL情報DB60内の複数のACLが上述の最適化グラフを構成するようにACL情報DB60内のデータを管理する。なお、以下の説明では、オブジェクト情報DB50において、各オブジェクトIDに関連付けて、図2の例の表に示す各項目の値が登録され、ACL情報DB60において、各ACL_IDに関連付けて、図3の例の表に示す各項目の値が登録されているとする。また、以下の説明では、ACL情報DB60には、少なくとも、空のACLが登録されているとする。
図5は、オブジェクトに対してACLを設定する際の文書管理サーバ10の処理手順の例を表す。
例えば、ユーザがクライアント20において、あるオブジェクトを指定し、指定したオブジェクトに対してACLを設定した場合、クライアント20は、ユーザが指定したオブジェクトのオブジェクトIDと、ユーザが設定したACLと、を含む設定要求を文書管理サーバ10に対して送信する。文書管理サーバ10の処理要求受付部100は、この設定要求を受け付けて、受け付けた設定要求を制御部110に対して出力する。
制御部110は、処理要求受付部100から設定要求を取得すると、図5に例示する手順の処理を開始する。まず、制御部110は、ユーザが指定したオブジェクトのオブジェクトID(以下、対象オブジェクトIDと呼ぶ)と、ユーザが設定したACL(以下、対象ACLと呼ぶ)と、を設定要求から抽出する(ステップS1)。次に、制御部110は、ACLグラフ管理部140に対して、対象オブジェクトID及び対象ACLを含む検索指示を出力し、ACL情報DB60内のACLのうち、対象ACLと同一のACLを検索させる(ステップS3)。
図6及び図7は、対象ACL検索処理(図5のステップS3)の詳細手順の例を表すフローチャートである。図6及び図7の例の手順の処理により、ACLグラフ管理部140は、ACL情報DB60内の複数のACLが構成するACLグラフを走査することで対象ACLと同一のACLを検索する。
図5のステップS3で制御部110から検索指示を受けたACLグラフ管理部140は、図6に例示する手順の処理を開始する。
図6を参照し、まず、ACLグラフ管理部140は、ACL情報DB60内に、対象オブジェクトIDに関連付けられたACLが存在するか否かを判定する(ステップS30)。この判定は、例えば、ACL情報DB60内の各ACL_IDに対応するレコードのうち、「オブジェクトID」の項目の値として対象オブジェクトIDを含むレコードが存在するか否かを判定することで行なう。対象オブジェクトIDに関連付けられたACLが存在する場合(ステップS30でYES)、当該ACLを注目ACLとして設定する(ステップS32)。対象オブジェクトIDに関連付けられたACLが存在しない場合(ステップS30でNO)、ACL情報DB60内の空ACLを注目ACLとして設定する(ステップS34)。
「注目ACLとして設定する」処理(ステップS32又はステップS34)は、例えば、該当するACL(ステップS32の場合は対象オブジェクトIDに関連付けられたACLであり、ステップS34の場合は空ACLである)に対応するレコードをACL情報DB60から取得し、取得したレコードに含まれる情報(ACL_ID,ACE,上位ACL,下位ACLなど)を注目ACLの値とする処理を表す。以下の説明で、ACL情報DB60内の特定のACLについて「注目ACLとする」と記載する場合も同様の処理を表すものとする。
ステップS32又はステップS34では、ACLグラフの走査の起点が設定される。
注目ACLの値が設定されると(ステップS32又はステップS34)、次に、ACLグラフ管理部140は、対象ACLと注目ACLとが一致するか否かを判定する(ステップS36)。ここで、対象ACL及び注目ACLのそれぞれに含まれるACEのすべてに関し、それぞれの主体及び権限の組み合わせが同一であれば、対象ACLと注目ACLとが一致すると判定される。両者が一致する場合(ステップS36でYES)は、注目ACLを検索結果とし(ステップS38)、ACL検索処理を終了する。両者が一致しない場合(ステップS36でNO)、処理は、図7のステップS40に進む。
図7を参照し、ACLグラフ管理部140は、対象ACLと注目ACLとを比較し、対象ACL中のACEにおいて、注目ACL中のACEから削除されている主体又は権限が存在するか否かを判定する(ステップS40)。ここで、「削除されている主体」とは、注目ACL中のACEに含まれているけれども対象ACL中のACEには含まれていない主体を指す。また、「削除されている権限」とは、注目ACLと対象ACLとの間で共通の主体を含むACE同士を比較した場合に、注目ACLのACEには含まれているけれども、対象ACLのACEには含まれていない権限を指す。
例えば、図8を参照し、ACL_ID"acl9"のACLが注目ACLであり、ACL:Liが対象ACLであるとする。注目ACL"acl9"中の各ACE({鈴木太郎,mwr},{山田花子,mwr},{営業一課,-wr},{全ユーザ,--r})と、対象ACL:Li中の各ACE({鈴木太郎,-wr},{営業一課,-wr},{佐藤次郎,-wr})と、を比較すると、対象ACL:Liにおいて、注目ACL"acl9"から「削除されている主体」は、「山田花子」及び「全ユーザ」である。また、注目ACL"acl9"と対象ACL:Liとの間で共通の主体を含むACEは、主体「鈴木太郎」及び「営業一課」を含むACEである。共通の主体「鈴木太郎」を含むACE同士を比較すると、注目ACL"acl9"中のACEの権限は、「mwr」であり、対象ACL:Li中のACEの権限は「-wr」であるため、権限「m(管理権限)」が「削除されている権限」に該当する。また、共通の主体「営業一課」を含むACE同士を比較すると、注目ACL"acl9"中のACEの権限と対象ACL:Li中のACEの権限とは、いずれも「-wr」で同一であるため、主体「営業一課」を含むACEに関しては「削除されている権限」は存在しない。図8の例の場合、図7のステップS40の判定結果はYESとなる。
図7の説明に戻り、対象ACL中のACEにおいて、注目ACL中のACEから削除されている主体又は権限が存在する場合(ステップS40でYES)、ACLグラフ管理部140は、注目ACLの上位ACLのいずれかが対象ACLと一致するか否かを判定する(ステップS50)。削除されている主体又は権限が存在する場合、半順序関係≦の定義より、対象ACLが、注目ACLに対して下位のACLである可能性はない。よって、ACLグラフ管理部140は、注目ACLの上位ACLの中から対象ACLと一致するACLを検索する。注目ACLの上位ACLのうち、対象ACLと一致するACLが存在すれば(ステップS50でYES)、当該一致する上位ACLを検索結果とし(ステップS54)、検索処理を終了する。対象ACLと一致するACLがなければ(ステップS50でNO)、注目ACLの上位ACLのうちの1つを新たな注目ACLとして(ステップS52)、処理はステップS40に戻る。ステップS52で、注目ACLの上位ACLが複数存在する場合、ACLグラフ管理部140は、例えば、複数の上位ACLのうち、対象ACLと共通の主体及び権限を含むACEを最も多く有する上位ACLを優先して1つ選択し、選択した上位ACLを新たな注目ACLとする。
対象ACL中のACEにおいて、注目ACL中のACEから削除されている主体又は権限が存在しない場合(ステップS40でNO)、ACLグラフ管理部140は、注目ACLの下位ACLのいずれかが対象ACLと一致するか否かを判定する(ステップS42)。削除されている主体又は権限が存在しない場合、対象ACLは、注目ACL中のACEの主体及び権限をすべて含む。さらに、対象ACLは、注目ACL中のACEに含まれない主体を含むACE、及び、注目ACLのACEと同一の主体を含むACEであって注目ACLのACEに含まれない権限を含むACE、の少なくとも一方を有する。したがって、半順序関係≦の定義より、対象ACLは、注目ACLに対して下位のACLである。よって、ACLグラフにおいて注目ACLに対して下位であるACLの中に対象ACLと一致するACLが存在する可能性がある。注目ACLの下位ACLのうち、対象ACLと一致するACLが存在すれば(ステップS42でYES)、当該一致する下位ACLを検索結果として(ステップS54)、検索処理を終了する。対象ACLと一致するACLが存在しなければ(ステップS42でNO)、ACLグラフ管理部140は、注目ACLの下位ACLのいずれかが対象ACLに対して上位のACLであるか否かを判定する(ステップS44)。
ステップS44の判定は、注目ACLの下位ACL:Ldのうち、対象ACL:Liとの間に半順序関係Ld≦Liが成立するACL:Ldが存在するか否かを判定することで行われる。Ld≦Liが成立する場合、当該ACL:Ldは、対象ACLに対して上位のACLである。
注目ACLの下位ACLのうち対象ACLに対して上位のACLが存在する場合(ステップS44でYES)、該当する下位ACLを注目ACLとし(ステップS48)、処理はステップS42に戻る。ステップS44の判定の結果、該当するACLが複数存在する場合は、それら複数のACLの中からいずれか1つを選択して、選択したACLをステップS54で注目ACLとすればよい。例えば、該当する複数のACLのうち、対象ACLと共通の主体及び権限を最も多く含むACLを優先的に選択して注目ACLとする。
注目ACLの下位ACLのうち対象ACLに対して上位のACLが存在しない場合(ステップS44でNO)、検索結果を「NULL」とし(ステップS46)、検索処理を終了する。
再び図5を参照し、対象ACL検索処理(ステップS3)が終了すると、検索結果がNULLでない値を持つか否かが判定される(ステップS5)。検索結果がNULLでない値を持つ場合(ステップS5でYES)、制御部110は、検索結果のACLのACL_IDと対象オブジェクトIDとを関連付ける処理を行う(ステップS7)。ステップS7で、例えば、制御部110は、オブジェクト情報管理部130を介してオブジェクト情報DB50を参照し、対象オブジェクトIDのレコードにおいて、ACL_IDの項目の値を検索結果のACLのACL_IDに書き換える。ここで、制御部110は、書き換え前のACL_IDの項目の値がNULLでなければ、その書き換え前のACL_IDを保持しておく。さらに、制御部110は、ACLグラフ管理部140を介してACL情報DB60を参照し、検索結果のACLに対応するレコードのオブジェクトIDの項目に対象オブジェクトIDを追加する。また、さらに、制御部110は、前述のように書き換え前のACL_IDを保持している場合は、そのACL_IDに対応するACL情報DBのレコードのオブジェクトIDの項目から対象オブジェクトIDを削除する。ステップS7の後、図5の例の手順の処理は終了する。
対象ACL検索処理の検索結果がNULLである場合(ステップS5でNO)、ACLグラフ管理部140は、対象ACLにACL_IDを付与し、付与したACL_IDに対応するレコードを新たに生成してACL情報DB60に登録する(ステップS9)。この新たなレコードにおいて、ACL_IDの項目の値は、付与したACL_IDに、ACEの項目の値は、対象ACLのACEに設定される。また、上位ACLの項目には、図7の例の処理が(ステップS46の後に)終了した時点での注目ACLのACL_IDが設定される。下位ACLの項目の値はNULLに設定される。
次に、制御部110は、対象ACLのACL_IDと対象オブジェクトIDとを関連付ける処理を行う(ステップS11)。制御部110は、オブジェクト情報DB50において、対象オブジェクトIDのレコードのACL_IDの項目の値を対象ACLのACL_ID(ステップS9で付与)に書き換え、ACL情報DB60において、対象ACLに対応するレコードのオブジェクトIDの項目に対象オブジェクトIDを追加する。さらに、オブジェクト情報DB50の対象オブジェクトIDのレコードにおいて書き換え前のACL_IDの値がNULLでない場合、その書き換え前のACL_IDに対応するACL情報DB60のレコードにおいて、オブジェクトIDの項目から対象オブジェクトIDを削除する。
その後、制御部110は、ACLグラフ管理部140に対して指示を出し、対象ACLを追加した後のACLグラフを最適化する処理を実行させる(ステップS13)。ACLグラフ最適化処理では、ACLグラフ管理部140は、例えば、上記の<最適化ACLグラフへのACLの追加>で示した(条件ADD1)〜(条件ADD4)が満たされるようにACL情報DB60内のデータ内容の変更等を行う。
図9は、ACLグラフ最適化処理の手順の一例を示すフローチャートである。図5のステップS13が開始されると、ACLグラフ管理部140は、図9の例の手順の処理を開始する。
図9を参照し、まず、ACLグラフ管理部140は、新規ACL(この例では、図5のステップS9でACL情報DB60に登録された対象ACL)中の各ACEの主体を含むACEのみからなるACLがACL情報DB60内に存在するか否かを判定する(ステップS130)。ステップS130の判定は、新規ACLを含むACLグラフが上述の(条件ADD4)を満たすか否かの判定である。新規ACL中のACEのうち、その主体を含むACEのみからなるACLがACL情報DB60内に存在しないACEがある場合(ステップS130でNO)、ACLグラフ管理部140は、該当するACEのみからなるACLを生成し、ACL情報DB60に登録する(ステップS132)。
ステップS132で、ACLグラフ管理部140は、該当するACEの主体及び権限を含むACEのみからなるACLに対してACL_IDを付与し、そのACLに対応するレコードをACL情報DB60に登録する。ステップS132でACL情報DB60に登録されるレコードは、上位ACLの項目の値として空ACLのACL_IDを含み、下位ACLの項目の値として新規ACLのACL_IDを含む。また、ステップS132では、ACL情報DB60の新規ACLに対応するレコードにおいて、該当するACEのみを含むACLとして新たに登録されたACLのACL_IDを、上位ACLの値として登録する。
例えば、空のACLだけがACL情報DB60に登録されている場合に、図4に例示するACL"acl7"と同様のACL({鈴木太郎,mwr},{営業一課,-wr})が、新たに図5のステップS9でACL情報DB60に登録されたとする。この例の場合、新規ACL中の各ACEの主体「鈴木太郎」及び「営業一課」を含むACEのみからなるACLは、ACL情報DB60内に未だ存在しない。したがって、この例において、ACLグラフ管理部140は、図9のステップS132で、主体「鈴木太郎」及び「営業一課」のそれぞれを含むACEのみからなるACLを生成し、生成した各ACLをACL情報DB60に登録する。このとき生成される各ACL中のACEに含まれる権限は、新規ACL中の対応するACEに含まれる権限と同様であってよい。本例では、図4に例示するACL"acl7"中の各ACEを含むACL({鈴木太郎,mwr})及び({営業一課,-wr})が生成されてACL情報DB60に登録される。
図9のステップS132の後、又は、新規ACL中の各ACEの主体を含むACEのみからなるACLがACL情報DB60内にすでに存在する場合(ステップS130でYES)、ACLグラフ管理部140は、新規ACLに接続される辺を生成する(ステップS134)。ステップS134の辺の生成は、例えば、以下の手順で行われる。まず、ACLグラフ管理部140は、ACL情報DB60において、(例えば、図5のステップS9、又は図9のステップS132で)すでに新規ACLの上位ACL又は下位ACLとして登録されているACL以外のACLの中から、新規ACLに対して上位又は下位であるACLを検索する。この検索は、例えば、ACL情報DB60内の各ACL中のACEと新規ACL中のACEとを比較し、半順序関係≦が成立するか否かを判定することで行う。次に、新規ACLと検索された上位又は下位のACLとの間の辺を表す情報をACL情報DB60に登録する。つまり、ACL情報DB60において、新規ACLに対応するレコードの上位ACL又は下位ACLの項目の値として、検索された上位又は下位のACLのACL_IDを登録する。さらに、新規ACLに対して上位のACLが検索されていた場合は、その上位のACLに対応するレコードの下位ACLの項目の値として新規ACLのACL_IDを登録し、下位のACLが検索されていた場合は、その下位のACLに対応するレコードの上位ACLの項目の値として新規ACLのACL_IDを登録する。以上の例の手順の処理により、ACLグラフにおいて新規ACLに接続される辺が生成される。
なお、ステップS134で新規ACLに接続される辺を生成した結果、ショートカットの辺に該当する辺(上記<最適化ACLグラフ>の(条件G3)参照)が生じた場合、ACLグラフ管理部140は、当該ショートカットの辺を削除する。すなわち、ACL情報DB60において、当該ショートカットの辺の両端点のACLにそれぞれ対応する2つのレコードの上位ACL及び下位ACLの項目から、互いのACL_IDを削除する。この処理により、(条件G3)が満たされる。
再び図9を参照し、ステップS134の後、ACLグラフ管理部140は、ACLの補完が必要であるか否かを判定する(ステップS136)。これは、上述の(条件ADD3)を満たすか否かの判定である。新規ACL:L+との間の積のACL:Lk*L+が存在しないACL:LkがACL情報DB内に存在する場合、(条件ADD3)が満たされないので、積のACL:Lk*L+を補完する必要があると判定される(ステップS136でYES)。この場合、ACLグラフ管理部140は、積のACL:Lk*L+を補完ACLとして生成し、補完ACLに対応するレコードをACL情報DB60に登録する(ステップS138)。補完ACLの下位ACLとしては、補完ACLを生成する演算*の引数に該当するACL、つまり、ACL:Lk及び新規ACL:L+のACL_IDが登録される。補完ACLの上位ACLとしては、例えば、ACL情報DB内で補完ACLに対して上位であるACLを検索した結果のACLのACL_IDが登録される。
補完ACLの登録の後、補完ACLの下位ACLを参照するオブジェクトが存在するか否かを判定する(ステップS140)。この判定は、例えば、ACL情報DB60において、補完ACLの下位ACLに対応するレコードのオブジェクトIDの項目の値がNULLであるか否かを判定することで行う。そのようなオブジェクトが存在しない(オブジェクトIDの項目の値がNULLである)場合(ステップS140でNO)、補完ACLの下位ACLをACL情報DB60から削除する(ステップS142)。ACLグラフ管理部140は、ACL情報DB60において、補完ACLの下位ACLに対応するレコードを削除するとともに、当該削除されるACLの下位ACLを、補完ACLの新たな下位ACLとして登録する。また、当該削除されるACLと辺で接続されるACLのレコードにおいて、上位ACL又は下位ACLの項目の値から当該下位ACLのACL_IDを削除する。
ステップS140,S142の処理により、ACLグラフ管理部140は、ACLグラフにおいて、オブジェクトに対するアクセスの可否の決定に用いられないACLの増加を防ぐ。
ステップS136でACLの補完は必要ない((条件ADD3)が満たされる)と判定された場合(ステップS136でNO)、ステップS140で補完ACLの下位ACLを参照するオブジェクトが存在する(オブジェクトIDの項目の値がNULLでない)と判定された場合(ステップS140でYES)、又は、ステップS142で補完ACLの下位ACLをACL情報DB60から削除した後、図9の例のACLグラフ最適化処理は終了する。
ここで、図10〜図14を参照し、図9の例のACLグラフ最適化処理の具体例を述べる。例えば、図10に例示するACLグラフに対して、図11の例の内容のACL"acl105"が新規ACLとして追加された場合、図9の例の処理手順のステップS134までの処理が終了した段階で、図12の例のACLグラフが得られる。このとき、ACL"acl105"とACL"acl102"との間には、ACLグラフ中に積のノードが存在しない。したがって、図9の例の処理手順のステップS136の判定の結果、ACL"acl105"とACL"acl102"との積のノードが補完ACLとして生成されてACL情報DB60に登録され(ステップS138)、図13に例示するようなACLグラフが得られる。図13を参照し、ACL"acl106"が補完ACLに該当する。
図13のACLグラフの例において、補完ACL"acl106"は、最適化ACLグラフの条件を満たすために生成されたACLであって、このACLを参照するオブジェクトは存在しない。したがって、例えば、補完ACL"acl106"の下位ACLであるACL"acl102"についても、いずれのオブジェクトからも参照されていない場合、図9の例の処理のステップS140,142により、ACL"acl102"は削除される。その結果、図14に例示するACLグラフのように、ACL"acl102"の下位ACLであったACL"acl100"が、補完ACL"acl106"の下位ACLとなる。
再び図5を参照し、ACLグラフの最適化処理(ステップS13)が終了すると、図5の例の手順の処理は終了する。
以上、図5〜図7,図9の各フローチャートの例を参照して説明した処理により、オブジェクト情報DB50及びACL情報DB60において、ユーザが指定したオブジェクトのオブジェクトIDと、ユーザが指定したACLと同一の内容を有するACLのACL_IDと、が関連付けられる。上述の例の処理では、ユーザが指定したACLと同一のACLがACL情報DB60内に既に存在すれば、そのACL_IDと対象オブジェクトIDとを関連付ける。ユーザが指定したACLと同一のACLがACL情報DB60内に存在しなければ、そのようなACLを新たに生成してACL情報DB60に登録し、新規登録されたACL_IDと対象オブジェクトIDとを関連付ける。したがって、上述の例の処理では、ユーザがオブジェクトにACLを設定する際に、ACL情報DB60内に登録済みのACLの内容が変更されることはない。例えば、すでにACLが設定されていたオブジェクト(ACL情報DB60内の特定のACLに関連付けられていたオブジェクト)について、ユーザがACLの内容を変更する操作を行った場合であっても、当該オブジェクトのオブジェクトIDに関連付けられるACL_IDが変更されるだけで、変更前に当該オブジェクトに設定されていたACL自体の内容が変更されることはない。
なお、以上では、ACL情報DB60において空ACLのレコード(図3の例のACL_ID"acl0"のレコード)が登録されているものとして、図5〜図7,図9の各フローチャートに従った処理の例を説明した。しかしながら、上述の処理の例と同様の処理を実行するためには、少なくとも空ACLのACL_IDが特定されていれば、ACL情報DB60において空ACLに対応するレコードを実際に登録しておかなくてもよい。例えば、空ACLに対応するレコードをACL情報DB60に登録せずに、空ACLに対して付与されたACL_IDだけをACL情報DB60に記憶させておけばよい。空ACLについて、対応するレコードを登録せずにACL_IDだけをACL情報DB60に記憶させておく場合、空ACLの下位ACLを取得する処理(例えば、図7のステップS42,S44)では、ACLグラフ管理部140は、空ACLのACL_IDを上位ACLの項目の値に含むレコードをACL情報DB60から検索し、検索結果のレコードのACL_IDを取得することで、空ACLの下位ACLを取得する。
以上、ACLグラフに対して変更が加えられる場合の文書管理サーバ10の処理の例を述べた。以下、文書管理サーバ10がACLグラフを利用してオブジェクト及びACLに関する情報を出力する場合の処理の例を述べる。
例えば、特定の主体(ユーザ又はグループ)に対して特定の種類の操作の実行が許可又は禁止されているオブジェクトに関する情報を出力するようクライアント20から要求を受けると、文書管理サーバ10は、ACLグラフを用いて該当するオブジェクトを検索し、検索結果のオブジェクトに関する情報をクライアント20に対して出力する。
図15は、クライアント20からの上述の例の出力要求に応じて文書管理サーバ10が行う処理の手順の例を示すフローチャートである。制御部110は、処理要求受付部100を介してクライアント20からの出力要求を受けると、検索処理部160に対して、図15に例示する手順の処理の実行の開始を指示する。
図15を参照し、検索処理部160は、処理要求受付部100及び制御部110を介して取得されるクライアント20からの出力要求から、主体及び操作種類を取得する(ステップS2)。次に、検索処理部160は、ユーザ情報DB70を参照し、ステップS2で取得した主体がユーザIDである場合(ステップS4でYES)、当該ユーザIDのユーザが所属するグループのグループIDをユーザ情報DB70から取得する(ステップS6)。ステップS6の後、又は、ステップS2で取得した主体がユーザIDでなくグループIDである場合(ステップS4でNO)、処理は、ステップS8へ進む。ステップS8で、検索処理部160は、ACLグラフ管理部140を介してACL情報DB60を参照し、ステップS4〜S6で取得されたユーザID又はグループIDのそれぞれと、ステップS2で取得された操作種類と、を含むACEのみからなるACLのACL_IDを取得する(ステップS8)。そして、取得したACL_IDごとに、ACLグラフ管理部140による下位ACL探索処理(ステップS10)を実行する。
図16は、下位ACL探索処理の手順の一例を示すフローチャートである。まず、検索処理部160は、現在の処理対象のACL_IDを注目IDとする(ステップS100)。次に、注目IDを中間結果リストに加える(ステップS102)。中間結果リストは、要求された処理の処理結果を求めるための材料となる情報を蓄積するために構築されるリストである。注目IDを中間結果リストに加えた後、検索処理部160は、ACLグラフ管理部140を介してACL情報DB60内の注目IDに対応するレコードを参照し、注目IDのACLに下位ACLが存在するか否かを判定する(ステップS104)。注目IDのACLに下位ACLが存在する場合(ステップS104でYES)、その下位ACLのACL_IDごとに、下位ACL探索処理を再帰的に呼び出して実行する(ステップS10)。注目ACLに下位ACLが存在しない場合(ステップS104でNO)、図16の例の処理は終了する。
再び図15を参照し、ステップS8で取得したACL_IDごとの下位ACL探索処理(ステップS10)が終了すると、中間結果リストには、ACL情報DB60内のACLのうち、指定されたユーザID又はグループIDが表すユーザ又はグループに対して、指定された種類の操作の実行を許可又は禁止するすべてのACLのACL_IDが含まれていることになる。
例えば、図17を参照し、指定されたユーザIDが「ユーザA」であり、ユーザAがグループP,Qに所属する場合に、図15のステップS2〜S10までの処理が終了した時点で、ACLグラフ中のACLのうち中間結果リストに含まれるACLの例を斜線で表す。斜線で表されるACLは、ユーザA、グループP、及びグループQのそれぞれと、指定された操作種類と、を含むACEのみからなるACL(破線円で囲んだACL)、並びに、各ACLの下位に位置するACLである。
図15の説明に戻り、検索処理部160は、ACLグラフ管理部140を介してACL情報DB60を参照して、中間結果リストに含まれるACL_IDに関連付けられるオブジェクトIDを取得し、そのオブジェクトIDのリストを制御部110に渡す(ステップS12)。制御部110は、検索処理部160から取得したオブジェクトIDのリストを用いて、クライアント20の要求に応じた出力情報を生成する。例えば、該当するオブジェクトのオブジェクト名のリストの表示を要求されている場合、オブジェクト情報管理部130を介してオブジェクト情報DB50を参照し、検索処理部160から取得したリスト中の各オブジェクトIDのオブジェクト名を取得し、そのオブジェクト名のリストを出力情報として生成する。制御部110は、処理結果出力部120を介して、出力情報を要求元のクライアント20に対して出力する(ステップS14)。
文書管理サーバ10は、また、ACLグラフの構造を用いて、ACL情報DB60内のACL同士の関係を図式的にクライアント20の表示装置に表示させる処理を行う場合もある。
図18は、文書管理サーバ10がクライアント20の表示装置に表示させる表示画面の一例である。画面左上のオブジェクトツリー表示エリア200には、文書DB40においてオブジェクトが格納されるフォルダの構造を表す木構造が表示される。画面右側の一覧表示エリア202には、オブジェクトツリー表示エリア200において選択されたフォルダに格納されたオブジェクトのリストが表示される。オブジェクトツリー表示エリア200で表示されるフォルダの名前、及び、一覧表示エリア202で表示される文書ファイルの名前や作成者などは、各オブジェクトについてオブジェクト情報DB50を参照することで取得される情報である。画面左下のACLツリー表示エリア204には、一覧表示エリア202において選択されたオブジェクトに設定されたACLに関する木構造が表示される。このACLの木構造は、ACL情報DB60内のACLグラフの構造に従って、文書管理サーバ10のACLツリー表示部150が生成する。図18の例では、ACLツリー表示エリア204において、一覧表示エリア202で選択されたオブジェクトに関連付けられるACLが強調表示されている。図18の例の表示画面をクライアント20に表示させる場合、例えば、文書管理サーバ10は、選択されたオブジェクトのオブジェクトIDをクライアント20から取得すると、オブジェクト情報DB50を参照し、当該オブジェクトIDに関連付けられるACL_IDを取得する。そして、取得したACL_IDに対応するACLのアイコンを強調表示させる表示情報をクライアント20に対して出力することで、ACLツリー表示エリア204において対応するACLを強調表示させる。
なお、一覧表示エリア202で選択されたオブジェクトに対応するACLをACLツリー表示エリア204において強調表示させる例について説明したが、ACLツリー表示エリア204において特定のACLが選択された場合に、一覧表示エリア202中のオブジェクトのうち、選択されたACLに関連づけられるオブジェクトを強調表示させてもよい。この例の場合、文書管理サーバ10は、例えば、選択されたACLのACL_IDをクライアント20から取得し、ACL情報DB60を参照して当該ACL_IDに関連付けられるオブジェクトIDを取得する。そして、オブジェクト情報DB50を参照し、ACL情報DB60から取得したオブジェクトIDのうち、一覧表示エリア202に表示されているオブジェクトのオブジェクトIDを特定し、特定したオブジェクトIDに対応するオブジェクトを強調表示させる表示情報をクライアント20に対して出力する。またあるいは、一覧表示エリア202中のオブジェクトのうち、ACLツリー表示エリア204で選択されたACLに関連付けられるオブジェクトのみを表示させるフィルタリング処理を行ってもよい。
図19は、表示画面の他の一例である。図19の例では、ACLツリー表示エリア204においてACLが選択された場合に、オブジェクトツリー表示エリア200で選択されたフォルダに含まれるオブジェクト以外のオブジェクトも含め、選択されたACLに関連付けられるすべてのオブジェクトのリストを一覧表示エリア202に表示させる。この場合、文書管理サーバ10は、例えば、選択されたACLのACL_IDに関連付けられるオブジェクトIDをACL情報DB60から取得する。そして、取得したオブジェクトIDに関する情報(名前、タイプ、作成者など)をオブジェクト情報DB50から取得することで、一覧表示エリア202に表示させる表示情報を生成してクライアント20に対して出力する。また例えば、選択されたACLに関連付けられるオブジェクトだけでなく、選択されたACLに対して下位であるACLに関連付けられるオブジェクトをすべて表示させてもよい。また、図19の例において、一覧表示エリア202に表示されたオブジェクトのうちの1つをユーザが選択した場合に、選択されたオブジェクトが格納されるフォルダをオブジェクトツリー表示エリア200において強調表示させてもよい。
図20は、表示画面のさらに他の一例を示す。図20の例では、ACLの木構造を表示する表示画面においてACLが選択された場合に、選択されたACLに関連付けられるオブジェクトを、木構造において当該ACLの下位に位置するように表示させる。
以上、図18〜図20のいずれの表示画面の例においても、文書管理サーバ10は、ACL間の関係をACLの木構造で表す。一方、ACLグラフの構造は、必ずしも木構造であるとは限らない。文書管理サーバ10のACLツリー表示部150は、ACLグラフの構造に対応する構造を有するACLの木構造を表す情報を生成することで、クライアントの表示画面に当該木構造を表示させる。
以下、ACLグラフに対応する構造を有するACLの木構造をACLグラフの「擬似木」と呼ぶ。ACLグラフの擬似木は、例えば、次のような数学的モデルによって表される。
<ACLグラフの擬似木>
アクセス権(fA,U,P,A,fL,£)のACL空間(£/〜,≦)上の制約つきACLグラフ(S/〜,E)に対し、次の条件を満たす有向グラフ(g,VT,ET)を、ACLグラフ(S/〜,E)の擬似木と呼ぶ。
(条件T1)(g,ET,VT)は単連結で閉路を持たない。
(条件T2)h:VT→S/〜となる全射が存在する。
(条件T3)任意のv1∈VTに対する任意の([L],h(v1))∈Eに対して、あるv0∈VTおよびe∈ETが存在して、h(v0)=[L]かつg(e)=(v0,v1)。
例えば、図21を参照し、図21(a)は、ACLのグラフ構造の例を表し、図21(b)は、図21(a)のACLグラフに対応する擬似木の例を表す。図21(a)を参照すると、ACL:Dは、ACLグラフにおいて、ACL:A及びACL:Bの2つの上位ACLを有する。一方、木構造は、2つ以上の親ノードを有するノードが存在しないデータ構造である。したがって、ACLツリー表示部150は、ACLグラフにおいて複数の上位ACLを有するACLについて、このACLに対応する2つのノードを生成することで、ACLグラフの擬似木を生成する。例えば、図21(a)の例のACL:Dに対応するノードを2つ生成し、各ノードを、ACL:Aに対応するノードの子ノード及びACL:Bに対応するノードの子ノードとする。図21(b)を参照し、表示画面上のACLの木構造において、ACL:Dは、ACL:A及びACL:Bの子ノードとして2箇所に現れる(破線円)が、木構造におけるこれら2つのノードは、ACLグラフにおける1つのノードであるACL:Dに対応する。
以下、ACLツリー表示部150がACLグラフから木構造を生成する処理の手順を説明する。まず、ACLツリー表示部150は、処理要求受付部100及び制御部110を介して取得されるクライアント20からの表示要求に応じて、ACL情報DB60内の複数のACLのうち、表示対象とするACLグラフの部分を特定する。表示対象のACLグラフの部分は、例えば、ACLグラフにおいて、クライアントの表示画面で選択されたオブジェクトに関連付けられたACL、及び当該ACLからACLグラフ中で所定数以内の辺を介して接続されるACLを含む部分グラフとする。あるいは、クライアントにおいて特定のACLが指定された場合に、指定されたACLと当該ACLからACLグラフ中で所定数以内の辺を介して接続されるACLとを含む部分グラフを表示対象の部分としてもよい。次に、表示対象のACLグラフの部分のうち、木構造の生成のための分離処理が必要なACL(ノード)を特定する。分離処理が必要なノードは、図21の例で説明したように、複数の上位ACL(上位ノード)を有するノードである。そして、分離処理が必要なノードについて、当該ノードが有する上位ノードの数だけ、当該ノードの下位グラフに対応するグラフを生成する。ここで、あるノードの「下位グラフ」とは、当該ノードと当該ノードに対して下位であるノードであって当該ノードへのパスを有するノードとを含む部分グラフを指す。
例えば、図22を参照し、図22(a)において、ノードdは、2つの上位ノードb,cを有する。ACLツリー表示部150は、ノードdの下位グラフ(ノードd及びノードeを含む)に対応するグラフを、ノードdの上位ノードの個数(2つ)だけ生成し、ノードdに対応する各ノードd1,d2を各上位ノードb,cの子ノードとする(図22(b))。以上の処理を、分離処理が必要なノードがなくなるまで繰り返すことで、ACLグラフの擬似木が生成される。
なお、分離処理が必要なノードが複数存在する場合、分離処理を行う順番によって、結果として得られる擬似木が異なる場合がある。一例として、図23を参照し、図23(a)のACLグラフの擬似木を生成する場合について考える。図23(a)のACLグラフにおいて、分離処理が必要なノードは、ノードd及びノードeである。図23(a)のACLグラフに対し、ノードeについて最初に分離処理を行うと、図23(b)に例示するグラフが得られ、次に、ノードdについて分離処理を行うと、図23(c)に例示するグラフが得られる。図23(c)に例示するグラフは、分離処理が必要なノードを含まず、図23(a)の例のACLグラフの擬似木である。クライアント20の表示画面においては、図23(c)の例の擬似木をACLの木構造として表示させればよい。
一方、図23(a)の例のACLグラフに対し、最初にノードdについて分離処理を行うと、図23(d)の例のグラフが得られる。図23(d)の例のグラフは、図23(a)におけるノードeに対応する2つのノードe1,e2を含む。ノードe1,e2は、それぞれ、上位ノードを2つ(ノードd1及びノードf、ノードd2及びノードf)有するので、いずれのノードe1,e2についても分離処理が必要である。各ノードe1,e2について分離処理を行うと、図23(e)の例のグラフが得られる。図23(e)の例のグラフは、分離処理の必要なノードを含まず、図23(a)の例のACLグラフの擬似木である。しかしながら、図23(e)の例の擬似木は、ノードfが2つの子ノードe12,e22を有する点で、最初にノードeに対して分離処理を行った結果の図23(c)の例の擬似木と異なる。また、図23(e)の例の擬似木において、ノードe12,e22は、いずれも、図23(a)の例のACLグラフにおける同じ1つのノードeに対応するものであり、かつ、同じ親ノードfを有する。したがって、図23(e)の例の擬似木におけるノードe12,e22は互いに冗長である。
図23(a)の例のACLグラフにおいて、ノードdについてノードeより先に分離処理を行った場合に、互いに冗長なノードe12,e22が生成されるのは、分離処理が必要であるノードdの下位グラフに含まれるノードeが、当該下位グラフ中のノード以外のノードfを上位ノードとして有するためである。
図23(e)の例のように互いに冗長なノードを含む擬似木の生成を防ぐため、ACLグラフにおいて、「ノードxが複数の上位ノードを有し、かつ、ノードxの下位グラフ中のノードx以外のノードのうち、下位グラフ中のノード以外のノードを上位ノードとして有するノードが存在しない」という条件が満たされる場合に、ノードxについて分離処理を行い、この条件が満たされない場合には、ノードxについて分離処理を行わないものとする。この条件を満たすノードを「枝分かれ可能」なノードと呼ぶ。
図23(a)の例のACLグラフにおいて、ノードeは枝分かれ可能であるが、ノードdは枝分かれ可能でない。枝分かれ可能であるノードeについて分離処理を行うと、その結果のグラフ(図23(b))では、ノードdは、枝分かれ可能となることに注意されたい。
枝分かれ可能なノードが複数存在する場合は、いずれのノードから分離処理を行っても、結果として得られる擬似木は同様のものとなるし、結果の擬似木において互いに冗長なノードが現れることもない。例えば、図24(a)に例示するACLグラフにおいて、ノードd,gはいずれも枝分かれ可能である。ノードgについて最初に分離処理を行い(図24(b))、次に、ノードdについて分離処理を行うと、図24(d)の例の擬似木が得られる。また、図24(a)の例のACLグラフにおいて、最初にノードdについて分離処理を行い(図24(c))、次に、ACLグラフのノードgに対応する2つのノードg´について分離処理を行った場合も、図24(d)の例の擬似木が得られる。図24(d)には、互いに冗長なノードは存在しない。
以上で説明した表示画面の例において、例えばマウスで入力されるポインタ位置の指定やキーボードで入力されるカーソル位置の指定などによって特定のACLが選択された場合に、文書管理サーバ10は、そのACLの内容を表す情報を表示させてもよい。例えば図25のように、選択されたACLのACEを表示させる。
また、いわゆる「ドラッグ・アンド・ドロップ」の処理によって、オブジェクトにACLを設定することを可能としても良い。例えば、図18及び図19等の例の表示画面において、ユーザが、マウスのポインタによってオブジェクトを表すアイコンを指定して、ACLを表すアイコンへ「ドラッグ・アンド・ドロップ」する処理を行なうと、指定されたオブジェクトのオブジェクトIDと、指定されたACLのACL_IDと、を含むACL設定要求を、クライアント20は文書管理サーバ10に対して送信する。この要求を受けた文書管理サーバ10は、指定されたACL_IDとオブジェクトIDとを関連付ける処理を行う。
ACLの半順序関係は、以上で例示したモデル以外に、権限の強弱によって定義してもよい。例えば、Allow-Denyモデルの場合、上述の半順序関係のモデルでは「許可」を追加しても「禁止」を追加しても同じ方向に変化するが、「許可」を追加すると権限が強くなり、「禁止」を追加すると権限が弱くなるように、権限の強弱の変化の方向に従って半順序関係の方向を定義してもよい。
また、上述の実施形態におけるACL間の構造の表示処理の例では、ACLグラフに対応する擬似木を生成して表示させるが、他の例では、擬似木の生成を行わずに、ACLグラフ自体を表現する表示情報を生成してクライアント20の表示画面に表示させてもよい。例えば、図23(a)及び図24(a)に例示するようなACLグラフの画像を表示画面に表示させてよい。
以上で説明した実施形態では、ACLグラフ管理部140は、同一内容のACLが重複して存在しないようにACL情報DB60内の複数のACLを管理する。しかしながら、前述の数学的なACLのモデルで説明したように、半順序関係はACLの商集合上で定義されるため、同一の内容のACLが複数存在していてもよい。
また、以上で説明した実施形態では、ACLの同値関係〜による商集合£/〜上に定義されるACL間の半順序関係≦に従った処理を行うが、ACL間の半順序関係は、ACLの商集合上で定義する代わりに、ACL集合£上で定義してもよい。同一内容のACLが重複して存在しないようにACL情報DB60内の複数のACLを管理する場合、ACL集合£上で定義した半順序関係に従った処理は、商集合£/〜上で定義した半順序関係に従った処理と同様となる。以下、ACL集合£上でACL間の半順序関係を定義する場合の数学的モデルの一例を示す。
<ACL集合£上の半順序関係≦>
例えば、アクセス権(fA,U,P,A,fL,£)のACL集合£上に、次の条件を満たす二項関係≦を定義する。
L1,L2∈£について、任意の(u,p)∈FL(L1)に対して、あるp⊆p´⊆Pが存在して、(u,p´)∈FL(L2)かつ、L1〜L2ならばL1=L2であるとき、L1≦L2
定義より≦は半順序関係である。この定義においては、ACLがもつACEの値のセットが同じ(FL(L1)=FL(L2))であっても、ACLが異なれば(L1≠L2)、L1とL2との間に関係≦はないとすることで、関係≦の反対称律を保証し、関係≦を半順序関係として定義している。
なお、以上の各種実施形態の例では、ACL間の関係を半順序関係として定義する。他の実施形態の例では、ACL間の関係は、少なくとも推移律を満たす関係であれば、半順序関係でなくてもよい。ACL間の関係として推移律を満たす関係を定義することで、その関係を用いてACLの有向グラフが定義される。
以上に例示した文書管理サーバ10は、典型的には、汎用のコンピュータにて上述の文書管理サーバ10の各部の機能又は処理内容を記述したプログラムを実行することにより実現される。コンピュータは、例えば、ハードウエアとして、図26に示すように、CPU(中央演算装置)80、メモリ(一次記憶)82、各種I/O(入出力)インタフェース84等がバス86を介して接続された回路構成を有する。また、そのバス86に対し、例えばI/Oインタフェース84経由で、ハードディスクドライブ(HDD)88やCDやDVD、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体を読み取るためのディスクドライブ90が接続される。このようなドライブ88又は90は、メモリに対する外部記憶装置として機能する。実施形態の処理内容が記述されたプログラムがCDやDVD等の記録媒体を経由して、又はネットワーク経由で、ハードディスクドライブ88などの固定記憶装置に保存され、コンピュータにインストールされる。固定記憶装置に記憶されたプログラムがメモリに読み出されCPUにより実行されることにより、実施形態の処理が実現される。
10 文書管理サーバ、20 クライアント、30 ネットワーク、40 文書DB、50 オブジェクト情報DB、60 ACL情報DB、70 ユーザ情報DB、84 I/Oインタフェース、86 バス、88 HDD、90 ディスクドライブ、100 処理要求受付部、110 制御部、120 処理結果出力部、130 オブジェクト情報管理部、140 ACLグラフ管理部、150 ACLツリー表示部、160 検索処理部、170 アクセス制御部。