JP2016051451A - アクセス制御システム及びプログラム - Google Patents

Abstract

【課題】一次委託先に対してアクセス権を付与した委託元にとって受け入れられない二次委託先に対して一次委託先からアクセス権が委譲されることを防止する。【解決手段】委託元は文書管理システム３００内の文書に対するアクセス権を一次委託先に付与し、二次委託先が満たすべきクライアント証明書及びユーザ属性の条件を証明書条件テーブル１２７及びユーザ属性条件テーブル１２９に設定する。一次委託先は、認証・認可サーバ１００にて認証を受けて一次トークンを取得し、一次トークンを二次委託先に渡す。二次委託先は、中間サーバ２００を経由して認証・認可サーバ１００に一次トークンを提示し、二次トークンを要求する。認証・認可サーバ１００は、二次委託先が証明書条件テーブル１２７及びユーザ属性条件テーブル１２９の条件を満たす場合に、二次トークンを提供する。二次委託先は、その文書を要求する際、二次トークンを提示する。【選択図】図１

Description

本発明は、アクセス制御システム及びプログラムに関する。

製造業において、部品設計を委託元が行い、部品製造を開発元以外の会社に委託する、委託開発が広く行われている。部品製造を委託する場合、委託元が作成した設計図を委託先に渡す必要がある。これを実現するため、電子ファイルとして作成された設計図を文書管理システム上に格納しておき、委託先の担当者が当該文書管理システムにアクセスして設計図を取得する、という方法が採られることが一般的である。このとき、文書管理システム上でアクセス権を適切に設定することにより、開発委託とは無関係な第三者が設計図を取得するのを防止している。

ところで、委託開発においては、委託元が製造委託した委託先（一次委託先）が、さらに別の委託先（二次委託先）に製造委託する場合がある。

このような再委託が行われる場合、二次委託先の担当者は、上述の文書管理システム上の設計図ファイルに対するアクセス権を持たないため、委託元の担当者、すなわち文書管理システム上の設計図の管理者が、二次委託先向けに新たにアクセス権を追加する必要がある。一次委託先が見積もりなどの目的で複数の二次委託先に設計図を渡す必要がでてくる場合もあり、このような場合、委託元は、それら複数の二次委託先のアクセス権を設定しなければならず、作業の手間が非常に大きくなってしまう。

特許文献１には、Ｗｅｂアプリケーションの利用権限を別の利用者に委譲する際の、委譲元の利用者の手間の軽減のためのシステムが開示されている。このシステムでは、利用者の本人性を確認可能な情報を格納する格納媒体に、当該格納媒体を利用する利用者が他の利用者から委譲された権限に関する権限委譲情報を格納する。認証サーバは、アクセス要求を利用者端末から受け付けた際に、当該利用者が利用する格納媒体に格納されている情報に基づいて当該利用者の本人性を認証するとともに、当該格納媒体に格納された権限委譲情報もしくは当該権限委譲情報から導出される情報を、当該アクセス要求にて指定されたアプリケーションサーバに転送し、アプリケーションサーバ各々は、転送された権限委譲情報等を受け付けると、当該権限委譲情報等に基づいて、当該権限委譲情報を格納する格納媒体の利用者の権限を判定する。

特開２００９−２０５３４２号公報

第１ユーザから電子文書へのアクセス権の付与を受けた第２ユーザが、別のユーザにそのアクセス権の一部又は全部を委譲する場合に、第２ユーザが選んだユーザを無条件に委譲先として認めたのでは、第１ユーザに受け入れられないユーザにアクセス権が委譲される可能性がある。

本発明は、第２ユーザに対してアクセス権を付与した第１ユーザにとって受け入れられないユーザに対して第２ユーザからアクセス権が委譲されることを防止することができる仕組みを提供する。

請求項１に係る発明は、認証装置と中間装置とを有し、前記認証装置は、文書管理装置に保持された電子文書について第１ユーザが第２ユーザに付与したアクセス権の委譲先として許可可能なユーザが満たすべき許可条件であって前記第１ユーザが指定した許可条件、を記憶する許可条件記憶手段と、前記第２ユーザに一次トークンを発行する一次トークン発行手段と、第３ユーザから前記一次トークンを含んだ委譲要求を受けた場合に、前記第３ユーザが前記許可条件を満たすならば前記第３ユーザに二次トークンを発行する二次トークン発行手段と、前記文書管理装置から前記二次トークンの検証依頼を受けた場合に、前記二次トークンに対応する前記一次トークンに対応する前記第２ユーザの前記電子文書へのアクセス権の範囲内で定められた前記第３ユーザのアクセス権に基づき、前記第３ユーザの前記電子文書に対するアクセス可否を検証する検証手段と、を有し、前記中間装置は、前記第３ユーザから前記二次トークンと共に前記電子文書に対するアクセス要求を受け取った場合に、前記アクセス要求を前記二次トークンと共に前記文書管理装置に転送する転送手段、を有することを特徴とするアクセス制御システムである。

請求項２に係る発明は、前記中間装置は、前記第３ユーザの端末装置から前記一次トークンを受け取った場合に、セッションＩＤを発行し、前記セッションＩＤと前記一次トークンとの組合せをセッション記憶手段に記憶し、前記セッションＩＤと前記一次トークンとを前記端末装置に記憶させ、前記端末装置に対して前記認証装置の前記二次トークン発行手段から二次トークンの発行を受けるよう指示する指示手段と、前記指示に従って前記二次トークン発行手段から二次トークンの発行を受けた前記端末装置から前記二次トークンを受け取るとともに、前記端末装置からセッションＩＤと一次トークンとを受け取り、受け取ったセッションＩＤと一次トークンが前記セッション記憶手段に記憶された前記組合せに合致する場合に、受け取った前記二次トークンを前記セッション記憶手段内の前記組合せに登録する二次トークン登録手段と、前記端末装置から前記電子文書へのアクセス要求を受け取った場合に、前記端末装置から送信される前記二次トークン及び前記セッションＩＤが前記セッション記憶手段に記憶された前記組合せに合致すれば、前記アクセス要求を前記二次トークンと共に前記文書管理装置に転送する転送手段と、を有する請求項１に記載のアクセス制御システムである。

請求項３に係る発明は、コンピュータを、文書管理装置に保持された電子文書について第１ユーザが第２ユーザに付与したアクセス権の委譲先として許可可能なユーザが満たすべき許可条件であって前記第１ユーザが指定した許可条件、を記憶する許可条件記憶手段と、前記第２ユーザに一次トークンを発行する一次トークン発行手段、第３ユーザから前記一次トークンを伴うアクセス権委譲要求を受けた場合に、前記第３ユーザが前記許可条件を満たすならば前記第３ユーザに二次トークンを発行する二次トークン発行手段、前記第３ユーザから前記二次トークンと共に前記電子文書に対するアクセス要求を受け取った場合に、前記アクセス要求を前記二次トークンと共に前記文書管理装置に転送する転送手段、前記文書管理装置から、前記二次トークンの検証依頼を受けた場合に、前記二次トークンに対応する前記一次トークンに対応する前記第２ユーザの前記電子文書へのアクセス権の範囲内の前記第３ユーザの前記電子文書へのアクセス権に基づき、前記第３ユーザの前記電子文書に対するアクセス可否を検証する検証手段、として機能させるためのプログラムである。

請求項１又は３に係る発明によれば、第２ユーザに対してアクセス権を付与した第１ユーザにとって受け入れられないユーザに対して第２ユーザからアクセス権が委譲されることを防止することができる。

請求項２に係る発明によれば、二次トークンを不正に取得した者がその二次トークンを用いて電子文書にアクセスすることを防止することができる。

実施形態のシステム構成の例を示す図である。 認証・認可サーバが持つ各種テーブルのデータ構造を説明するための図である。 中間サーバが持つ状態セッション照合テーブルのデータ構造を説明するための図である。 図１のステップ(6)の時点での各種テーブルのデータ内容の例を示す図である。 一次トークン登録アドレスの例を示す図である。 図１のステップ(11)の時点での各種テーブルのデータ内容の例を示す図である。 二次トークン要求アドレスの例を示す図である。 図１のステップ(16)の時点での各種テーブルのデータ内容の例を示す図である。 二次トークン登録アドレスの例を示す図である。 図１のステップ(20)の時点での各種テーブルのデータ内容の例を示す図である。 図面アドレスの例を示す図である。 一次委託先担当者と本システムとの間の処理の流れを説明する図である。 二次委託先担当者と本システムとの間の処理の流れの前半部を説明する図である。 二次委託先担当者と本システムとの間の処理の流れの後半部を説明する図である。

＜システム構成＞
図１を参照して、本実施形態のシステムについて説明する。

本実施形態では、委託元（例えば製造開発元）の担当者が文書管理システム３００に登録した電子文書（例えば設計図ファイル）のアクセス権を一次委託先（例えば製造委託先）の担当者に付与し、一次委託先の担当者がそのアクセス権を二次委託先の担当者に委譲する仕組みを説明する。

本実施形態のシステムは、認証・認可サーバ１００及び中間サーバ２００を含み、これら両者の協調動作により、文書管理システム３００に対してアクセス管理のサービスを提供する。

文書管理システム３００は、設計図面データ等の電子文書（例えば文書ファイル）を格納し、それら格納した電子文書をユーザからのリクエストに応じて提供するサーバである。文書管理システム３００は、受け取ったリクエストに含まれるトークンを認証・認可サーバ１００に送って検証を依頼する機能（トークン検証依頼部３１０）を有する。この機能は、ＵＭＡ（Ｕｓｅｒ Ｍａｎａｇｅｄ Ａｃｃｅｓｓ）という、Ｗｅｂベースの標準的なアクセス管理プロトコルに定義された機能である。そして、トークン検証依頼部３１０の依頼に対して認証・認可サーバ１００から返される検証結果に従い、電子文書へのアクセスを許可又は拒否する。文書管理システム３００は、標準的なプロトコルであるＵＭＡ（あるいはこれと同様の、トークンの検証を依頼する機能を定義したプロトコル）をサポートしていれば、本実施形態のシステム（認証・認可サーバ１００及び中間サーバ２００）からサービスを受けることができる。

認証・認可サーバ１００は、ユーザの認証と、トークンの発行及び管理を行う。トークンとは、認証・認可サーバ１００が、ユーザにリソースへのアクセスを認可する場合にそのユーザに対して発行するデータであり、アクセストークンとも呼ばれる。また、認証・認可サーバ１００は、ユーザから提示されたトークンを検証することで、ユーザのリソースに対するアクセス権の有無を判定する。

この実施形態では、認証・認可サーバ１００は、文書管理システム３００に保持されたリソース（図面等の文書のデータ）に対するユーザのアクセスの認証や認可（トークン発行）の処理を行う。ここでは文書管理システム３００のみを示したが、認証・認可サーバ１００は、他のシステムに対してもユーザ認証やトークンの発行、検証のサービスを提供可能である。

認証・認可サーバ１００は、ユーザ認証及びトークンの発行・管理のために、トークン照合テーブル１２１、トークン管理テーブル１２３、アクセス権テーブル１２５、証明書条件テーブル１２７、ユーザ属性条件テーブル１２９を有する。これら各テーブルのデータ構造の例を図２に示す。

トークン照合テーブル１２１は、一次トークンと二次トークンとを対応づけて記憶するテーブルである。一次トークンは、委託元の担当者から委託を受けた一次委託先の担当者が取得するトークンである。二次トークンは、一次委託先から委託を受けた二次委託先の担当者が取得するトークンである。一次トークン及び二次トークンの役割及び使われ方については、後で詳しく説明する。

トークン管理テーブル１２３は、トークンと、その発行先のユーザのユーザＩＤ（識別情報）との対応関係を記憶している。

アクセス権テーブル１２５は、文書管理システム３００に記憶された各電子文書（例えば設計図面データ等）に対する各ユーザのアクセス権の情報を記憶している。図示例では、電子文書の文書ＩＤ（識別情報）に対応づけて、その電子文書に対してアクセス権を付与されたユーザのユーザＩＤと、付与されたアクセス権の内容とを記憶している。アクセス権の内容を表す記号のうち「ｒ」は読み出し権、「ｗ」は書き込み権、「ｘ」は実行権を表す。

証明書条件テーブル１２７は、二次委託先の担当者が満たすべき条件のうちの１つである証明書条件を規定するテーブルである。証明書条件は、二次委託先担当者が認証・認可サーバ１００に対して提出（送信）したクライアント証明書に含まれる属性情報が、二次委託先として認められるために満たすべき条件である。図２に示す例では、証明書条件テーブル１２７には、証明書条件の項目毎に、「Ｎｏ．」、「種別」、「パーミッション」、「アクセスパターン」の値が記憶されている。「Ｎｏ．」は当該条件項目の識別番号である。「種別」は、その条件項目が対象とする属性の「種別」である。「パーミッション」は、その条件項目が満たされた場合にそのクライアント証明書を信頼できるものとして受け入れるのか否かを示す。「パーミッション」の値「ＤＥＮＹ」は「受け入れない（信頼できない）」ことを意味し、値「ＰＥＲＭＩＴ」は「受け入れる」ことを意味する。「アクセスパターン」は、提出されたクライアント証明書の、「種別」に対応する属性についての条件となる値である。条件の値のデータ型及び意味は、その属性の「種別」毎に異なる。例えば「ＶＡＬＩＤＩＴＹ」（有効期間）という種別の属性の場合、「アクセスパターン」の値は正の整数値であり、この属性「ＶＡＬＩＤＩＴＹ」の値がこの「アクセスパターン」値以上の場合に当該条件項目が満たされることを意味する。したがって、「１」番の条件項目の場合、ユーザから提示されたクライアント証明書の有効期間が１８２５日（約５年）以上の場合にこの条件項目が満たされ、この結果、この項目の「パーミッション」の値は「ＤＥＮＹ」に従ってそのクライアント証明書は受け入れられない（したがってこれを提示したユーザは二次委託先として認められない）こととなる。

図２では、クライアント証明書の有効期間を例示したが、条件項目の対象となる属性の種別としてこのほかに例えばそのクライアント証明書を発行した認証局名（「ＩＳＳＵＥＲ」）等もある。この発行認証局名についての「アクセスパターン」は、例えば、認証・認可サーバ１００が信頼する認証局の名前のリスト（ホワイトリスト）、又は信頼しない認証局の名前のリスト（ブラックリスト）である。ホワイトリストの場合「パーミッション」の値は「ＰＥＲＭＩＴ」であり、ブラックリストの場合は「パーミッション」の値は「ＤＥＮＹ」である。

証明書条件テーブル１２７に複数の条件項目が含まれる場合、クライアント証明書の受け入れ可否を、それら複数の条件項目の判定結果をどのように組み合わせて判定するかは適宜定めればよい。例えば、「パーミッション」の値が「ＤＥＮＹ」の条件項目が１つでも満たされれば、他の条件項目の判定結果によらず当該クライアント証明書を受け入れ不可と判定し、かつ、「パーミッション」の値が「ＰＥＲＭＩＴ」の条件項目についてはすべての項目が満たされた場合に受け入れ可能と判定する、などの判定方式が考えられる。

なお、「０」番の条件項目は、「１」番以降の各条件項目に係る属性「種別」がすべて提出されたクライアント証明書に含まれていない場合に適用される条件項目であり、この場合は、当該クライアント証明書は受け入れ不可と判定される。

証明書条件テーブル１２７は、１つの例では、委託元の会社全体で共通のものが用いられる。この場合、証明書条件テーブル１２７に示される証明書条件は、委託元会社が指定したものである。

別の例として、委託元会社の部署毎に証明書条件テーブル１２７を用意してもよい。この場合、証明書条件テーブル１２７に示される証明書条件は部署により指定され、その部署のＩＤに対応づけて認証・認可サーバ１００に保持される。

更に別の例として、委託元会社の担当者毎に証明書条件テーブル１２７を用意してもよい。この場合、証明書条件テーブル１２７に示される証明書条件はその委託元担当者により指定され、委託元担当者のユーザＩＤに対応づけて認証・認可サーバ１００に保持される。

更に別の例として、文書管理システム３００に記憶された電子文書毎に証明書条件テーブル１２７を用意してもよい。この場合、電子文書に対するアクセス権を他者に付与する権限を有するユーザである委託元担当者が、その電子文書に対応する証明書条件を指定する。このように指定された証明書条件を表す証明書条件テーブル１２７がその電子文書の文書ＩＤと対応づけて認証・認可サーバ１００に登録される。

ユーザ属性条件テーブル１２９は、二次委託先の担当者が満たすべき条件のうちの１つであるユーザ属性条件を規定するテーブルである。ユーザ属性条件は、二次委託先として適格なユーザの属性が満たすべき条件である。図２に例示するユーザ属性条件テーブル１２９では、ユーザ属性条件の項目毎に、「Ｎｏ．」、「種別」、「パーミッション」、「アクセスパターン」の値が記憶されている。「Ｎｏ．」は当該条件項目の識別番号である。「種別」はその条件項目が対象とするユーザ属性の「種別」である。「パーミッション」は、その条件項目が満たされた場合にそのユーザが二次委託先として適格（値「ＰＥＲＭＩＴ」）、不適格（値「ＤＥＮＹ」）のいずれであるかを示す。「アクセスパターン」は、その「種別」の属性についての条件となる値である。条件の値のデータ型及び意味は、その属性の「種別」毎に異なる。例えば「ＣＯＭＰＡＮＹ ＮＵＭＢＥＲ ＯＦ ＥＭＰＬＯＹＥＥＳ」（会社の従業員数）及び「ＣＯＭＰＡＮＹ ＣＡＰＩＴＡＬ」（会社の資本金）という種別の場合、「アクセスパターン」の値は正の整数値であり、これらの属性の値がこの「アクセスパターン」値以上の場合に、当該条件項目が満たされることを意味する。また「ＣＯＭＰＡＮＹ ＲＥＧＩＯＮ」（会社の所在地域）と言う種別では、「アクセスパターン」の値は、適格（値「ＰＥＲＭＩＴ」）又は不適格（値「ＤＥＮＹ」）と判断する国名又は地域名のリストである。

ユーザ属性条件テーブル１２９内の複数の条件項目を組み合わせて適格か否かを判定する仕方は、証明書条件テーブル１２７の場合と同様でよい。

ユーザ属性条件テーブル１２９も、証明書条件テーブル１２７の場合と同様、委託元の会社全体で共通のものとしてもよいし、委託元会社の部署毎、委託元担当者毎、又は電子文書毎に用意してもよい。

この実施形態では、ユーザが提出したクライアント証明書が証明書条件を満たし、かつ、そのユーザのユーザ属性がユーザ属性条件を満たす場合に、そのユーザが、一次委託先から権限委譲を受ける二次委託先として適格であると判定する。

また、認証・認可サーバ１００は、委託先情報検証部１１０を有する。委託先情報検証部１１０は、証明書条件テーブル１２７及びユーザ属性条件テーブル１２９を参照して、二次委託先担当者が権限委譲を受ける条件を満たすかどうか（すなわち適格な二次委託先であるか否か）、検証する。委託先情報検証部１１０は、ユーザ属性についての検証のために、属性プロバイダ４００を利用する。

属性プロバイダ４００は、認証されたユーザのユーザ属性の情報を提供する装置である。属性プロバイダ４００としてトラストフレームワークに参加しているものを用いることで、属性プロバイダ４００から提供されるユーザ属性情報の信頼性がトラストフレームワークにより保証される。トラストフレームワークとは、ユーザ認証サービスを提供する提供者（アイデンティティ・プロバイダ：ＩｄＰ。本実施形態の認証・認可サーバ１００に）、ＩｄＰから提供されるユーザＩＤ等の情報に従ってユーザに対してオンラインサービスを提供するサービス提供者（リライイング・パーティ：ＲＰ。本実施形態の文書管理システム３００）、及びユーザの属性情報をＩｄＰやＲＰに提供する提供者（アトリビュート・プロバイダ：ＡＰ。本実施形態の属性プロバイダ４００）の間での、ＩＤ連携、属性交換のための信頼の枠組みである。このような属性プロバイダの実装例としては、「学認トラストフレームワーク」や米国政府の「ＩＣＡＭ」（Identity Credentialing and Access Management）トラストフレームワークで用いられる「Attribute eXchange Network」等がある。

委託先情報検証部１１０が実行する検証処理については後で詳しい例を説明する。

中間サーバ２００は、ユーザからの文書管理システム３００へのアクセスを仲介するサーバである。中間サーバ２００は、ユーザからの文書管理システム３００へのリクエストを文書管理システム３００の代わりに受信し、そのリクエストの正当性を検証し、正当なリクエストと判断した場合に、そのリクエストを文書管理システム３００に転送する。中間サーバ２００は、特に二次委託先担当者からのリクエストの正当性を検証するために、一次委託先担当者からの一次トークンを提示した二次委託先担当者のＷｅｂブラウザ７００に対してセッションＩＤを発行する。セッションＩＤは、一意な文字列であり、二次委託先担当者とのセッションを識別するために用いられる。このセッションＩＤの発行処理は、状態セッション生成部２１０により行われる。セッションＩＤは、二次委託先担当者のＷｅｂブラウザ７００に対して、Cookie（クッキー）として設定される。以降、二次委託先担当者と中間サーバ２００とのやりとりは、１つのセッションとして、このセッションＩＤにより管理される。このセッションのことは、以下では状態セッションと呼ぶ。

また、状態セッション生成部２１０は、Ｗｅｂブラウザ７００を認証・認可サーバ１００にリダイレクトして二次トークンを取得させる。そして、その二次トークンをＷｅｂブラウザ７００から受け取り、元の一次トークン及びセッションＩＤと対応づけて状態セッション照合テーブル２２０に保持する。状態セッション照合テーブル２２０は、図３に示すように、セッションＩＤ、一次トークン、及び二次トークンの対応関係を保持するテーブルである。その後、二次委託先担当者（Ｗｅｂブラウザ７００）から文書管理システム３００へのリクエストを受け取ると、中間サーバ２００は、そのリクエストと共にＷｅｂブラウザ７００から提示される二次トークン及びセッションＩＤが、状態セッション照合テーブル２２０に保持している二次トークン及びセッションＩＤの組合せに合致するか否かを判定し、合致する場合に、そのリクエストを（中間サーバ２００にとって）正当なものと判定する。そして、正当なものと判定した場合、そのリクエストに対してその二次トークンを付加し、二次トークン付加後のリクエストを文書管理システム３００に転送する。

二次委託先担当者からのリクエストの検証のために、中間サーバ２００は、状態セッション生成部２１０及び状態セッション照合テーブル２２０を有する。

＜処理の流れ＞
以下、図１のシステムにおける処理の流れを説明する。以下の説明では、図１に示した「(1)」等の括弧付きの処理順序の番号に従って、順に説明を行う。この例では、本システムが、委託元の会社全体で共通の証明書条件テーブル１２７及びユーザ属性条件テーブル１２９を用いる場合を説明する。

(1) 委託元（製品開発元）の担当者は、自分の端末５００から、製造委託を行う製品の設計図面のデータ（以下単に「図面」と呼ぶ）を文書管理システム３００に登録する。

(2) 委託元担当者は、ステップ(1)で登録した図面に対するアクセス権を一次委託先の担当者に付与する場合、その一次委託先担当者に付与するアクセス権をアクセス権テーブル１２５に設定する。このアクセス権設定により、一次委託先の担当者が文書管理システム３００内のその図面に対するアクセス権を有する状態となる。

この例では、委託元の会社全体で共通の証明書条件テーブル１２７及びユーザ属性条件テーブル１２９を用いる。これら証明書条件テーブル１２７及びユーザ属性条件テーブル１２９は、その会社内のしかるべき権限を持つユーザによりあらかじめ作成されているものとする。

委託元担当者は、一次委託先の担当者に、委託を行う旨の連絡を行う。この時点では、トークン照合テーブル１２１、トークン管理テーブル１２３及び状態セッション照合テーブル２２０は、図２及び図３に示すように、空（何もデータが無い）状態であるとする。

(3) 委託元担当者から委託の連絡を受けた一次委託先の担当者は、自分の端末のＷｅｂブラウザ６００を操作して、文書管理システム３００内の図面についてのアクセス権委譲用のＵＲＬにアクセスする。このＵＲＬは、例えば、認証・認可サーバ１００のポータルのＷｅｂページ上のメニュー項目「アクセス権委譲」に埋め込まれている。このＵＲＬは、認証・認可サーバ１００が実行するアクセス権委譲処理を指しており、一次委託先担当者がこのＵＲＬにアクセスすることにより、認証・認可サーバ１００がアクセス権委譲処理を開始する。

(4) このアクセス権委譲処理にて認証・認可サーバ１００は、まずユーザ認証のための認証情報（例えばユーザＩＤとパスワード）の入力画面のＷｅｂページを一次委託先担当者のＷｅｂブラウザ６００に返す。一次委託先担当者は、認証・認可サーバ１００が返す入力画面に認証情報の入力等を行い、ユーザ認証を受ける。この例では、その一次委託先担当者が、文書管理システム３００にアクセス権を持つ正当なユーザであると認証される。

(5) このように一次委託先担当者が文書管理システム３００にアクセス権を持つ正当な担当者で有ると判定した場合、認証・認可サーバ１００は、一次トークンを発行する。

(6) 認証・認可サーバ１００は、トークン照合テーブル１２１の「一次トークン」列に、その一次トークンを保存するとともに、トークン管理テーブル１２３に、その一次トークンを一次委託先担当者のユーザＩＤと対応づけて保存する。このステップ(6)の時点でのトークン照合テーブル１２１、トークン管理テーブル１２３及び状態セッション照合テーブル２２０の状態を図４に示す。図４に示すように、この時点では、トークン管理テーブル１２３には、発行したトークン（一次トークン）と一次委託先担当者のユーザＩＤの値がそれぞれ登録され、トークン照合テーブル１２１にはその一次トークンのみが登録される（対応する二次トークンの欄は空）。また状態セッション照合テーブル２２０は空のままである。

(7) 次に認証・認可サーバ１００は、一次委託先担当者に対して、二次委託先の担当者に通知するＵＲＬ（以下「一次トークン登録アドレス」という）を送付する。

図５に一次トークン要求アドレスの具体例を示す。図示のように、一次トークン要求アドレスは、中間サーバ２００の一次トークン登録用のエンドポイントＵＲＬの後に、パラメータとして一次トークンとリダイレクトＵＲＩ（Uniform Resource Identifier）とがクエリ文字列の形で付加されて構成されたものである。一次トークンはパラメータ名が「delegator_token」であり、この例では一次トークンの値は「vfrcde3」である。リダイレクトＵＲＩは「redirect_uri」というパラメータ名で示されている。パラメータ「redirect_uri」は、OpenID Connectに規定されるパラメータであり、認証後のリダイレクト先（すなわち認証結果の応答の宛先）のＵＲＩを示す。図５では煩雑さを避けるために一部省略したが、この例のリダイレクトＵＲＩは図７に示す二次トークン発行要求のエンドポイントである。すなわち、このリダイレクトＵＲＩは、認証・認可サーバ１００のエンドポイントＵＲＬの後に、一次トークンと、中間サーバ２００の二次トークン発行要求のエンドポイントＵＲＬがクエリ文字列として続いたものとなっている。

(8) 一次委託先担当者は、認証・認可サーバ１００から受け取った一次トークン登録アドレスを、例えば電子メール等により二次委託先担当者に送付する。ここで、一次委託先担当者は、見積もり等の目的で、複数の二次委託先担当者（見積もり段階なので厳密には候補者であるが、煩雑さを避けるためにこのような場合にも「二次委託先担当者」と呼ぶ）に対して一次トークン登録アドレスを送ることも考えられる。以降の処理は、一次トークン登録アドレスを渡した二次委託先担当者（あるいは候補者）毎に行われる。

(9) 二次委託先担当者は、一次委託先担当者から受け取った一次トークン登録アドレスにアクセスする。これにより、二次委託先担当者のＷｅｂブラウザ７００から中間サーバ２００に対して、一次トークンと認証・認可サーバ１００へのリダイレクト指示とをパラメータとして含んだ、一次トークン登録処理へのアクセス指示がＨＴＴＰリクエストとして送信される。

(10)このＨＴＴＰリクエストを受けた中間サーバ２００は、一次トークン登録処理を開始する。この処理では、まず状態セッションのセッションＩＤを発行する。

(11)また中間サーバ２００は、状態セッション照合テーブル２２０に、発行したセッションＩＤと、ＨＴＴＰリクエスト中に含まれる一次トークンとを対応付けて保存する。この時点でのトークン照合テーブル１２１、トークン管理テーブル１２３及び状態セッション照合テーブル２２０の状態を図６に示す。図６に示すように、この時点では、トークン照合テーブル１２１及びトークン管理テーブル１２３は図４に示したステップ(6)の時点と同じ状態だが、状態セッション照合テーブル２２０にはそのセッションＩＤと一次トークンとのペアが新たに登録されている。

(12)また中間サーバ２００は、(9)のＨＴＴＰリクエストに対するレスポンスで、状態セッションのセッションＩＤ、及び一次トークンをCookie（クッキー）として二次委託先担当者のＷｅｂブラウザ７００に設定する。さらに、中間サーバ２００は、ステップ(9)のＨＴＴＰリクエストに含まれ、クエリとして一次トークンと中間サーバの二次トークン受付処理のエンドポイントＵＲＬを付加した文字列で表されるＵＲＩにリダイレクトする。このリダイレクトＵＲＩは、図７に示す二次トークン要求アドレスである。リダイレクトにより、Ｗｅｂブラウザ７００から認証・認可サーバ１００に対し、一次トークンと、中間サーバ２００の二次トークン受付処理のエンドポイントＵＲＬがパラメータとして送られる。

(13)このリダイレクトを受けた認証・認可サーバ１００は、ユーザ認証用の画面（認証情報を入力するためのＷｅｂページ）を二次委託先担当者のＷｅｂブラウザ７００に返す。二次委託先担当者は、その認証用の画面にしたがって、ユーザ認証処理を行う。例えば、その画面に対して自分のユーザＩＤ及びパスワードを入力する。ここではこのユーザ認証は成功したとする。また認証・認可サーバ１００は、Ｗｅｂブラウザ７００にクライアント証明書の提示を要求する。Ｗｅｂブラウザ７００には、前もって二次委託先担当者のクライアント証明書がインストールされている。Ｗｅｂブラウザ７００は、その要求に応じて、そのクライアント証明書を認証・認可サーバ１００に返す。なお、クライアント証明書は、認証局から発行された、その二次委託先担当者を証明するデジタル証明書である。

(14)クライアント証明書を受け取った認証・認可サーバ１００では、委託先情報検証部１１０が、二次委託先担当者から提示されたクライアント証明書が証明書条件テーブル１２７に設定された証明書条件を満たすかどうかを判定する。証明書条件が満たされない場合、今回アクセスしてきた二次委託先担当者は委託元の課した二次委託先の条件を満たさないと言うことである。この場合、認証・認可サーバ１００は、二次委託先担当者のＷｅｂブラウザ７００に対し、二次委託先の条件を満たさないこと等を示すエラーメッセージを返し、処理を終了する。ここでは証明書条件が満たされたとし、説明を続ける。

(15)また委託先情報検証部１１０は、ステップ(13)のユーザ認証で確認した二次委託先担当者のユーザＩＤに対応するユーザ属性を属性プロバイダ４００に問い合わせる。そして、この問合せにより属性プロバイダ４００から取得したユーザ属性が、ユーザ属性条件テーブル１２９に設定されたユーザ属性条件を満たすかどうかを判定する。ユーザ属性条件が満たされない場合、今回アクセスしてきた二次委託先担当者は委託元の課した二次委託先の条件を満たさないので、認証・認可サーバ１００は、二次委託先担当者のＷｅｂブラウザ７００に対してエラーメッセージを返し、処理を終了する。ここではユーザ属性条件が満たされたとし、説明を続ける。

(16)この例では、ユーザ認証が成功し、証明書条件及びユーザ属性条件も満たされたので、その二次委託担当者は一次委託先担当者から権限を委譲される二次委託先として適格である。そこで認証・認可サーバ１００は、その二次委託先担当者のために二次トークンを発行し、トークン照合テーブル１２１及びトークン管理テーブル１２３に対してその二次トークンの情報を反映する。すなわち、トークン照合テーブル１２１内の、ステップ(10)でリダイレクトのパラメータとして受け取った一次トークンに対応するレコード内の「二次トークン」列に、その発行した二次トークンの値を保存するとともに、トークン管理テーブル１２３に、その二次委託先担当者のユーザＩＤと対応づけてその二次トークンを保存する。この時点でのトークン照合テーブル１２１、トークン管理テーブル１２３及び状態セッション照合テーブル２２０の状態を図８に示す。図８に示すように、この時点では状態セッション照合テーブル２２０は図６に示したステップ(6)の時点と同じ状態だが、トークン照合テーブル１２１には一次トークンに対応する二次トークンが登録され、トークン管理テーブル１２３にはその二次トークンと二次委託先担当者のユーザＩＤのペアが追加（同テーブルの内容の２行目）されている。

(17)次に認証・認可サーバ１００は、二次委託先担当者のＷｅｂブラウザ７００を、中間サーバ２００の二次トークン登録用のＵＲＬ（以下、「二次トークン登録アドレス」という）にリダイレクトする。この二次トークン登録アドレスは、二次トークン要求アドレス（図７参照）内にパラメータとして含まれた中間サーバ２００の二次トークン登録用のエンドポイントＵＲＬの後に、二次トークンがパラメータとして付加されたものである（図９参照）。このリダイレクトにより、Ｗｅｂブラウザ７００から中間サーバ２００に対して、二次トークンが伝達される。また、このときＷｅｂブラウザ７００に保持された中間サーバ２００のCookie（ステップ(12)で設定されたもの）が、中間サーバ２００に送られる。

(18)リダイレクトされたアクセスを受けた中間サーバ２００は、二次トークン登録アドレスのパラメータから二次トークンを抽出する。さらに、Ｗｅｂブラウザ７００が提示したCookieからセッションＩＤと一次トークンを抽出する。

(19)次に中間サーバ２００は、状態セッション照合テーブル２２０上で、ステップ(18)で抽出したセッションＩＤと一次トークンとが同一レコード上に保存されているかどうかを判定する。それらセッションＩＤと一次トークンとが同一レコード上に保存されていない場合、何らかの誤りが生じているということなので、この場合、中間サーバ２００は二次委託先担当者のＷｅｂブラウザ７００にエラーメッセージを送り、一連の処理を中止する。それらセッションＩＤと一次トークンとが同一レコード上に保存されていれば、正しいセッションが行われていると言うことなので、中間サーバ２００は処理を続行する。ここではそれらセッションＩＤと一次トークンとが同一レコード上に保存されているとして説明を続ける。

(20)この場合、中間サーバ２００は、二次トークン登録アドレスから抽出した二次トークンを、状態セッション照合テーブル２２０内の、そのセッションＩＤと一次トークンとを含むレコード内の、二次トークンのフィールドに登録する。この時点でのトークン照合テーブル１２１、トークン管理テーブル１２３及び状態セッション照合テーブル２２０の状態を図１０に示す。図１０に示すように、この時点ではトークン照合テーブル１２１及びトークン管理テーブル１２３は図８に示したステップ(16)の時点と同じ状態だが、状態セッション照合テーブル２２０には、ステップ(16)の時点では空欄だった二次トークンの欄に、今回抽出した二次トークンが登録されている。

(21)そして中間サーバ２００は、Ｗｅｂブラウザ７００へのレスポンスの際に、Ｗｅｂブラウザ７００に対してその二次トークンをCookieとして設定する。これにより、Ｗｅｂブラウザ７００は、中間サーバ２００に対応するCookieとして、一次トークン、セッションＩＤ、及び二次トークンを保持していることとなる。Ｗｅｂブラウザ７００は、それらCookieの期限が切れるまでは、中間サーバ２００にアクセスする際には、それらCookieを中間サーバ２００に送る。

(22)以上の二次トークン取得の処理を成功裏に終えた後、二次委託先担当者は、Ｗｅｂブラウザ７００を操作して、文書管理システム３００内に格納されている委託対象業務で用いる図面を取得するためのＵＲＬ（「図面取得アドレス」）にアクセスする。図面取得アドレスは、図１１に示すように、中間サーバ２００の文書要求受付用のエンドポイントのＵＲＬの後に、委託対象業務で用いる図面の文書ＩＤがパラメータとして付加されたものである。この図面取得アドレスは、例えば、委託元の担当者から一次委託先担当者へ電子メール等で伝達され、更に一次委託先担当者から二次委託先担当者へ電子メール等で伝達される。

(23)Ｗｅｂブラウザ７００から図面取得アドレスにアクセスするＨＴＴＰリクエストを受けた中間サーバ２００は、そのＨＴＴＰリクエストに対応づけてＷｅｂブラウザ７００から送信されたCookieから、セッションＩＤと二次トークンを抽出する。

(24)次に中間サーバ２００は、そのCookieから抽出したセッションＩＤと二次トークンとのペアを含んだレコードが状態セッション照合テーブル２２０内にあるか（すなわちそれら両者が互いに対応づけられているか）を判定する。そのセッションＩＤと二次トークンとのペアを含んだレコードが状態セッション照合テーブル２２０から見つからない場合、何らかのエラーが生じたということなので、中間サーバ２００はＷｅｂブラウザ７００にエラーメッセージを返し、処理を終了する。ここでは、そのセッションＩＤと二次トークンとのペアを含んだレコードが状態セッション照合テーブル２２０から見つかったものとして説明を進める。

(25)この場合、中間サーバ２００は、ステップ(23)でＷｅｂブラウザ７００から受け取ったＨＴＴＰリクエストに対してその二次トークンを付加し、二次トークン付加後のリクエストを文書管理システム３００に転送する。ここで、中間サーバ２００は、二次トークンを、ＵＭＡに準拠した単なるトークン（一次、二次の区別のないもの）としてリクエストに付加する。これにより、ＵＭＡに準拠した文書管理システム３００は、その二次トークンをトークンと認識できる。

(26)中間サーバ２００から転送されたリクエストを受け取った文書管理システム３００では、トークン検証依頼部３１０が実行される。トークン検証依頼部３１０は、そのリクエストからトークン（二次トークン）と文書ＩＤを抽出し、抽出したトークン及び文書ＩＤを認証・認可サーバ１００に送付して検証を依頼する。

(27)認証・認可サーバ１００は、トークン照合テーブル１２１から、その検証依頼中のトークンを二次トークンとして持つレコードを探し、そのレコード中から一次トークンを取得する。そして、その一次トークンで、文書管理システム３００上のその文書ＩＤに対応する図面に対するアクセスが可能かどうかを検証する。すなわち、その一次トークンに対応するユーザＩＤをトークン管理テーブル１２３から求め、求めたユーザＩＤのその文書ＩＤに対するアクセス権の情報をアクセス権テーブル１２５から求める。そして、求めたアクセス権により、その文書ＩＤの図面にアクセスが可能かどうかを検証（判定）する。ここで、ステップ(26)での文書管理システム３００から認証・認可サーバ１００への検証依頼に、二次委託先担当者から要求された文書に対する操作の種類の情報を含め、この検証ステップ(27)で、認証・認可サーバ１００が、求めたアクセス権によりその種類の操作が可能かどうかを判定してもよい。

(28)認証・認可サーバ１００は、ステップ(27)の検証結果を、文書管理システム３００に応答する。

(29)文書管理システム３００は、ステップ(28)の応答が「アクセス権なし」であれば、中間サーバ２００を介して二次委託先担当者のＷｅｂブラウザ７００に対して、要求された図面にアクセスできない旨などを示すエラーメッセージを返し、図面を提供せずに処理を終える。逆に、ステップ(28)の応答が、読出権等のアクセス権があることを示すものであれば、文書管理システム３００は、中間サーバ２００を経由してＷｅｂブラウザ７００に対して図面を提供する。

＜一次委託先担当者との間での処理＞
次に、図１２を参照して、一次委託先担当者の認証から一次トークンの発行までの処理（図１のステップ(3)〜(6)）の流れを更に詳しく説明する。以下の説明では、図１２に示した「(1)」等の括弧付きの処理順序の番号に従って、順に説明を行う。

(1) 一次委託先担当者は、Ｗｅｂブラウザ６００からアクセス権委譲処理のＵＲＬにアクセスする。このＵＲＬには、パラメータとして、アクセス権委譲の対象となる図面の文書ＩＤが含まれている。

(2) 認証・認可サーバ１００は、その一次委託先担当者が認証・認可サーバ１００にログイン済みかどうか確認する。ログイン済みでなければ、以下のステップ(3)〜(5)の処理を実行する。

(3) 認証・認可サーバ１００は、ログイン認証画面（ユーザＩＤ／パスワードの入力画面）を一次委託先担当者のＷｅｂブラウザ７００に返す。

(4) 一次委託先担当者は、ログイン認証画面にユーザＩＤ及びパスワードを入力し、認証・認可サーバ１００に送信する。

(5) 認証・認可サーバ１００は、Ｗｅｂブラウザ６００から受け取ったユーザＩＤとパスワードのペアが、自分が保持している正当なユーザＩＤとパスワードのペアに合致するかどうかを検証する。ここではこの検証が成功したものとする（ログイン認証成功）。

(6) ステップ(2)で一次委託先担当者が既にログイン済みであると分かった場合、又はステップ(3)〜(5)のログイン認証が成功した場合、認証・認可サーバ１００は、一次トークンを発行する。

(7) 認証・認可サーバ１００は、トークン照合テーブル１２１の「一次トークン」列に、ステップ(6)で発行した一次トークンを保存する。

(8) 認証・認可サーバ１００は、トークン管理テーブル１２３に、一次委託先担当者のユーザＩＤと紐付けてその一次トークンを保存する。

(9) 認証・認可サーバ１００は、一次委託先担当者に一次トークン登録アドレスを送付する。この送付には、例えばS/MIMEメール等、第三者が閲覧できない方法を用いることが考えられる。ただし、送付の仕方はこれに限定されるものではない。

＜二次委託先担当者との間での処理＞
次に、図１３及び図１４を参照して、二次委託先担当者の認証から二次トークンの発行までの処理（図１のステップ(9)〜(17)）の流れを更に詳しく説明する。以下の説明では、図１３及び図１４に示した「(1)」等の括弧付きの処理順序の番号に従って、順に説明を行う。

(1) 二次委託先担当者は、Ｗｅｂブラウザ７００から一次委託先担当者から受け取った一次トークン登録アドレス（図５参照）にアクセスする。一次トークン登録アドレスは、中間サーバ２００の一次トークン登録処理用のＵＲＬであり、一次トークンをパラメータとして含んでいる。

(2) アクセスを受けた中間サーバ２００は、状態セッションのセッションＩＤを発行する。

(3) 中間サーバ２００は、状態セッション照合テーブル２２０に、そのセッションＩＤと、一次トークン登録アドレスに含まれる一次トークンとを対応付けて保存する。

(4) 中間サーバ２００は、Ｗｅｂブラウザ７００を二次トークン要求アドレス（図７参照）にリダイレクトする。二次トークン要求アドレスは、認証・認可サーバ１００のエンドポイントのＵＲＬを示している。

(5) 二次委託先担当者（Ｗｅｂブラウザ７００）からアクセスを受けた認証・認可サーバ１００は、二次委託先担当者が認証・認可サーバ１００にログイン済みかどうか確認する。ログイン済みでない場合に、以下のステップ(6)〜(8)の処理を実行する。

(6) 認証・認可サーバ１００は、ログイン認証画面をＷｅｂブラウザ７００に返す。

(7) 二次委託先担当者は、そのログイン認証画面にユーザＩＤ及びパスワードを入力する。Ｗｅｂブラウザ７００は、入力されたユーザＩＤ及びパスワードを認証・認可サーバ１００に送信する。

(8) 認証・認可サーバ１００は、Ｗｅｂブラウザ７００から受け取ったユーザＩＤ及びパスワードが、自分が保持している正当なユーザＩＤ及びパスワードのペアに該当するかどうかを検証する。ここでは、検証が成功したものとする（ログイン認証成功）。

(9) ステップ(5)で一次委託先担当者が既にログイン済みであると分かった場合、又はステップ(6)〜(8)のログイン認証が成功した場合、認証・認可サーバ１００は、二次委託先担当者（Ｗｅｂブラウザ７００）にクライアント証明書の提示を要求する。

(10)二次委託先担当者は、クライアント証明書を認証・認可サーバ１００に送付する。

(11)認証・認可サーバ１００は、受け取ったクライアント証明書が信頼する証明機関が発行したものかどうかを検証する。

(12)クライアント証明書が信頼する証明機関が発行したものではない場合、エラー画面を返して処理を終了する。

(13) クライアント証明書が信頼する証明機関が発行したものである場合、認証・認可サーバ１００は、そのクライアント証明書に含まれる属性情報が、証明書条件テーブル１２７に含まれる証明書条件を満たすかどうか判定する。以下、図１４の処理に移る。

(14)クライアント証明書が証明書条件を満たさない場合、エラー画面を返して処理を終了する。

(15)クライアント証明書が証明書条件を満たす場合、認証・認可サーバ１００は、二次委託先担当者のユーザＩＤに対応するユーザ属性を属性プロバイダ４００に問い合わせる。

(16)認証・認可サーバ１００は、ステップ(15)で取得したユーザ属性が、ユーザ属性条件テーブル１２９に保持されるユーザ属性条件を満たすかどうか判定する。

(17)ユーザ属性条件が満たされない場合、エラー画面を返して処理を終了する。

(18)ユーザ属性条件が満たされた場合、認証・認可サーバ１００は、二次トークンを発行する。

(19)認証・認可サーバ１００は、一次トークン登録アドレス（ステップ(1)参照）から抽出した一次トークンに対応する「二次トークン」として、その二次トークンをトークン照合テーブル１２１に保存する。

(20)認証・認可サーバ１００は、トークン管理テーブル１２３に、二次委託先担当者のユーザＩＤと紐付けてその二次トークンを保存する。

(21)認証・認可サーバ１００は、二次委託先担当者のＷｅｂブラウザ７００を、二次トークン登録アドレスにリダイレクトする。

＜変形例＞
以上、本発明の一つの実施形態を説明した。

以上の実施形態では、委託元の会社全体で共通の証明書条件テーブル１２７及びユーザ属性条件テーブル１２９を用いる場合を例にとった。

この代わりに、証明書条件テーブル１２７及びユーザ属性条件テーブル１２９を図面毎に設定する仕組みを採用している場合には、図１のステップ(2)において、委託元担当者が、一次委託先担当者に委託する図面に適用する証明書条件及びユーザ属性条件を指定する。指定された証明書条件及びユーザ属性条件を示す証明書条件テーブル１２７及びユーザ属性条件テーブル１２９が、その図面の文書ＩＤと対応づけて認証・認可サーバ１００に登録される。この場合、認証・認可サーバ１００は、その図面についてのアクセス権委譲用のＵＲＬを生成し、そのＵＲＬを委託元担当者に提供する。このＵＲＬは、その図面の文書ＩＤに対応づけられている（例えばその文書ＩＤ又はこれに一意に関連付けられた情報をパラメータとして含んでいる）。委託元担当者は、そのＵＲＬを一次委託先担当者に送信する。一次委託先担当者は、図１のステップ(3)において、そのＵＲＬにアクセスする。認証・認可サーバ１００は、そのＵＲＬへのアクセス要求（ＨＴＴＰリクエスト）に含まれる情報から、そのＵＲＬに対応する文書ＩＤを特定する。そして、ステップ(4)では、認証した一次委託先担当者が、その文書ＩＤに対するアクセス権を持つかどうかをアクセス権テーブル１２５を参照して確認してもよい。一次委託先担当者がその文書ＩＤに対するアクセス権を持たない場合、一次トークンを発行しない。一次委託先担当者がその文書ＩＤに対するアクセス権を持つ場合には、ステップ(5)で一次トークンを発行する。この例では、トークン照合テーブル１２１に文書ＩＤの欄を設け、ステップ(6)ではトークン照合テーブル１２１に、発行した一次トークンとその文書ＩＤとを登録する。また、ステップ(12)で中間サーバ２００から二次委託先担当者の二次トークン要求のリダイレクトを受けた認証・認可サーバ１００は、そのリダイレクトの際に受け取った一次トークンに対応する文書ＩＤをトークン照合テーブル１２１から求める。そして、ステップ(13)〜(15)では、その求めた文書ＩＤに対応する証明書条件テーブル１２７及びユーザ属性条件テーブル１２９を用いて、二次委託先担当者が、委託元が想定する当該図面についての二次委託先として適格であるかどうかを判定する。

また、証明書条件テーブル１２７及びユーザ属性条件テーブル１２９を委託元会社の部署毎、又は委託元の担当者毎に設定する仕組みを採用している場合には、証明書条件テーブル１２７及びユーザ属性条件テーブル１２９は、図１のステップ(2)の時点ではすでに設定済みであると考えられる。この例では、認証・認可サーバ１００は、ステップ(2)で、その図面についてのアクセス権委譲用のＵＲＬを生成し、そのＵＲＬを委託元担当者に提供する。このＵＲＬは、委託元担当者のユーザＩＤに対応づけられている（例えばそのユーザＩＤ又はこれに一意に関連付けられた情報をパラメータとして含んでいる）。委託元担当者は、そのＵＲＬを一次委託先担当者に送信する。一次委託先担当者は、図１のステップ(3)において、そのＵＲＬにアクセスする。認証・認可サーバ１００は、そのＵＲＬへのアクセス要求（ＨＴＴＰリクエスト）に含まれる情報から、そのＵＲＬに対応するユーザＩＤ（委託元担当者）を特定する。この例では、トークン照合テーブル１２１に「委託元担当者のユーザＩＤ」の欄を設け、ステップ(6)ではトークン照合テーブル１２１に、発行した一次トークンとそのユーザＩＤとを登録する。また、ステップ(12)で中間サーバ２００から二次委託先担当者の二次トークン要求のリダイレクトを受けた認証・認可サーバ１００は、そのリダイレクトの際に受け取った一次トークンに対応するユーザＩＤをトークン照合テーブル１２１から求める。そして、ステップ(13)〜(15)では、その求めたユーザＩＤに対応する証明書条件テーブル１２７及びユーザ属性条件テーブル１２９（又はそのユーザＩＤが属する部署を組織情報データベースから求め、その部署に対応する証明書条件テーブル１２７及びユーザ属性条件テーブル１２９）を用いて、二次委託先担当者が、委託元が想定する当該図面についての二次委託先として適格であるかどうかを判定する。

また以上に説明した実施形態では、一次トークンは一次委託先担当者のユーザＩＤに対応づけられるのみ（トークン管理テーブル１２３。図２参照）であり、対象の文書を限定していない。このため、一次委託先担当者から一次トークンを受け取った二次委託先担当者は、一次委託先担当者がアクセス権を持つすべての文書（図面）にアクセスできる可能性がある。これに対し、変形例として、対象となる文書を特定して一次トークンを発行するようにしてもよい。この変形例では、図１のステップ(4)の一次委託先担当者の認証の成功後、認証・認可サーバ１００は、一次委託先担当者に対し、二次委託先に権限を委譲する文書を選択させる。ここでは、認証・認可サーバ１００は、例えば、アクセス権テーブル１２５からその一次委託先担当者がアクセス権を持つ文書を特定し、特定した文書のリストをＷｅｂブラウザ６００に返し、一次委託先担当者がそのリストから権限委譲の対象とする文書を選択すればよい。認証・認可サーバ１００は、その指定された文書についての一次トークンを発行する。すなわち、この変形例では、トークン照合テーブル１２１には、文書ＩＤの欄が設けられ、認証・認可サーバ１００は、発行した一次トークンを、一次委託先担当者が選択した文書の文書ＩＤと対応づけて、トークン照合テーブル１２１に登録する。そして、認証・認可サーバ１００は、文書管理システム３００からトークン（二次トークン）と文書ＩＤを含む検証依頼を受けた場合、図１のステップ(27)にて、そのトークンを二次トークンとして持ち、かつその文書ＩＤを含んだレコードをトークン照合テーブル１２１から求める。そのようなレコードが見つかれば、図１のステップ(27)と同様、そのレコード中の一次トークンに対応するユーザ（一次委託先担当者）のアクセス権で、その文書ＩＤにアクセス可能かどうかを判定する。一方、そのようなレコードが見つからない場合は、アクセス権無しと判定する。

また、別の変形例として、認証・認可サーバ１００に、二次委託先用アクセス権テーブルと二次委託先用アクセス権設定部を追加してもよい（いずれも図示省略）。

二次委託先用アクセス権テーブルは、二次委託先担当者に付与するアクセス権を、一次トークンと対応づけて保持するテーブルである。

二次委託先用アクセス権設定部は、一次委託先担当者から二次委託先担当者に付与するアクセス権の設定を受け付ける。

すなわち、二次委託先用アクセス権設定部は、一次トークンの発行後、アクセス権設定用の画面（Ｗｅｂページ）を一次委託先担当者のＷｅｂブラウザ６００に送信する。より詳しくは、この例では、一次トークンの対象となる文書ＩＤが１つに特定されており、その文書ＩＤに対するその一次委託先担当者のアクセス権をアクセス権テーブル１２５から求め、求めたアクセス権の範囲内のアクセス権を選択可能としたユーザインタフェース部品を含んだＷｅｂページを作成し、Ｗｅｂブラウザ６００に送信する。このＷｅｂページに対して一次委託先担当者が入力したアクセス権の情報が、その一次トークンに対応づけて、二次委託先用アクセス権テーブルに登録される。

認証・認可サーバ１００は、文書管理システム３００から二次トークンの検証依頼（図１のステップ(26)）を受け取ると、その二次トークンに対応する一次トークンをトークン照合テーブル１２１から求める。そして、求めた一次トークンに対応するアクセス権情報を二次委託先用アクセス権テーブルから求め、求めたアクセス権情報に従い、当該文書ＩＤを持つ図面に対する二次委託先担当者の操作の可否、あるいは許可可能な操作の種類を判定する。

以上に例示した認証・認可サーバ１００、中間サーバ２００及び文書管理システム３００は、例えば、汎用のコンピュータに当該装置の各機能モジュールの処理を表すプログラムを実行させることにより実現してもよい。ここで言うコンピュータは、例えば、ハードウエアとして、ＣＰＵ等のマイクロプロセッサ、ランダムアクセスメモリ（ＲＡＭ）およびリードオンリメモリ（ＲＯＭ）等のメモリ（一次記憶）、ＨＤＤ（ハードディスクドライブ）やＳＳＤ（ソリッドステートドライブ）、フラッシュメモリ等の二次記憶を制御する二次記憶コントローラ、各種Ｉ／Ｏ（入出力）インタフェース、無線又は有線のネットワークとの接続のための制御を行うネットワークインタフェース等が、たとえばバスを介して接続された回路構成を有する。また、そのバスに対し、例えばＩ／Ｏインタフェース経由で、ＣＤやＤＶＤ、ブルーレイディスクなどの可搬型ディスク記録媒体に対する読み取り及び／又は書き込みのためのディスクドライブ、フラッシュメモリなどの各種規格の可搬型の不揮発性記録媒体に対する読み取り及び／又は書き込みのためのメモリリーダライタ、などが接続されてもよい。上に例示した各機能モジュールの処理内容が記述されたプログラムがＣＤやＤＶＤ等の記録媒体を経由して、又はネットワーク等の通信手段経由で、フラッシュメモリ等の二次記憶装置に保存され、コンピュータにインストールされる。二次記憶装置に記憶されたプログラムがＲＡＭに読み出されＣＰＵ等のマイクロプロセッサにより実行されることにより、上に例示した機能モジュール群が実現される。

以上の実施形態及び変形例において、認証・認可サーバ１００と中間サーバ２００が同一のコンピュータにインストールされていてもよい。また、認証・認可サーバ１００と中間サーバ２００のうちの一方又は両方が、文書管理システム３００と同一のコンピュータにインストールされていてもよい。

１００ 認証・認可サーバ、１１０ 委託先情報検証部、１２１ トークン照合テーブル、１２３ トークン管理テーブル、１２５ アクセス権テーブル、１２７ 証明書条件テーブル、１２９ ユーザ属性条件テーブル、２００ 中間サーバ、２１０ 状態セッション生成部、２２０ 状態セッション照合テーブル、３００ 文書管理システム、３１０ トークン検証依頼部、４００ 属性プロバイダ、５００ （委託元担当者の）端末、６００ Ｗｅｂブラウザ（一次委託先）、７００ Ｗｅｂブラウザ（二次委託先）。

Claims (3)

1. 認証装置と中間装置とを有し、
   前記認証装置は、
   文書管理装置に保持された電子文書について第１ユーザが第２ユーザに付与したアクセス権の委譲先として許可可能なユーザが満たすべき許可条件であって前記第１ユーザが指定した許可条件、を記憶する許可条件記憶手段と、
   前記第２ユーザに一次トークンを発行する一次トークン発行手段と、
   第３ユーザから前記一次トークンを含んだ委譲要求を受けた場合に、前記第３ユーザが前記許可条件を満たすならば前記第３ユーザに二次トークンを発行する二次トークン発行手段と、
   前記文書管理装置から前記二次トークンの検証依頼を受けた場合に、前記二次トークンに対応する前記一次トークンに対応する前記第２ユーザの前記電子文書へのアクセス権の範囲内で定められた前記第３ユーザのアクセス権に基づき、前記第３ユーザの前記電子文書に対するアクセス可否を検証する検証手段と、
   を有し、
   前記中間装置は、
   前記第３ユーザから前記二次トークンと共に前記電子文書に対するアクセス要求を受け取った場合に、前記アクセス要求を前記二次トークンと共に前記文書管理装置に転送する転送手段、
   を有することを特徴とするアクセス制御システム。
2. 前記中間装置は、
   前記第３ユーザの端末装置から前記一次トークンを受け取った場合に、セッションＩＤを発行し、前記セッションＩＤと前記一次トークンとの組合せをセッション記憶手段に記憶し、前記セッションＩＤと前記一次トークンとを前記端末装置に記憶させ、前記端末装置に対して前記認証装置の前記二次トークン発行手段から二次トークンの発行を受けるよう指示する指示手段と、
   前記指示に従って前記二次トークン発行手段から二次トークンの発行を受けた前記端末装置から前記二次トークンを受け取るとともに、前記端末装置からセッションＩＤと一次トークンとを受け取り、受け取ったセッションＩＤと一次トークンが前記セッション記憶手段に記憶された前記組合せに合致する場合に、受け取った前記二次トークンを前記セッション記憶手段内の前記組合せに登録する二次トークン登録手段と、
   前記端末装置から前記電子文書へのアクセス要求を受け取った場合に、前記端末装置から送信される前記二次トークン及び前記セッションＩＤが前記セッション記憶手段に記憶された前記組合せに合致すれば、前記アクセス要求を前記二次トークンと共に前記文書管理装置に転送する転送手段と、
   を有する請求項１に記載のアクセス制御システム。
3. コンピュータを、
   文書管理装置に保持された電子文書について第１ユーザが第２ユーザに付与したアクセス権の委譲先として許可可能なユーザが満たすべき許可条件であって前記第１ユーザが指定した許可条件、を記憶する許可条件記憶手段と、
   前記第２ユーザに一次トークンを発行する一次トークン発行手段、
   第３ユーザから前記一次トークンを伴うアクセス権委譲要求を受けた場合に、前記第３ユーザが前記許可条件を満たすならば前記第３ユーザに二次トークンを発行する二次トークン発行手段、
   前記第３ユーザから前記二次トークンと共に前記電子文書に対するアクセス要求を受け取った場合に、前記アクセス要求を前記二次トークンと共に前記文書管理装置に転送する転送手段、
   前記文書管理装置から、前記二次トークンの検証依頼を受けた場合に、前記二次トークンに対応する前記一次トークンに対応する前記第２ユーザの前記電子文書へのアクセス権の範囲内の前記第３ユーザの前記電子文書へのアクセス権に基づき、前記第３ユーザの前記電子文書に対するアクセス可否を検証する検証手段、
   として機能させるためのプログラム。
   

Images