JP2003280990A - 文書処理装置及び文書を管理するためのコンピュータプログラム - Google Patents

Abstract

(57)【要約】 【課題】 従来共有文書に対するアクセス権をユーザID
やグループIDのみによって管理していたために必要にな
っていた組織（グループ）変更時のメンテナンス作業の
軽減を図る。 【解決手段】 電子データ管理サーバ１はユーザ属性情
報（組織のポスト情報、職務権限の範囲等）とアクセス
種類（例えば、参照／改版／更新／削除）とを文書毎に
関連付けたアクセスコントロールリスト（ACL）を保有
し、クライアント５A，５Bからのアクセス要求に対して
ACLにより文書に対するアクセスの制御をして、アクセ
ス権の管理を行う。このように、ACLをユーザ属性情報
により参照するようにしたので、ユーザ属性を直接アク
セス権に結びつけることが可能になり、従来組織変更の
際に必要になったグループ構成の見直しの負担を軽減す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、文書DBの利用シス
テムやファイルサーバなど共有電子データをアクセス権
に基づいて複数のユーザが利用する電子データサーバ機
能を備えた文書処理装置（システム）に関するものであ
り、特にアクセスコントロールリスト（ACL）をユーザ
属性情報（例えば、組織のポスト情報、職務権限の範囲
等）に関する一次情報により直接参照して、対象文書
（電子データ）に対して設定されたアクセスを許可する
アクセス権管理を可能にした前記文書処理装置（システ
ム）に関する。

【０００２】

【従来の技術】従来より、蓄積した文書（電子データ）
を複数のユーザが利用できるようにした文書管理装置
（システム）やファイルサーバなどにおいて、共有する
蓄積文書を利用する複数のユーザにとって不都合が生じ
ないように、蓄積文書へのアクセス権をユーザにより制
限してデータの適正な維持・管理を行うようにしてい
る。例えば、特開平9-218827号公報には、認証システム
名、ユーザ名およびアクセス権を設定したアクセス権リ
ストを各電子文書（データ）に付与し、電子文書を開く
際に、認証システムにおいてそのユーザの認証をおこな
い、認証されたユーザのアクセス権をアクセス権リスト
を用いて認識するように構成した電子文書管理装置が提
案されている。なお、この例は、複数のユーザ管理環境
下に適応するシステムを構成するために、ユーザ指定の
（前記アクセス権リストに載せた）認証システムによ
り、ユーザの認証を行うことにより、管理環境によって
異なる認証システムが採用された場合への対応を図るよ
うにしている。操作対象物である電子文書へのアクセス
権の設定は、一般に、例示した特開平9-218827号公報に
おけるように、直接ユーザの名前もしくはIDにより行う
場合、或いはユーザと同様にディレクトリサービス上で
管理されているグループの名前もしくはIDにより行う場
合が知られている。なお、上記したディレクトリサービ
スは、登録された認証可能なユーザの一覧やユーザ検索
のサービスを提供するものである。因みに、マイクロソ
フト Windows（登録商標）の場合にはActive Directory
と呼ぶサービスによりその機能を提供しており、また、
一般にLDAP(LightWait Directory Access Protocol)と
呼ぶプロトコルを実装するサーバであれば、認証サービ
スとディレクトリサービスの双方を提供する。

【０００３】ところで、グループIDでアクセス権を設定
する方式による場合に、グループは複数のユーザ又は他
のグループを包含することが可能になっており、グルー
プに対してアクセス権が設定されていれば、そのグルー
プに所属するユーザはそのアクセス権を持っていると解
釈されて、蓄積電子文書へのアクセスを可能にする。電
子文書毎にユーザのアクセス権リストを付与するという
方法によりアクセス権を設定するとき、グループ対応方
式による場合は、ユーザのみの場合に比べて、複数の
ユーザをグルーピングすることによりアクセス権の設定
数を減らす、グループを所属組織や組織上のポスト
（役職等）に対応付けて運用することにより、流動的で
あることが多い組織の構成メンバーと実際に設定するア
クセス権を分離することができる、などの利点がある。
の利点に着目した場合、組織の構成が変更されてアク
セス権を持つユーザが変わった場合は、グループの構成
メンバーを実際の組織変更に合わせて修正することによ
り対応することが可能であり、個々の蓄積文書に設定さ
れているアクセス権を一つ一つ変更する必要は無い。

【０００４】

【発明が解決しようとする課題】しかしながら、グルー
プ対応方式による場合、組織構成に関する一次情報はデ
ィレクトリサービス上に設定されているユーザの所属情
報や属性情報であり、グループの構成メンバーに関して
は別途それぞれユーザが設定登録を行う必要があり、組
織変更があると、それに合わせて修正を行う。修正して
グループの構成メンバーとして登録しておかないと、ア
クセス権が得られない。従って、上記の利点を目的と
してグループ対応方式を採用する場合、組織変更の際に
必要になるグループ構成の見直しが大きな負担となって
いることが実状である。グループの構成はそれぞれの利
用者が比較的自由に作成することも多く自由度も高いた
め自動的に変更を反映する操作も一般的には困難であ
る。本発明は、蓄積した文書（電子データ）に対して複
数のユーザによるアクセスを可能にした電子データサー
バなどの文書処理システムにおける上記した従来技術の
問題点に鑑みてなされたもので、その目的は、従来、蓄
積した共有文書に対するアクセス権をユーザIDやグルー
プIDのみによって管理していたために必要になっていた
組織（グループ）変更時のメンテナンス作業の軽減化を
図ることが可能なアクセス権管理を行うようにした電子
データサーバ機能を持つ文書処理装置（システム）及び
該文書処理装置を構成するためのコンピュータプログラ
ムを提供することにある。

【０００５】

【課題を解決するための手段】請求項１の発明は、フォ
ルダ下に文書を置き、該文書及びフォルダに対して設定
されたアクセス権に従い文書を管理する文書管理部を有
する文書処理装置であって、前記文書管理部は、ユーザ
属性情報と関連付けて文書及びフォルダに対して設定さ
れたアクセス権を示したアクセス権設定情報を予め保有
し、ユーザのアクセス要求に示された指示内容を該アク
セス権設定情報によりチェックし、整合する設定条件に
従いアクセス権を許可するようにしたことを特徴とする
文書処理装置である。

【０００６】請求項２の発明は、請求項１に記載された
文書処理装置において、前記文書管理部は、ユーザ属性
情報が階層構造を持つ組織のポスト情報である場合に、
アクセス権を許可するときに、アクセス要求をしたユー
ザの属性としてのポストに対して上位に位置するポスト
との関連で設定されているアクセス権も許可するように
したことを特徴とするものである。

【０００７】請求項３の発明は、請求項１又は２に記載
された文書処理装置において、アクセス権設定情報にお
けるユーザの属性情報が、複数の属性情報の組み合わせ
からなることを特徴とするものである。

【０００８】請求項４の発明は、請求項１乃至３のいず
れかに記載された文書処理装置において、前記アクセス
権設定情報がユーザ情報とユーザの属性情報の組み合わ
せと文書及びフォルダに対して設定されたアクセス権と
の関連を示すものであることを特徴とするものである。

【０００９】請求項５の発明は、フォルダ下に文書を置
き、該文書及びフォルダに対して設定されたアクセス権
に従い文書を管理するためのコンピュータプログラムで
あって、管理下の文書及びフォルダに対するユーザのア
クセス要求に基づいてユーザの属性情報及びアクセス種
別情報を取得するステップと、取得したユーザの属性情
報及びアクセス権種別を、予め用意したユーザ属性情報
と関連付けて文書及びフォルダに対して設定されたアク
セス権を示したアクセス権設定情報によりチェックする
ステップと、チェック結果により整合するアクセス権を
許可するステップの各処理ステップを実行するためのコ
ンピュータプログラムである。

【００１０】

【発明の実施の形態】本発明の文書処理装置を添付する
図面とともに示す以下の実施形態に基づき説明する。図
１は、本発明の実施形態に係わる文書処理装置（システ
ム）の構成の概要を示すものである。図１に示すよう
に、本例の文書処理システムは、ストレージ１１を有し
た電子データ管理サーバ１と、認証サーバ２と、ユーザ
情報DB（データベース）３１を有したディレクトリサー
バ３と、複数のクライアントコンピュータ５A，５Bを構
成要素として、これらをネットワークを介して接続する
ことによりシステムを構成する。電子データ管理サーバ
１は、複数のユーザが共有する電子データ（例えば文
書）をストレージ１１に保持し、複数のクライアントコ
ンピュータ５A，５Bからのアクセス要求に応じ電子デー
タを操作し、クライアントに対する電子データのサーバ
として機能する。電子データ管理サーバ１は、共有する
電子データに対するアクセスの度にそれが適切なユーザ
による操作であるかどうかをチェックする。このため
に、認証サーバ２及びディレクトリサーバ３を利用す
る。認証サーバ２、或いは構成によってはディレクトリ
サーバ３は、クライアントコンピュータ５A，５Bからの
アクセス要求に示されたユーザの認証を行い、認証が成
功した場合に、ユーザ情報DB３１に保存されている認証
情報を電子データ管理サーバ１に伝える。なお、認証に
失敗した場合には、いかなる操作も許可されない。又、
認証サーバ２とディレクトリサーバ３はユーザの管理情
報に関して同期が取れており、両者が統合されて一つの
サーバとして構成されている場合もある。電子データ管
理サーバ１におけるチェックは、認証サーバから取得し
た認証情報と操作対象の電子データに設定されているAC
L（アクセスコントロールリスト）を照合することによ
り、ACLに設定された可能な操作（アクセス）種を得
る。また、この照合の結果、得られた操作種とクライア
ントの要求する操作種との整合をチェックし、整合（一
致）する操作種によるアクセスコントロールを許可し、
ストレージ１１の対象電子データへの操作を可能にす
る。なお、図１には、ネットワーク上に構築された実施
形態の文書処理システムを示したが、必要な機能を実現
するためのコンピュータプログラムをワークステーショ
ンに搭載することにより、スタンドアロンの文書処理装
置として実施することも可能である。

【００１１】ACL（アクセスコントロールリスト）につ
いて説明する。ACLは、操作対象物、たとえばファイル
やデータフォルダ毎に、誰がどんな操作を行うことを許
可するかを定義するリストである。従来技術では、ユー
ザ又はグループによりアクセス権の範囲を決める方式で
あった。図２は、従来のACLを例示するものであり、同
図では、３つのエントリーが登録されている。各エント
リーには、ユーザIDもしくはグループID、エントリ
ーがユーザを表すのかグループを表すものかを識別する
情報、そのユーザ又はグループが可能な操作の種類、
即ち、参照／改版／更新／削除からなる操作種の許可の
有無を表す情報が指示される。次に、認証情報について
説明する。認証情報は、アクセス要求を行ったユーザの
認証を行うために用意されている情報であり、ディレク
トリサーバ３の管理下のユーザ情報DB３１に保存されて
いる。認証情報の一つは、グループ定義であり、その例
を図３に示す。この例では「企画２グループ」という名
前のグループを定義しており、そのグループIDとメンバ
ーの構成を記述している。もう一つの認証情報は、ユー
ザ定義であり、その例を図４に示す。この例では「tana
ka」という名前のユーザを定義しており、そのIDと電話
番号やメールアドレス、職務上の権限（図４中、「Post
Code:6」として職務権限の範囲をデータ化した例を示
す）などのユーザ属性を記述している。なお、認証情報
（図３，図４）については、本実施形態において用いる
ものも、基本的に従来例におけるものと変わりがない。

【００１２】本実施形態では、ACLに直接ユーザ属性に
より、対象電子データに対する可能な操作の種類（アク
セス権種別）を定義し、従来のユーザIDもしくはグルー
プIDのみによる場合に必要であったグループ変更時のメ
ンテナンス作業の軽減を図るものである。本例のユーザ
属性に基づくACLの例を図５に示す。従来例（図２）と
の違いは、ユーザ又はグループのIDを使って利用者を特
定する変わりにユーザ属性の取る範囲、即ち、ここで
は、職務上の権限の範囲によりPost Code＜4とPost Cod
e＜6の各エントリを指定することにより利用者を特定す
るようにした点である。

【００１３】図６は、階層構造をもつユーザ属性の例で
ある。ディレクトリサービスの管理対象であるユーザ、
グループやその他のリソースは、図６のような階層構造
の基に定義されることがある。ディレクトリの階層構造
は、一般的には組織の構成を表すのに用いることが多
い。図６では、'tanaka'というユーザは階層上'o=ab
c' 'ou=ppu, o=abc' 'ou=p2g, ou=ppu, o=abc'とい
うポスト（ノード）に所属している。本発明の実施形態
に係わる他のACLの例は、上記図６に例示したような階
層構造をもつユーザ属性に対するものである。図７は、
そのACLを例示する。ここでは、その指定されている条
件を、階層構造上のポスト（ノード）がdn='ou=p2g,ou=
ppu, o=abc'とdn='ou=ppu, o=abc'として、各エントリ
を指定することにより利用者を特定するようにしてい
る。図８は、図７に示されているアクセス権の及ぶ範囲
を図示したものである。指定されたポストに設定された
アクセス権はそのポストの下位の階層に属するユーザ全
体に影響が及ぶ。つまり、dn='ou=p2g, ou=ppu, o=abc'
のエントリーに設定されたアクセス権（参照／改版）
は、図８に示した範囲Z3に及び、dn='ou=ppu,o=abc'の
エントリーに設定されたアクセス権（参照）は、図８に
示した範囲Z2に及び、id=264のエントリーに設定された
アクセス権（参照／改版／更新／削除）は、図８に示し
た範囲Z1に及ぶ。

【００１４】本発明の実施形態に係わる他のACLの例
は、複数のユーザ属性の組み合わせに対するものであ
る。図９は、そのACLを例示する。属性条件の項に複数
のユーザ属性条件を併記して２項演算子'and'で結ぶこ
とにより複数のユーザ属性条件を同時に満たすユーザの
みが設定したアクセス権を持つようにすることを示して
いる。ここでは、、図９の1レコード目に示すように、
その指定されている条件を、階層構造上のノードと職務
上の権限の範囲の組み合わせ、即ち、「dn='ou=p2g, ou
=ppu, o=abc'」and「Post Code＜6」として、エントリ
を指定することにより利用者を特定するようにしてい
る。また、本発明の実施形態に係わる他のACLの例は、
複数のアクセス権設定方式を組み合わせたものである。
図１０は、そのACLを例示する。属性条件の項にユーザ
属性条件とユーザもしくはグループIDを併記して２項演
算子'and'で結ぶことにより複数の複数のアクセス権設
定方式による条件を同時に満たすユーザのみが設定した
アクセス権を持つようにすることを示している。ここで
は、図１０の1レコード目に示すように、その指定され
ている条件を、「ObjectClass='Person'」and「id=26
4」として、エントリを指定することにより利用者を特
定するようにしている。

【００１５】次に、上記した文書処理システムにおける
共有データ管理サーバによるアクセス権制御処理に係わ
る実施形態を以下に説明する。以下に示す「実施形態
１」、「実施形態２」、「実施形態３」、「実施形態
４」は、それぞれ上記の図５、図７、図９、図１０のア
クセスコントロールリスト（ACL）によるアクセス権制
御を行うことにより、ユーザ属性により直接、対象電子
データに対する可能な操作を行うようにし、従来のユー
ザIDもしくはグループIDのみによりアクセス権制御を行
っていた場合に必要であった組織やグループの構成変更
時のメンテナンス作業の軽減化を図ることを可能とする
ものである。「実施形態１」図１１は、実施形態１（図
５に例示したACLによる）のアクセス権制御処理フロー
である。なお、図１１中の（Ａ）で囲った部分は、ACL
の1レコード分の処理に相当する。図１１を参照して、
クライアントコンピュータ５A（５B）からストレージ１
１に蓄積された対象電子データへのアクセス要求がある
度に、電子データ管理サーバ１が行う本例のアクセス権
制御処理のフローを説明する。先ず、適切なユーザによ
るアクセス要求であるか否かを、認証サーバ２により認
証する。そのための手順として、認証手続きが済んでい
るか否かをチェックし（Ｓ１１）、済んでいない場合、
認証サーバ２に接続して認証手続きを行う（Ｓ１２）。
認証手続きは、アクセス要求に記されたユーザ情報（或
いはユーザ属性情報）がディレクトリサーバ３のユーザ
情報DB３１に登録されているか否かを確認することによ
る。ユーザ情報（或いはユーザ属性情報）が確認でき
ず、認証に失敗した場合（Ｓ１３-NO）、アクセス要求
を拒否し、いかなる操作も許可しない。他方、認証に成
功した場合（Ｓ１３-YES）、次の手順として、認証サー
バ２（構成によってはディレクトリサーバ３の場合もあ
る）よりそこに保有されていたユーザ属性情報を取得し
て認証情報（図４）として保持する（Ｓ１４）。

【００１６】次に、認証サーバ２から取得した認証情報
と操作対象物のACLを照合することによりアクセス要求
の操作が可否をチェックする。具体的には、操作対象物
毎に設定されるACL（図５）の各レコードと認証情報を
比較するので、ACLの1レコードを取り出し（Ｓ１５）、
さらにそのレコードの属性条件（本例では、属性条件と
して認証情報に含まれるユーザ属性値、即ちPost Code
＜4、といった職務権限に対する許可範囲を設定してい
る）及びステップＳ１３で認証した認証情報に記されて
いるユーザ属性情報を取り出す（Ｓ１６）。両者を比較
し、ACLの属性条件が認証情報に存在しない場合（Ｓ１
７-NO）、又属性が存在しても属性値がACLの属性条件の
範囲内（Post Code＜4）ではない場合（Ｓ１８-NO）、
照合は不成立であるから、全レコードのチェック完了を
確認して（Ｓ２０）、未完了であれば、次の１レコード
の照合を行うために、ステップＳ１５からの手順に戻
す。他方、ACLの属性条件が認証情報に存在し（Ｓ１７-
YES）、又その属性値がACLの属性条件の範囲内である場
合（Ｓ１８-YES）、照合は成立するから、ACLレコード
上のアクセス許可情報を取り出し、参照以外に改版／更
新／削除が許可されているときには、それらを可能なア
クセス操作種に加える（Ｓ１９）。なお、ACLの各レコ
ードは独立している。例のようにアクセス許可の種類が
複数ある場合、ACL上の複数レコードの条件を満たすユ
ーザ属性は、その両方のアクセス許可を得ることができ
る。全レコードの完了を確認した後（Ｓ２０-YES）、ユ
ーザのアクセス要求内容に指示されているアクセス操作
種（アクセス権）が許可できるか否かを、上記したACL
により確認したユーザ属性に関連付けて許可されるアク
セス操作種によりチェックを掛ける（Ｓ２１）。このチ
ェックの結果、ユーザのアクセス要求内容がACLに設定
された許可条件と整合しない場合（Ｓ２１-NO）、アク
セス要求を拒否する。他方、ユーザのアクセス要求内容
がACLに設定された許可条件と整合する場合（Ｓ２１-YE
S）、要求に従うアクセス操作種を実行可能とする（Ｓ
２２）。このように、アクセス許可とユーザが指示した
操作を比較して可能な操作だけを実行し、許可されない
操作を実行しないことによりアクセス権管理機能を実現
する。

【００１７】「実施形態２」図１２は、実施形態２（図
７に例示したACLによる）のアクセス権制御処理フロー
に係わる。なお、本実施形態は、図１１中の（Ａ）で囲
った、ACLの1レコード分の処理に相当する部分を図１２
に示すフローに置き換えて実施するものであり、ACLの1
レコード分の処理以外は図１１と同じ処理フローを実行
する。図１２を参照して、本例のアクセス権制御処理の
フローを説明する。図１２のフローに入る前段のステッ
プで、適切なユーザによるアクセス要求であるか否か
を、アクセス要求に記されたユーザ情報（或いはユーザ
属性情報）により認証する。認証された場合、認証サー
バ２からそこに保有されていた“階層構造をもつユーザ
属性”を含むユーザ属性情報を取得して認証情報として
保持する（図１１参照）。この後、操作対象物毎に設定
されるACL（図７）の各レコードと認証情報を比較する
図１２の処理ステップに入る。先ず、ACLの1レコードを
取り出し、さらにそのレコードの属性条件（本例では、
属性条件として認証情報に含まれる階層構造をもつユー
ザ属性、即ちdn='ou=p2g, ou=ppu, o=abc'、といった条
件に対する許可範囲を設定している）及び認証した認証
情報に記されているユーザ属性情報を取り出す（Ｓ３
１）。両者を比較し、ACLの属性条件が認証情報に存在
しない場合（Ｓ３２-NO）、又存在しても属性が階層構
造を持つ属性ではなく（Ｓ３３-NO）、このACLに設定さ
れた属性条件の範囲内ではない場合（Ｓ３８-NO）、照
合は不成立であるから、当該レコードのチェックを終了
する。

【００１８】他方、ACLの属性条件が認証情報に存在し
（Ｓ３２-YES）、又その属性が階層構造を持つ属性であ
る場合（Ｓ３３-YES）、認証情報からユーザ属性情報と
して得られる階層構造をもつ属性値を加工してユーザが
属する階層上のノードのリストを得る（Ｓ３４）。例え
ば、図６のような階層構造をもつユーザ管理が行われて
いた場合、'cn=tanaka, ou=p2g, ou=ppu, o=abc'という
ユーザは、その属性値を分析することにより、'o=ab
c' 'ou=ppu, o=abc' 'ou=p2g, ou=ppu, o=abc'とい
うポスト（ノード）に所属していることが分かる。次
に、ACLのレコードの属性条件と認証情報を加工して得
たポスト（ノード）名を比較する（Ｓ３５）。ここで照
合が、不成立の場合には（Ｓ３６-NO）、当該レコード
のチェックを終了する。照合が成立する場合には（Ｓ３
６-YES）、ACLレコード上のアクセス許可情報を取り出
し、参照以外に改版／更新／削除が許可されているとき
には、それらを可能なアクセス操作種に加える（Ｓ３
７）。具体的には、ACLのレコード（図７）と上記〜
を比較する。ACLの第2レコードの'ou=p2g, ou=ppu, o
=abc'はと一致し、第3レコードの'ou=ppu, o=abc'は
と一致することから、このユーザは「参照／改版」に
関するアクセス権をもっていると判断される。図８に示
すように、各ノードに対するアクセス権を設定すると下
位に属する全てのユーザに対してその設定が有効にな
る。なお、ACLの属性条件が認証情報に存在し（Ｓ３２-
YES）、その属性が階層構造を持つ属性ではない場合で
も（Ｓ３３-NO）、例えばid=264（図７）のように、条
件に適合する場合には（Ｓ３８-YES）、ACLに従ったア
クセス権を設定する（Ｓ３７）。

【００１９】「実施形態３」図１３は、実施形態３（図
９に例示したACLによる）のアクセス権制御処理フロー
に係わる。なお、本実施形態は、図１１中の（Ａ）で囲
った、ACLの1レコード分の処理に相当する部分を図１３
に示すフローに置き換えて実施するものであり、ACLの1
レコード分の処理以外は図１１と同じ処理フローを実行
する。また、図１３の（Ｂ）で囲んだ部分はACLの属性
の組み合わせ条件を分割して1条件分の処理に相当する
部分を示す。図１３を参照して、本例のアクセス権制御
処理のフローを説明する。図１３のフローに入る前段の
ステップで、適切なユーザによるアクセス要求であるか
否かを、アクセス要求に記されたユーザ情報（或いはユ
ーザ属性情報）により認証する。認証された場合、認証
サーバ２からそこに保有されていた、複数種の組み合わ
せからなるユーザ属性情報を取得して認証情報として保
持する（図１１参照）。この後、操作対象物毎に設定さ
れるACL（図９）の各レコードと認証情報を比較する図
１３の処理ステップに入るが、先ず、ACLの1レコードを
取り出し、そこに記述されている属性条件データを構文
解析して1つの条件を取り出す（Ｓ４１）。なお、ACLに
属性条件として記述される一般的な複合条件を解釈して
適合チェックをするためには条件文の構文解析が必要と
なるが、ここでは、図９に示すように比較的単純な‘A=
a and B=b’の条件から‘A=a’と‘B=b’を分離して、
それぞれの条件を判定した上で最後に両者を統合する方
式例を示した。一般的な属性条件としては、演算子とし
て論理積（AND）、論理和（OR）、否定（NOT）や、等号
（＝）、不等号（＜，＞）およびその組み合わせなどを
用いた複雑な条件も定義することができる。そうした場
合には、ここで例示したよりも少し複雑な構文解析を行
う必要がある。

【００２０】ACLの1レコードに記述された属性条件を構
文解析して得られる1つの条件についてのチェック処理
（図１３中（Ｂ）部分）の始めに、レコードの解析され
た1条件（本例では、属性条件として認証情報に含まれ
る階層構造をもつユーザ属性、即ちdn='ou=p2g, ou=pp
u, o=abc'、といった条件と、職務権限のランク、即ちP
ost Code＜6、といった条件の組み合わせに対する許可
範囲を設定しているので、この中から分けた1条件）及
び認証した認証情報に記されているユーザ属性情報を取
り出す（Ｓ４２）。両者を比較し、ACLの属性条件が認
証情報に存在しない場合（Ｓ４３-NO）、照合処理を行
わずに、照合は不成立として、ステップＳ４８にスキッ
プする。ACLの属性条件が認証情報に存在する場合（Ｓ
４３-YES）、属性が階層構造を持つ属性か否かにより処
理を分岐するので、その確認をする（Ｓ４４）。その属
性が階層構造を持つ属性である場合（Ｓ４４-YES）、認
証情報からユーザ属性情報として得られる階層構造をも
つ属性値を加工してユーザが属する階層上のノードのリ
ストを得る（Ｓ４５）。この処理は図１２のステップ３
４の処理と同様であり、先の説明を参照する。次に、AC
Lのレコードの属性条件と認証情報を加工して得たポス
ト（ノード）名を比較し、照合の成立／不成立を判定し
（Ｓ４６）、次のステップＳ４８に移行する。他方、属
性が階層構造を持たない場合の条件（本例では、職務権
限のランク）についてその照合を行い、照合の成立／不
成立を判定し（Ｓ４７）、次のステップＳ４８に移行す
る。次に、上記で行った照合結果を受け、かつACLの属
性の組み合わせ条件を示す演算子を考慮して、条件を満
足するかを判定する（Ｓ４８）。判定結果として、条件
を棄却する場合（Ｓ４９-YES）、当該レコードのチェッ
クを終了する。ステップＳ４８の判定結果として、条件
を棄却しない場合（Ｓ４９-NO）、ACLの属性の組み合わ
せの全条件のチェックを済ませたかを確認して（Ｓ５
０）、全条件をチェックしていない場合には（Ｓ５０-N
O）、次の条件をチェックするためにステップＳ４１に
戻す。なお、ステップＳ４９の処理は、条件不成立を確
認した場合のみチェックを終了させ、それ以外の不定の
状態では棄却をしない。条件を棄却せずに、全条件のチ
ェックが済んだ場合には（Ｓ５０-YES）、ACLの属性の
組み合わせ条件を満たすことになるので、ACLレコード
上のアクセス許可情報を取り出し、参照以外に改版／更
新／削除が許可されているときには、それらを可能なア
クセス操作種に加え（Ｓ５１）、当該1レコード分のチ
ェックを終了する。

【００２１】「実施形態４」図１４は、実施形態４（図
１０に例示したACLによる）のアクセス権制御処理フロ
ーに係わる。なお、本実施形態は、図１１中の（Ａ）で
囲った、ACLの1レコード分の処理に相当する部分を図１
４に示すフローに置き換えて実施するものであり、ACL
の1レコード分の処理以外は図１１と同じ処理フローを
実行する。また、図１４中のステップＳ６４は、図１３
の（Ｂ）で囲んだ部分、即ちACLの属性の組み合わせ条
件を分割して1条件分の処理に相当する部分を示す。図
１４を参照して、本例のアクセス権制御処理のフローを
説明する。図１４のフローに入る前段のステップで、適
切なユーザによるアクセス要求であるか否かを、アクセ
ス要求に記されたユーザ情報（或いはユーザ属性情報）
により認証する。認証された場合、本例は、複数のアク
セス権設定方式による条件を同時に満たすユーザのみが
設定したアクセス権を持つようにすることを意図したも
のであるから、この条件チェックに関わるユーザ情報お
よびユーザの属性情報を認証サーバ２から取得して認証
情報として保持する（図１１参照）。この後、操作対象
物毎に設定されるACL（図１０）の各レコードと認証情
報を比較する図１４の処理ステップ（Ｓ６２〜６４）に
入るが、先ず、ACLの1レコードを取り出し、そこに記述
されている属性条件データを構文解析して1つの条件を
取り出す（Ｓ６１）。なお、ACLに属性条件として記述
される一般的な複合条件を解釈して適合チェックをする
ためには条件文の構文解析が必要となるが、ここでは、
図９に示すように比較的単純な‘A=a and B=b’の条件
から‘A=a’と‘B=b’を分離して、それぞれの条件を判
定した上で最後に両者を統合する方式例を示した。一般
的な属性条件としては、演算子として論理積（AND）、
論理和（OR）、否定（NOT）や、等号（＝）、不等号
（＜，＞）およびその組み合わせなどを用いた複雑な条
件も定義することができる。そうした場合には、ここで
例示したよりも少し複雑な構文解析を行う必要がある。

【００２２】本例では、「実施形態３」で組み合わされ
た属性条件にさらにグループを特定する条件が追加され
ているので、ACLの1レコードに記述された属性条件を構
文解析して得られる3種類の条件に対するチェック処理
を要する。そこで、この3種類の条件に対するチェック処
理を分岐するために、最初に、ステップ６１で取り出し
た1条件がグループを特定できる条件であるかを確認
し、グループである場合に（Ｓ６２-YES）、ディレクト
リサーバ３を検索し、認証情報に含まれるユーザIDが、
該当グループの構成メンバーに含まれるか否かを判定す
る（Ｓ６３）。他方、ステップ６１で取り出した1条件
がグループを特定できる条件ではない場合（Ｓ６２-N
O）、「実施形態３」で説明した図１３の（Ｂ）部分の
処理、即ちACLのユーザ属性の組み合わせ条件の分割処
理を行う（Ｓ６４）。このようにして、3種類の条件に
対するチェック処理を分岐して行い、それぞれ得られる
判定結果（Ｓ６３，Ｓ４６，Ｓ４７）、即ち属性条件の
照合の成立／不成立の結果を受け、かつACLの属性の組
み合わせ条件を示す演算子を考慮して、複数のアクセス
権設定方式による条件を満足するかを判定する（Ｓ６
５）。判定結果として、条件を棄却する場合（Ｓ６６-Y
ES）、当該レコードのチェックを終了する。ステップＳ
６５の判定結果として、条件を棄却しない場合（Ｓ６６
-NO）、ACLの属性の組み合わせの全条件のチェックを済
ませたかを確認して（Ｓ６７）、全条件をチェックして
いない場合には（Ｓ６７-NO）、次の条件をチェックす
るためにステップＳ６１に戻す。なお、ステップＳ６５
の処理は、条件不成立を確認した場合のみ当該レコード
のチェックを終了させ、それ以外の不定の状態では棄却
をしない。条件を棄却せずに、全条件のチェックが済ん
だ場合には（Ｓ６７-YES）、ACLの属性の組み合わせ条
件を満たすことになるので、ACLレコード上のアクセス
許可情報を取り出し、参照以外に改版／更新／削除が許
可されているときには、それらを可能なアクセス操作種
に加え（Ｓ６８）、当該1レコード分のチェックを終了
する。

【００２３】上記「実施形態１」〜「実施形態４」にそ
れぞれ示したアクセス権制御処理は、例示したフローに
示した各処理ステップを実行するためのコンピュータプ
ログラムを作成し、それを、文書管理サーバ（図１のシ
ステム例では電子データ管理サーバ１）を構成するコン
ピュータにおける動作制御プログラムとして用いること
により、実施し得る。文書管理サーバ（電子データ管理
サーバ１）を構成するコンピュータは、サーバ機能に必
要な処理手順を実行するためのプログラム（ソフトウェ
ア）を内蔵CPU（図示せず）の制御下の記憶手段（図示
せず）の記憶媒体に保持させ、プログラムに従う処理を
実行するが、そのプログラムの一部として、上記「実施
形態１」〜「実施形態４」にそれぞれ例示したアクセス
権制御処理を実行するために作成したプログラムを用
い、所期のアクセス権制御を実現する。

【００２４】

【発明の効果】（１） 請求項１の発明に対応する効果 文書管理部（電子データ管理サーバ）はユーザ属性情報
（組織のポスト情報、職務権限の範囲等）とアクセス権
の種類とを文書毎に関連付けたアクセスコントロールリ
スト（ACL）を保有し、アクセス要求に対してACLをユー
ザ属性情報により参照するようにしたので、ユーザ属性
を直接アクセス権に結びつけることが可能になり、従
来、ユーザIDやグループIDのみによって管理していたた
めに組織（グループ）変更時にアクセスができなくなっ
てしまっていたケースでも、バックアップが可能にな
り、又その分、不可欠であった組織（グループ）変更時
のメンテナンス作業（グループ構成の見直し等）の負担
を軽減することが可能になる。 （２） 請求項２の発明に対応する効果 上記（１）の効果に加え、階層構造を持つ組織のポスト
情報を対象としたアクセス権設定を行う場合に、上位ポ
ストに設定されているアクセス権も許可するようにした
ので、組織の所属メンバーに対するアクセス権付与がよ
り簡単に実現できる。 （３） 請求項３の発明に対応する効果 上記（１）、（２）の効果に加え、アクセス権設定情報
におけるユーザの属性情報を複数の属性情報の組み合わ
せとしたので、アクセス権設定の自由度を増大させるこ
とができる。即ち、従来行われているグループを利用し
たアクセス権設定は非常に大きな自由度を持っており、
請求項１、請求項２の発明だけで同等の設定を実現する
のは困難であるが、請求項３の発明により、ユーザ属性
の有効利用がやり易くなり、データのセキュリティにあ
わせた柔軟なアクセス権の設定ができるようになる。

【００２５】（４） 請求項４の発明に対応する効果 上記（１）〜（３）の効果に加え、ACLのアクセス権設
定情報をユーザ情報とユーザの属性情報の組み合わせと
したので、さらに柔軟性が高く管理のし易いアクセス権
管理が可能になる。即ち、グループによるアクセス権設
定はディレクトリサーバで管理されているユーザ属性と
無関係な人の集合に対してアクセス権の設定を行う際に
は有効であり、この場合には組織（グループ）変更とは
まったく関係のないアクセス権を設定できるため、両者
を併用することによってさらに柔軟性が高く管理のしや
すいアクセス権管理システムを構築することが可能にな
る。 （５） 請求項５の発明に対応する効果 文書管理部（電子データ管理サーバ）を構成するコンピ
ュータに、請求項５に記載された各処理ステップを実行
するためのプログラムを搭載することにより、上記
（１）の効果を容易に具現化することが可能になる。

【図面の簡単な説明】

【図１】 本発明の実施形態に係わる文書処理装置（シ
ステム）の構成の概要を示す。

【図２】 従来のACL（アクセスコントロールリスト）
の例を示す。

【図３】 ユーザ情報DBに格納された認証情報の例（グ
ループの定義）を示す。

【図４】 ユーザ情報DBに格納された認証情報の例（ユ
ーザの定義）を示す。

【図５】 本発明に係わるACLの例（実施形態１）を示
す。

【図６】 階層構造をもつユーザ属性の例を示す。

【図７】 本発明に係わるACLの例（実施形態２）を示
す。

【図８】 図７のACLによるアクセス権の範囲を説明す
る図である。

【図９】 本発明に係わるACLの例（実施形態３）を示
す。

【図１０】 本発明に係わるACLの例（実施形態４）を
示す。

【図１１】 本発明に係わるアクセス権制御処理（実施
形態１）のフローチャートを示す。

【図１２】 本発明に係わるアクセス権制御処理（実施
形態２）のフローチャートを示す。

【図１３】 本発明に係わるアクセス権制御処理（実施
形態３）のフローチャートを示す。

【図１４】 本発明に係わるアクセス権制御処理（実施
形態４）のフローチャートを示す。

【符号の説明】

１…電子データ管理サーバ ２…認証サーバ、
３…ディレクトリサーバ、 ５A，５B…クライアントコ
ンピュータ、１１…ストレージ、 ３１
…ユーザ情報DB（データベース）。

Claims (5)

【特許請求の範囲】
1. 【請求項１】 フォルダ下に文書を置き、該文書及びフ
   ォルダに対して設定されたアクセス権に従い文書を管理
   する文書管理部を有する文書処理装置であって、前記文
   書管理部は、ユーザ属性情報と関連付けて文書及びフォ
   ルダに対して設定されたアクセス権を示したアクセス権
   設定情報を予め保有し、ユーザのアクセス要求に示され
   た指示内容を該アクセス権設定情報によりチェックし、
   整合する設定条件に従いアクセス権を許可するようにし
   たことを特徴とする文書処理装置。
2. 【請求項２】 請求項１に記載された文書処理装置にお
   いて、前記文書管理部は、ユーザ属性情報が階層構造を
   持つ組織のポスト情報である場合に、アクセス権を許可
   するときに、アクセス要求をしたユーザの属性としての
   ポストに対して上位に位置するポストとの関連で設定さ
   れているアクセス権も許可するようにしたことを特徴と
   する文書処理装置。
3. 【請求項３】 請求項１又は２に記載された文書処理装
   置において、アクセス権設定情報におけるユーザの属性
   情報が、複数の属性情報の組み合わせからなることを特
   徴とする文書処理装置。
4. 【請求項４】 請求項１乃至３のいずれかに記載された
   文書処理装置において、前記アクセス権設定情報がユー
   ザ情報とユーザの属性情報の組み合わせと文書及びフォ
   ルダに対して設定されたアクセス権との関連を示すもの
   であることを特徴とする文書処理装置。
5. 【請求項５】 フォルダ下に文書を置き、該文書及びフ
   ォルダに対して設定されたアクセス権に従い文書を管理
   するためのコンピュータプログラムであって、管理下の
   文書及びフォルダに対するユーザのアクセス要求に基づ
   いてユーザの属性情報及びアクセス種別情報を取得する
   ステップと、取得したユーザの属性情報及びアクセス権
   種別を、予め用意したユーザ属性情報と関連付けて文書
   及びフォルダに対して設定されたアクセス権を示したア
   クセス権設定情報によりチェックするステップと、チェ
   ック結果により整合するアクセス権を許可するステップ
   の各処理ステップを実行するためのコンピュータプログ
   ラム。