JP4757687B2 - 認証認可サーバ、認証認可システム、認証認可方法及び認証認可プログラム - Google Patents

Description

この発明は、例えば、ユーザが複数の企業に跨って権限をもち、かつ、複数の企業を跨ってシステムを利用する際に、各企業のシステムに対して各企業における職務または権限によりアクセス制御を行う技術に関するものである。

企業では、さまざまなシステムをさまざまなユーザが使用するために厳密なアクセス制御が必要である。また、近年、利用者が企業グループ内など複数の企業に跨って職務をもつことがある。この場合、企業内だけでなく、複数の企業に跨がってシステムを利用する必要がある。しかし、業種によっては、同時に複数の企業に跨った職務を実施することが法令などにより禁止されている場合がある。そのため、このような場合に各企業のシステム毎に操作端末を異なる部屋に設置するなどの運用で対策がとられている。しかし、利用者の利便性は著しく低い。そこで、複数の企業のシステムへの認証認可を統合して行う仕組が必要である。

Ｗｅｂクライアント／サーバ型のシステムにおいて、複数システムの認証及び認可を統合して行う認証認可サーバが存在する。この認証認可サーバでは、１つの認証リポジトリのみを参照し、認証認可を行う。ここで認証リポジトリとは、認証情報を有するサーバ、データベースなどである。
また、分散した拠点において拠点毎にアクセス制御を行う装置を置くことにより、ローカル拠点だけではなく分散拠点からのアクセスに対してアクセス制御を行い、一定の操作権限を与えるものがある。
また、特開２０００−１４８７３７号公報では、ネットワークを介して分散管理された各電子文書に対して、関与者情報等を含んだコミュニケーション情報を持たせる。そして、分散管理されたコミュニケーション情報同士をリンクで関連付ける。このコミュニケーション情報を用いることにより、ローカルのユーザのみならず、他の場所のユーザに対してもアクセス制御できる。
特開２０００−１４８７３７号公報

従来の認証認可システムによるアクセス制御では、複数の企業のシステムを使用する場合にはそれぞれの認証認可システムにログインして業務を実施する。そのため、それぞれの企業でユーザ管理も行われており、ユーザ属性情報（ユーザ管理情報）に関連はない。したがって、同時に複数の企業の業務にアクセスすることに対して制御できないという課題がある。
また、企業を跨って職務を有する場合に、ある企業の認証認可サーバから他企業のシステムに接続可能する場合、各企業の認証リポジトリにおいて他社のユーザ属性情報を管理する必要がある。つまり、この場合には、ユーザ属性情報の二重管理が必要となり、セキュリティレベルの低下、運用負荷の増加が発生するという課題がある。
本発明は、例えば、１つの認証認可システムの認証により、複数の企業のシステムへのアクセス制御を行うことを目的とする。また、本発明は、例えば、複数の企業（グループ）に跨って職務（権限）を有し、１つの認証認可サーバから複数の企業のシステムへアクセスする場合にも、ユーザ属性情報を一元管理することを目的とする。

本発明にかかる認証認可サーバは、属性情報と、リンクする認証リポジトリを示すリンク情報とを含むユーザ毎に割当てられたユーザ属性情報を記憶装置に記憶する複数の認証リポジトリから、所定の認証リポジトリを処理装置により検索する認証リポジトリ検索部と、上記認証リポジトリ検索部が検索した認証リポジトリである第１認証リポジトリから所定のユーザのユーザ属性情報を取得して記憶装置に記憶する第１ユーザ属性情報取得部と、上記第１ユーザ属性情報取得部が取得したユーザ属性情報からリンク情報を取得して記憶装置に記憶するリンク情報取得部と、上記リンク情報取得部が取得したリンク情報が示す認証リポジトリである第２認証リポジトリから上記ユーザのユーザ属性情報を取得して記憶装置に記憶する第２ユーザ属性情報取得部と、上記第１認証リポジトリが割当てられたグループである第１グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記第１ユーザ属性情報取得部が取得したユーザ属性情報に基づき処理装置によりアクセス制御を行い、上記第２認証リポジトリが割当てられたグループである第２グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記第２ユーザ属性情報取得部が取得したユーザ属性情報に基づき処理装置によりアクセス制御を行う認証認可処理部と
を備えることを特徴とする。

本発明にかかる認証認可サーバよれば、各認証リポジトリ毎に記憶されたユーザ属性情報に基づき、各グループのサーバへのアクセス制御を行う。また、ユーザ属性情報はリンク情報により、他の認証リポジトリとリンクされている。したがって、１つの認証認可システムの認証により、複数の企業のシステムへのアクセス制御を行うことができる。

以下、図に基づき本発明の実施の形態について説明する。

まず、図１、図２に基づき本発明にかかる認証認可サーバ１００のハードウェア構成の一例について説明する。

図１は、実施の形態にかかる認証認可システム１０００の外観の一例を示した図である。
図１において、認証認可システム１０００は、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）表示装置９０１、キーボード（Ｋ／Ｂ）９０２、マウス９０３、コンパクトディスク装置（ＣＤＤ）９０５、データベース９０８、システムユニット９０９、サーバＡ９１７、サーバＢ９１８を備え、これらはケーブルで接続されている。
さらに、認証認可システム１０００は、ローカルエリアネットワーク（ＬＡＮ）９４２、ゲートウェイ９４１を介してインターネット９４０に接続されている。また、認証認可システム１０００は、インターネット９４０を介して外部サーバ９１６等と接続されている。
ここで、サーバＡ９１７は、後述する認証認可サーバ１００の一例である。また、サーバＢ９１８や外部サーバ９１６は、後述するＷｅｂ系業務などを提供する業務サーバの一例である。さらに、データベース９０８は、認証リポジトリ、ＡＣＬＤＢ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ Ｄａｔａ Ｂａｓｅ）の一例である。また、ＣＲＴ表示装置９０１は表示装置９８６の一例である。

図２は、実施の形態における認証認可サーバ１００のハードウェア構成の一例を示す図である。
図２において、認証認可サーバ１００は、コンピュータであり、プログラムを実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）９１１を備えている。ＣＰＵ９１１は、バス９１２を介してＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、ＣＲＴ表示装置９０１、Ｋ／Ｂ９０２、マウス９０３、ＦＤＤ（Ｆｌｅｘｉｂｌｅ Ｄｉｓｃ）９０４、ＣＤＤ９０５、磁気ディスク装置９２０と接続されている。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、磁気ディスク装置９２０は、不揮発性メモリの一例である。これらは、記憶装置９８４の一例である。
通信ボード９１５は、ＬＡＮ９４２等に接続されている。
また、Ｋ／Ｂ９０２、マウス９０３等は、入力装置９８２の一例である。
また、ＣＰＵ９１１は、処理装置９８０の一例である。
また、通信ボード９１５は、通信装置９８８の一例である。

ここで、通信ボード９１５は、ＬＡＮ９４２に限らず、直接、インターネット９４０、或いはＩＳＤＮ等のＷＡＮ（ワイドエリアネットワーク）に接続されていても構わない。直接、インターネット９４０、或いはＩＳＤＮ等のＷＡＮに接続されている場合、認証認可サーバ１００は、インターネット９４０、或いはＩＳＤＮ等のＷＡＮに接続され、ゲートウェイ９４１は不用となる。
磁気ディスク装置９２０には、オペレーティングシステム（ＯＳ）９２１、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３は、ＣＰＵ９１１、ＯＳ９２１、ウィンドウシステム９２２により実行される。

上記プログラム群９２３には、以下に述べる実施の形態の説明において、例えば、「〜部」として説明する機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
ファイル群９２４には、以下に述べる実施の形態の説明において、「〜判定」として説明するものが、「〜ファイル」として記憶されている。
また、以下に述べる実施の形態の説明において説明するフローチャートの矢印の部分は主としてデータの入出力を示し、そのデータの入出力のためにデータは、磁気ディスク装置９２０、ＦＤ、光ディスク、ＣＤ、ＭＤ（ミニディスク）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のその他の記録媒体に記録される。あるいは、信号線やその他の伝送媒体により伝送される。

また、以下に述べる実施の形態の説明において「〜部」として説明するものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、ハードウェアのみ、或いは、ソフトウェアとハードウェアとの組合せ、さらには、ファームウェアとの組合せで実施されても構わない。

また、以下に述べる実施の形態を実施するプログラムは、また、磁気ディスク装置９２０、ＦＤ、光ディスク、ＣＤ、ＭＤ、ＤＶＤ等のその他の記録媒体による記録装置を用いて記憶されても構わない。

実施の形態１．
次に、実施の形態１について説明する。実施の形態１では、１度の認証のみで複数の企業のシステムへのアクセス制御を行う認証認可システム１０００について説明する。

図３は実施の形態１にかかる認証認可システム１０００の概要構成を示す構成図である。
認証認可システム１０００は、認証認可サーバ１、認証リポジトリＡ２ａ、認証リポジトリＢ２ｂ、ＡＣＬＤＢ３を備える。ここで、認証リポジトリＡ２ａは企業Ａに割当てられた認証リポジトリであり、認証リポジトリＢ２ｂは企業Ｂに割当てられた認証リポジトリである。

認証リポジトリＡ２ａはユーザ情報２ａ−１を記憶し、認証リポジトリＢ２ｂは、ユーザ情報２ｂ−１を記憶する。ユーザ情報２ａ−１とユーザ情報２ｂ−１とは、ユーザＩＤ（識別子）、組織、役職、リンク情報（リンク元、リンク先）を備えるユーザ属性情報を管理する。つまり、認証リポジトリＡ２ａと認証リポジトリＢ２ｂとは、ユーザ毎に、割当てられたユーザ属性情報を記憶する。また、リンク情報には、ここでは、リンク元（先）認証リポジトリ及びユーザＩＤが記憶される。ＡＣＬＤＢ３はアクセス制御リスト３−１を記憶する。アクセス制御リスト３−１は、ＡＣＬ名をキーにして、業務サーバへアクセスする権限を企業、役割（組織、役職）、職務、業務サーバ毎に管理する。
認証認可システム１０００は、クライアント４から企業Ａや企業Ｂの各業務サーバへアクセスがあった場合、認証リポジトリＡ２ａと認証リポジトリＢ２ｂ、ＡＣＬＤＢ３の情報を使用してアクセス制御を行う。

次に、図４、図５、図６に基づき認証認可システム１０００の機能と動作とを説明する。図４は、実施の形態１にかかる認証認可システム１０００の機能を示す機能ブロック図である。
図４において、認証認可システム１０００は、上記と同様に、認証認可サーバ１、認証リポジトリＡ２ａ、認証リポジトリＢ２ｂ、ＡＣＬＤＢ３を備える。また、認証認可サーバ１は、企業Ａの業務サーバＡ−１、業務サーバＡ−２と、企業Ｂの業務サーバＢ−１、業務サーバＢ−２と接続されている。
認証認可サーバ１は、識別情報受信部１０、認証リポジトリ検索部２０、ユーザ属性情報取得部３０、リンク情報取得部４０、権限情報取得部５０、認証認可処理部６０、認証判定部９０、処理装置９８０、記憶装置９８４、通信装置９８８を備える。また、ユーザ属性情報取得部３０は、第１ユーザ属性情報取得部３２、第２ユーザ属性情報取得部３４を備える。

図５は、実施の形態１における認証認可サーバ１の認証処理のフローチャートである。図６は、実施の形態１における認証認可サーバ１の認可処理のフローチャートである。これらは、認証認可サーバ１の認証認可処理（認証認可方法、認証認可プログラム）の一例である。

まず、ユーザによりクライアント４（ユーザ端末の一例）からＷｅｂブラウザなどを使用して、認証認可サーバ１へアクセスされる（Ｓ１：認証認可サーバアクセスステップ）。次に、認証判定部９０は、認証済み情報の有無により認証済か否かを処理装置９８０により判定する（Ｓ２：認証確認ステップ）。認証済であると認証判定部９０が判定した場合（Ｓ２で認証済）、認証判定部９０は（Ｓ５）へ進む。一方、認証済でないと認証判定部９０が判定した場合（Ｓ２で認証前）、認証判定部９０は、例えば図３に示すログイン画面６などを送信する（Ｓ３：識別画面送信ステップ）。ここで、図３に示すようにユーザ認証に使用するログイン画面は、ユーザＩＤ（ＵＩＤ）、パスワード（ＰＷＤ）、企業コードを入力するための欄および入力データを送信するためのＳＵＢＭＩＴボタンを備える。そして、クライアント４の表示装置にログイン画面６が表示される（Ｓ４：識別画面表示ステップ）。ユーザが、ログイン画面６にてユーザを識別するユーザＩＤ（ユーザ識別情報の一例）、パスワード、企業を識別する企業コード（グループ識別情報の一例）を入力し、ＳＵＢＭＩＴボタンを押下する（Ｓ５：識別情報入力ステップ）。すると、認証認可サーバ１へユーザが入力した情報が送信される（Ｓ６：識別情報送信ステップ）。ここでは、ユーザはユーザＩＤとして「ユーザＡ」、企業コードとして「Ａ」を入力したとする。

認証認可サーバ１の識別情報受信部１０は、ユーザが送信したユーザＩＤ、パスワード、企業コードを、通信装置９８８を介して受信する（Ｓ７：識別情報受信ステップ）。そして、認証リポジトリ検索部２０は、企業コードから認証に使用する認証リポジトリを検索して決定する（Ｓ８：認証リポジトリ検索ステップ）。ここでは企業Ａ（第１グループの一例）に割当てられた「認証リポジトリＡ２ａ」（第１認証リポジトリの一例）に決定される。次に、認証判定部９０は、認証リポジトリ検索部２０が決定した認証リポジトリに対して、ユーザＩＤ、パスワードを使用して、認証リクエストを送信する（Ｓ９：認証リクエスト送信ステップ）。認証判定部９０は、認証リポジトリからの応答に基づき認証するか否かを処理装置９８０により判定する（Ｓ１０：認証判定ステップ）。認証判定部９０が認証しない場合（Ｓ１０で失敗）、認証判定部９０は（Ｓ３）へ戻る。一方、認証判定部９０が認証した場合（Ｓ１０で成功）、認証判定部９０は認証済情報を作成する（Ｓ１１：認証済情報作成ステップ）。そして、第１ユーザ属性情報取得部３２は、認証リポジトリＡ２ａから該当のユーザのユーザ属性情報（組織、役職）を取得し、組織、役職情報を認証済情報に主職務として格納する（Ｓ１２：第１ユーザ属性情報取得ステップ）。ここでは、第１ユーザ属性情報取得部３２は、企業Ａ、総務、課長を主職務として記憶装置９８４に記憶する。次に、リンク情報取得部４０は、第１ユーザ属性情報取得部３２が取得したユーザ属性情報のリンク情報に値が設定されているか処理装置９８０によりチェックする（Ｓ１３：リンク情報判定ステップ）。リンク情報がないとリンク情報取得部４０が判定した場合（Ｓ１３でなし）、リンク情報取得部４０は（Ｓ１６）へ進む。一方、リンク情報があるとリンク情報取得部４０が判定した場合（Ｓ１３であり）、リンク情報取得部４０はＡＣＬＤＢ３から取得したユーザ属性情報に含まれるリンク情報を取得する。（Ｓ１４：リンク情報取得ステップ）。そして、第２ユーザ属性情報取得部３４は、リンク先およびリンク元の認証リポジトリからユーザ属性情報（組織、役職）を取得して、上述の認証済み情報に副職務として記憶装置９８４に格納する（Ｓ１５：第２ユーザ属性情報取得ステップ）。ここでは、リンク先情報として「認証リポジトリＢのユーザＡ’」を記憶している。そのため、第２ユーザ属性情報取得部３４は、認証リポジトリＢ（第２認証リポジトリの一例）のユーザＡ’のユーザ属性情報を取得する。つまり、第２ユーザ属性情報取得部３４は、企業Ｂ（第２グループの一例）、経理、担当を副職務として記憶する。（Ｓ１３）から（Ｓ１５）までの処理をリンク先とリンク元とのユーザ属性情報をすべて取得するまで繰り返す。そして、認証認可サーバ１は認証完了する（Ｓ１６：認証完了ステップ）。

そして、認証が完了したユーザがクライアント４から、認証認可サーバ１経由で、業務サーバへアクセスする（Ｓ１９：サーバアクセス認証ステップ）。次に、権限情報取得部５０は、ＡＣＬＤＢ３からアクセス先の業務サーバに関するＡＣＬ（権限情報）を取得して記憶装置９８４に記憶する（Ｓ２０：権限情報取得ステップ）。そして、認証認可処理部６０は、主務職と権限情報取得部５０が取得したＡＣＬとを処理装置９８０により比較する（Ｓ２１：第１権限情報比較ステップ（認証認可処理ステップ））。認証認可処理部６０が主職務と一致すると判定した場合（Ｓ２１で一致）、認証認可処理部６０は（Ｓ２４）へ進む。一方、認証認可処理部６０が主職務と一致しないと判定した場合（Ｓ２１で不一致）、認証認可処理部６０は副職務の有無を処理装置９８０によりチェックする（Ｓ２２：第２権限情報判定ステップ）。副職務がないと認証認可処理部６０が判定した場合（Ｓ２２でなし）、認証認可処理部６０はクライアントへアクセス不可通知を、通信装置９８８を介して送信して処理を終了する（Ｓ２６：認証失敗通知ステップ）。一方、副職務があると認証認可処理部６０が判定した場合（Ｓ２２であり）、認証認可処理部６０は副職務とＡＣＬとを処理装置９８０により比較する（Ｓ２３：第２権限情報比較ステップ（認証認可処理ステップ））。副職務と一致すると認証認可処理部６０が判定した場合（Ｓ２３で一致）、ＡＣＬＤＢ３のアクセス制御リスト３−１に従い、処理装置９８０により権限を設定する（Ｓ２４：アクセス権限設定ステップ（認証認可処理ステップ））。一方、副職務と一致しないと認証認可処理部６０が判定した場合（Ｓ２３で不一致）、認証認可処理部６０は（Ｓ２２）へ戻り、他に副職務があるかをチェックする。（Ｓ２４）にて権限を設定された場合、設定された権限に基づき業務サーバへアクセスする（Ｓ２５：サーバアクセスステップ）。

ここで、まず、ユーザＡが企業Ａの業務サーバＡ−１にアクセスするものとする（Ｓ１９）。すると、ユーザＡの現在の主職務は（企業Ａ、総務、課長）であるため、ＡＣＬＤＢ３のアクセス制御リスト３−１のＡＣＬ−Ａ１に一致し（Ｓ２１で一致））、権限は「読み書き」可能となる（Ｓ２４）。
一方、ユーザＡが企業Ｂの業務サーバＢ−１にアクセスするとする（Ｓ１９）。すると、ユーザＡの現在の主職務は（企業Ａ、総務、課長）であるため、主職務と一致するＡＣＬＤＢ３のアクセス制御リスト３−１の権限情報はない（Ｓ２１で不一致）。次に、ユーザＡの副職務の有無をチェックするが（Ｓ２２）、ユーザＡには副職務が存在する（Ｓ２２であり）。そして、ユーザＡの副職務は（企業Ｂ、経理、担当）であるため、ＡＣＬＤＢ３のアクセス制御リスト３−１のＡＣＬ−Ｂ２と一致し（Ｓ２３で一致）、権限は「読み」のみ可能となる（Ｓ２４）。

また、ユーザＡが、企業Ａの業務サーバＡ−２にアクセスする場合、上記業務サーバＡ−１にアクセスした際と同様の処理を辿る。つまり、ユーザＡの主職務は（企業Ａ、総務、課長）であるため、ＡＣＬＤＢ３のアクセス制御リスト３−１のＡＣＬ−Ａ３にしたがい、権限は「読み」のみ可能となる。
一方、ユーザＡが、企業Ｂの業務サーバＢ−２にアクセスすると、ユーザＡの主職務と一致するＡＣＬＤＢ３のアクセス制御リスト３−１の権限情報はなく、またユーザＡの副職務と一致するＡＣＬＤＢ３のアクセス制御リスト３−１の権限情報はないため、権限はなく、アクセス不可をクライアントに通知する（Ｓ２６）。

つまり、認証認可処理部６０は、ユーザによりログイン時などに選択された企業Ａ（第１グループの一例）のサーバへのクライアント４からのアクセスに対しては、企業Ａに割当てられた認証リポジトリＡ２ａ（第１認証リポジトリの一例）から取得したユーザ属性情報（第１ユーザ属性情報取得部３２が取得したユーザ属性情報）に基づき処理装置９８０によりアクセス制御を行う。一方、企業Ｂ（第２グループの一例）のサーバへのクライアント４からのアクセスに対しては、企業Ｂに割当てられた認証リポジトリＢ２ｂ（第２認証リポジトリの一例）から取得したユーザ属性情報（第２ユーザ属性情報取得部３４が取得したユーザ属性情報）に基づき処理装置９８０によりアクセス制御を行う。
また、権限情報取得部５０は、企業Ａのサーバへのクライアント４からのアクセスに対しては、主職務（第１レベルの一例）に割当てられたＡＣＬを認証リポジトリＡ２ａから取得したユーザ属性情報に基づき取得し、認証認可処理部６０は、権限情報取得部５０が取得したＡＣＬ（第１権限情報の一例）に基づきアクセス制御を行う。一方、権限情報取得部５０は、企業Ｂのサーバへのクライアント４からのアクセスに対しては、副職務（第２レベルの一例）に割当てられたＡＣＬを認証リポジトリＢ２ｂから取得したユーザ属性情報に基づき取得し、認証認可処理部６０は、権限情報取得部５０が取得したＡＣＬ（第２権限情報の一例）に基づきアクセス制御を行う。

次に、ユーザＡがログイン画面６で企業Ｂを入力したときの動作を示す。基本的な流れは上記と同様である。
まず、ユーザによりクライアント４からＷｅｂブラウザなどを使用して、認証認可サーバ１にアクセスされる（Ｓ１）。認証前の場合、クライアント４の表示装置にログイン画面６が表示される（Ｓ４）。ユーザＡが、ログイン画面にてユーザＩＤ、パスワード、企業コードを入力し、ＳＵＢＭＩＴボタンを押下すると（Ｓ５）、認証認可サーバ１に入力した情報が送信される。ここでは、ユーザはユーザＩＤとして「ユーザＡ’」、企業コードとして「Ｂ」を入力したとする。

識別情報受信部１０は、ユーザＡが送信したユーザＩＤ、パスワード、企業コードを受け取り（Ｓ７）、認証リポジトリ検索部２０は、企業コードから認証に使用する認証リポジトリを決定する（Ｓ８）。ここでは、企業Ｂ（第１グループの一例）に割当てられた「認証リポジトリＢ２ｂ」（第１認証リポジトリの一例）に決定される。認証判定部９０は、決定した認証リポジトリに対して、ユーザＩＤ、パスワードを使用して、認証処理を実施する（Ｓ９、Ｓ１０）。認証に成功した場合（Ｓ１０で成功）、認証判定部９０は、認証済み情報を作成し（Ｓ１１）、第１ユーザ属性情報取得部３２は、該当のユーザ情報の属性（組織、役職）を取得する（Ｓ１２）。第１ユーザ属性情報取得部３２は、組織、役職は認証済情報に主職務として格納する。ここでは、第１ユーザ属性情報取得部３２は、企業Ｂ、経理、担当を主職務として記憶する。リンク情報取得部４０は、取得したリンク情報属性に値が設定されているかチェックし（Ｓ１３）、リンク情報があった場合（Ｓ１３であり）、リンク情報取得部４０はリンク情報を取得する（Ｓ１４）。そして、第２ユーザ属性情報取得部３４は、リンク先およびリンク元の属性情報も取得する。取得した役職（組織、役職）と上述の認証済み情報に副職務として格納する（Ｓ１５）。ここでは、リンク先情報として「認証リポジトリＡのユーザＡ」を記憶している。そのため、第２ユーザ属性情報取得部３４は、認証リポジトリＡ（第２認証リポジトリの一例）のユーザＡのユーザ属性情報を取得する。つまり、第２ユーザ属性情報取得部３４は、企業Ａ（第２グループの一例）、総務、課長を副職務として記憶する。

認証が完了したユーザＡが、企業Ａの業務サーバＡ−１にアクセスすると（Ｓ１９）、ユーザＡの主職務は（企業Ｂ、経理、担当）であるため、主職務と一致するＡＣＬＤＢ３のアクセス制御リスト３−１の権限情報はない（Ｓ２１で不一致）。次に、ユーザＡの副職務の有無をチェックするが（Ｓ２２）、ユーザＡには副職務が存在する（Ｓ２２であり）。そして、ユーザＡの現在の副職務は（企業Ａ、総務、課長）であるため、ＡＣＬＤＢ３のアクセス制御リスト３−１のＡＣＬ−Ａ２にしたがい、権限は「読み」のみ可能となる。
一方企業Ｂの業務サーバＢ−１にアクセスすると、ユーザＡの主職務は（企業Ｂ、経理、担当）であるため、ＡＣＬＤＢ３のアクセス制御リスト３−１のＡＣＬ−Ｂ１にしたがい、権限は「読み書き」可能となる。
また、ユーザＡが、企業Ａの業務サーバＡ−２にアクセスすると、ユーザＡの主職務と一致するＡＣＬＤＢ３のアクセス制御リスト３−１の権限情報はなく、またユーザＡの副職務と一致するＡＣＬＤＢ３のアクセス制御リスト３−１の権限情報はないため、権限はなく、アクセス不可をクライアントに通知する。
一方企業Ｂの業務サーバＢ−２にアクセスすると、ユーザＡの主職務は（企業Ｂ、経理、担当）であるため、ＡＣＬＤＢ３のアクセス制御リスト３−１のＡＣＬ−Ｂ３にしたがい、権限は「読み」のみ可能となる。

以上のように、実施の形態１にかかる認証認可システム１０００によれば、同一の業務サーバにアクセスする際に、システム利用時の職務に応じてアクセス権限を変えることにより、厳密なアクセス制御が可能である。また、ユーザの属性情報をリンクにより取り出し可能とすることで、ユーザ属性情報を企業ごとで分割することが可能となる。そのため、アクセス制御のためのユーザ属性情報の二重管理をする必要がない。したがって、二重管理による管理負荷増および、セキュリティ低下を防止することができる。

つまり、実施の形態１にかかる認証認可システム１０００は、企業ごとに認証リポジトリを分割管理している認証認可サーバ１において、企業を跨った同一ユーザ間にリンクを持つ認証リポジトリを備え、認証時にリンク情報をもとに複数企業における属性情報を認証情報として保持し、認証情報に記録されているユーザの属性情報を利用して、アクセス制御を行うことを特徴とする。

また、実施の形態１にかかる認証認可システム１０００は、各企業の認証リポジトリの同一ユーザのデータ（エントリ）間にリンクを設定し、認証時にリンクにより収集した属性情報をもとに認証認可サーバ１が、利用ユーザの利用時の職務により、厳密なアクセス制御を行う。

実施の形態２．
次に実施の形態２について説明する。実施の形態１では、認証認可サーバ１が単一であるときの認証認可方式を示した。実施の形態２では、認証認可サーバ１が複数ある場合の認証及びアクセス制御を行う認証認可システム１０００について説明する。

図７は実施の形態２にかかる認証認可システム１０００の概要構成を示す構成図である。実施の形態１の構成と異なり、認証認可サーバ１が同じドメインである認証認可サーバＡ１ａと認証認可サーバＢ１ｂとの２つある。それにともない認証リポジトリ２も、認証認可サーバＡ１ａが割当てられた企業Ａに割当てられた認証リポジトリＡ２ａと認証認可サーバＢ１ｂが割当てられた企業Ｂに割当てられた認証リポジトリＢ２ｂとの２つある。また、ＡＣＬＤＢ３も企業Ａに割当てられたＡＣＬＤＢ−Ａ３ａと企業Ｂに割当てられたＡＣＬＤＢ−Ｂ３ｂとの２つある。その他は、実施の形態１の構成と同様である。

次に、図８、図９、図６に基づき認証認可システム１０００の機能と動作とを説明する。図８は、実施の形態２にかかる認証認可システム１０００の機能を示す機能ブロック図である。ここで、ユーザは、初めに認証認可サーバＡ１ａへアクセスするものとする。そのため認証認可サーバＡ１ａは第１認証認可サーバの一例であり、認証認可サーバＢ１ｂは第２認証認可サーバの一例である。また、認証リポジトリＡ２ａは第１認証リポジトリの一例であり、認証リポジトリＢ２ｂは第２認証リポジトリの一例である。さらに、ＡＣＬＤＢ−Ａ３ａは第１ＡＣＬＤＢの一例であり、ＡＣＬＤＢ−Ｂ３ｂは第２ＡＣＬＤＢの一例である。
図８において、認証認可システム１０００は、認証認可サーバＡ１ａ、認証認可サーバＢ１ｂ、認証リポジトリＡ２ａ、認証リポジトリＢ２ｂ、ＡＣＬＤＢ−Ａ３ａ、ＡＣＬＤＢ−Ｂ３ｂを備える。また、認証認可サーバＡ１ａは、企業Ａ（第１グループの一例）の業務サーバＡ−１、業務サーバＡ−２と接続されている。さらに、認証認可サーバＢ１ｂは、企業Ｂ（第２グループの一例）の業務サーバＢ−１、業務サーバＢ−２と接続されている。
認証認可サーバＡ１ａは、識別情報受信部１０、認証リポジトリ検索部２０、ユーザ属性情報取得部３０、リンク情報取得部４０、第１権限情報取得部５２、第１認証認可処理部６２、認証判定部９０、処理装置９８０Ａ、記憶装置９８４Ａ、通信装置９８８Ａを備える。また、ユーザ属性情報取得部３０は、第１ユーザ属性情報取得部３２、第２ユーザ属性情報取得部３４を備える。
認証認可サーバＢ１ｂは、第２権限情報取得部５４、第２認証認可処理部６４、処理装置９８０Ｂ、記憶装置９８４Ｂ、通信装置９８８Ｂを備える。

図９は、実施の形態２における認証認可サーバＡ１ａ、認証認可サーバＢ１ｂの認証処理のフローチャートである。実施の形態２における認証認可サーバＡ１ａ、認証認可サーバＢ１ｂの認可処理は図６に示す処理と同様である。これらは、認証認可システムの認証認可処理（認証認可方法、認証認可プログラム）の一例である。

まずユーザによりクライアント４から、認証認可サーバＡ１ａへアクセスされる。（Ｓ１）。（Ｓ２）から（Ｓ４）までは、実施の形態１と同様である。但し、（Ｓ２で認証済）の場合、（Ｓ５−１）へ進む。また、（Ｓ３）では、ログイン画面６−１を送信する。（Ｓ５−１：識別情報入力ステップ）では、ユーザが、ログイン画面６−１にてユーザを識別するユーザＩＤ（ユーザ識別情報の一例）、パスワードのみを入力し、ＳＵＢＭＩＴボタンを押下する。すると、認証認可サーバ１へユーザが入力した情報が送信される（Ｓ６−１：識別情報送信ステップ）。ここでは、ユーザはユーザＩＤとして「ユーザＡ」を入力したとする。

（Ｓ７−１：識別情報受信ステップ）では、認証認可サーバＡ１ａの識別情報受信部１０は、ユーザＡが送信したユーザＩＤ、パスワードを、通信装置９８８Ａを介して受信する。（Ｓ８−１：認証リポジトリ検索ステップ）では、認証リポジトリ検索部２０は、認証に使用する認証リポジトリを決定する。認証リポジトリ検索部２０は、ユーザによりクライアントから認証認可サーバＡ１ａにアクセスされているため、使用する認証リポジトリは認証認可サーバＡ１ａが割当てられた企業Ａに割当てられた「認証リポジトリＡ２ａ」に決定される。（Ｓ９）から（Ｓ１６）までは、実施の形態１と同様である。
ここで、認証認可サーバＡ１ａによって作成された認証情報は、例えばクライアントが記憶する。そして、クライアントが同じドメインにある認証認可サーバＢ１ｂにアクセスする場合、クライアントから認証認可サーバＢ１ｂへ認証情報が送信され、認証認可サーバＢ１ｂは、（Ｓ２）の処理において認証済と判断される。つまり、同じドメイン内の認証認可サーバ１が作成した認証情報を他の認証認可サーバ１でも信頼する。

（Ｓ１９）で、（Ｓ１６）までの処理で認証が完了したユーザが、認証認可サーバＡ１ａ経由で、企業Ａの業務サーバへアクセスするものとする。この場合、（Ｓ２０）では、第１権限情報取得部５２は、アクセスする業務サーバが割当てられた企業Ａに割当てられたＡＣＬＤＢ−Ａ３ａからアクセス先の業務サーバに関するＡＣＬ（権限情報）を取得する。そして、（Ｓ２１）では、第１認証認可処理部６２は、主務職と第１権限情報取得部５２が取得したＡＣＬとを比較する。（Ｓ２２）から（Ｓ２６）までの処理は、実施の形態１と同様である。但し、権限情報取得部５０が行う処理を第１権限情報取得部５２が行い、認証認可処理部６０２が行う処理を第１認証認可処理部６２が行う点で異なる。

一方、（Ｓ１９）で、（Ｓ１６）までの処理で認証が完了したユーザが、認証認可サーバＢ１ｂ経由で、企業Ｂの業務サーバへアクセスするものとする。この場合、（Ｓ２０）では、第２権限情報取得部５４は、ＡＣＬＤＢ−Ｂ３ｂからアクセス先の業務サーバに関するＡＣＬ（権限情報）を取得する。そして、（Ｓ２１）では、第２認証認可処理部６４は、主務職と第２権限情報取得部５４が取得したＡＣＬとを比較する。（Ｓ２２）から（Ｓ２６）までの処理は、実施の形態１と同様である。但し、権限情報取得部５０が行う処理を第２権限情報取得部５４が行い、認証認可処理部６０が行う処理を第２認証認可処理部６４が行う点で異なる。

ここで、ユーザＡが認証認可サーバＡ１ａ経由で、企業Ａの業務サーバＡ−１にアクセスするものとする（Ｓ１９）。ユーザＡの現在の主職務は（企業Ａ、総務、課長）であるため、ＡＣＬＤＢ−Ａ３ａのアクセス制御リスト３ａ−１のＡＣＬ−Ａ１に一致し、権限は「読み書き」可能となる（Ｓ２４）。
一方、ユーザＡが認証認可サーバＢ１ｂ経由で、企業Ｂの業務サーバＢ−１にアクセスするとする（Ｓ１９）。すると、ユーザＡの現在の主職務は（企業Ａ、総務、課長）であるため、主職務と一致するＡＣＬＤＢ−Ｂ３ｂのアクセス制御リスト３ｂ−１の権限情報はない（Ｓ２１で不一致）。次に、ユーザＡの副職務の有無をチェックするが（Ｓ２２）、ユーザＡには副職務が存在する（Ｓ２２であり）。そして、ユーザＡの副職務は（企業Ｂ、経理、担当）であるため、ＡＣＬＤＢ−Ｂ３ｂのアクセス制御リスト３ｂ−１のＡＣＬ−Ｂ２一致し（Ｓ２３で一致）、権限は「読み」のみ可能となる（Ｓ２４）。

また、ユーザＡが、認証認可サーバＡ１ａ経由で、企業Ａの業務サーバＡ−２にアクセスする場合、上記業務サーバＡ−１にアクセスした際と同様の処理を辿る。つまり、ユーザＡの主職務は（企業Ａ、総務、課長）であるため、ＡＣＬＤＢ−Ａ３ａのアクセス制御リスト３ａ−１のＡＣＬ−Ａ３にしたがい、権限は「読み」のみ可能となる。
一方、ユーザＡが、認証認可サーバＢ１ｂ経由で、企業Ｂの業務サーバＢ−２にアクセスすると、ユーザＡの主職務と一致するＡＣＬＤＢ−Ｂ３ｂのアクセス制御リスト３ｂ−１の権限情報はなく、またユーザＡの副職務と一致するＡＣＬＤＢ−Ｂ３ｂのアクセス制御リスト３ｂ−１の権限情報はないため、権限はなく、アクセス不可をクライアントに通知する（Ｓ２６）。

つまり、第１認証認可処理部６２は、ユーザにより選択された企業Ａ（第１グループの一例）のサーバへのクライアント４からのアクセスに対しては、企業Ａに割当てられた認証リポジトリＡ２ａから取得したユーザ属性情報に基づき処理装置９８０によりアクセス制御を行う。一方、第２認証認可処理部６４は、企業Ｂ（第２グループの一例）のサーバへのクライアント４からのアクセスに対しては、企業Ｂに割当てられた認証リポジトリＢ２ｂから取得したユーザ属性情報に基づき処理装置９８０によりアクセス制御を行う。
また、第１権限情報取得部５２は、企業Ａのサーバへのクライアント４からのアクセスに対しては、企業Ａに割当てられたＡＣＬＤＢ−Ａ（第１ＡＣＬＤＢの一例）から主職務（第１レベルの一例）に割当てられたＡＣＬを認証リポジトリＡ２ａから取得したユーザ属性情報に基づき取得し、第１認証認可処理部６２は、第１権限情報取得部５２が取得したＡＣＬ（第１権限情報の一例）に基づきアクセス制御を行う。一方、第２権限情報取得部５４は、企業Ｂのサーバへのクライアント４からのアクセスに対しては、企業Ｂに割当てられたＡＣＬＤＢ−Ｂ（第２ＡＣＬＤＢの一例）から副職務（第２レベルの一例）に割当てられたＡＣＬを認証リポジトリＢ２ｂから取得したユーザ属性情報に基づき取得し、第２認証認可処理部６２４は、第２権限情報取得部５４が取得したＡＣＬ（第２権限情報の一例）に基づきアクセス制御を行う。

以上のように、実施の形態２にかかる認証認可システム１０００によれば、認証認可サーバ１が複数台存在する場合でも、認証認可サーバ１が単一の場合と同様に、システム利用時の職務に応じてアクセス権限を変えることにより、厳密なアクセス制御が可能である。

また、上記では、認証認可サーバが同じドメイン内である場合にシングルサインオン可能とした。しかし、これに限られず、所定のサーバが作成した認証情報のみ信頼するなどとしても構わない。認証認可サーバ１が同一ドメインでない場合のシングルサインオンにはＳＡＭＬ（Ｓｅｃｕｒｉｔｙ Ａｓｓｅｒｔｉｏｎ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を利用することで実現可能である。

つまり、実施の形態２にかかる認証認可システム１０００は、認証認可サーバ１を複数の異なる筐体に備え、異なるサーバ間においてもシングルサインオンおよびユーザ間のリンクから属性情報を取得してアクセス制御を行うことを特徴とする。

実施の形態３．
次に実施の形態３について説明する。実施の形態１では、認証認可サーバ１が各業務サーバへの要求を中継するリバースプロキシ方式であるときの認証認可方式を示した。実施の形態３では、認証認可サーバ１が各業務サーバのエージェントから要求を受けるエージェント方式である場合の認証及びアクセス制御について説明する。

図１０は実施の形態３にかかる認証認可システム１０００の概要構成を示す構成図である。各業務サーバ（業務サーバ５Ａ−１、業務サーバ５Ａ−２、業務サーバ５Ｂ−１、業務サーバ５Ｂ−２）では、認証認可エージェント７が動作する。また、上記各業務サーバは同じドメインにあるものとする。その他は、実施の形態１の構成と同様である。

次に、図１１、図１２、図１３に基づき認証認可システム１０００の機能と動作とを説明する。図１１は、実施の形態３にかかる認証認可システム１０００の機能を示す機能ブロック図である。
実施の形態３にかかる認証認可システム１０００は、クライアントから認証認可サーバ１へのアクセスを各業務サーバ経由で受ける。その他は、実施の形態１と同様である。

図１２は、実施の形態３における認証認可サーバ１の認証処理のフローチャートである。図１３は、実施の形態３における認証認可サーバ１の認可処理のフローチャートである。これらは、認証認可システム１０００及び認証認可サーバ１の認証認可処理（認証認可方法、認証認可プログラム）の一例である。

まず、（Ｓ１−１：認証認可サーバアクセスステップ）では、ユーザによりクライアント４からＷｅｂブラウザなどを使用して、業務サーバへアクセスする。次に、（Ｓ２−１：認証確認ステップ）では、業務サーバの認証認可エージェント７は認証済み情報の有無により認証済みかどうかをチェックする。認証済であると認証認可エージェント７が判定した場合（Ｓ２で認証済）、認証認可エージェント７は（Ｓ５−１）へ進む。一方、認証済でないと認証認可エージェント７が判定した場合（Ｓ２で認証前）、認証認可エージェント７は、例えば図９に示すログイン画面６−１などを送信する（Ｓ３−１：識別画面送信ステップ）。（Ｓ４）は実施の形態１と同様である。（Ｓ５−１：識別情報入力ステップ）では、ユーザが、ログイン画面６にてユーザを識別するユーザＩＤ（ユーザ識別情報の一例）、パスワードのみを入力し、ＳＵＢＭＩＴボタンを押下する。（Ｓ６−１：識別情報送信ステップ）では、業務サーバへ入力した情報が送信される。ここでは、ユーザはユーザＩＤとして「ユーザＡ」を入力したとする。

業務サーバの認証認可エージェント７はユーザが送信したユーザＩＤ、パスワードを受信し、企業コード（グループ識別情報）を決定する。ここでは、業務サーバが割当てられた企業の企業コードとする（Ｓ２８：グループ識別情報検索ステップ）。そして、認証認可エージェント７は、認証認可サーバ１へ決定した企業コードを付加して送信する（Ｓ２９：識別情報転送ステップ）。
次に、認証認可サーバ１の識別情報受信部１０は、認証認可エージェント７が送信したユーザＩＤ、パスワード、企業コードを、通信装置９８８を介して受信する（Ｓ７−１：識別情報受信ステップ）。ここでは、ユーザは業務サーバＡ−１へアクセスしたものとする。したがって、最初にアクセスした業務サーバが業務サーバＡ−１のため、企業コードは「Ａ」となる。（Ｓ８）から（Ｓ１６）までは、実施の形態１と同様である。認証認可サーバ１が作成した認証情報は、例えばクライアントが記憶する。そして、クライアントが同じドメインにある他の業務サーバへアクセスする場合、クライアントから業務サーバに送信され、認証認可エージェント７は、（Ｓ２）の処理において認証済みと判断する。つまり、同じドメイン内の業務サーバから送信された情報に基づいて作成された認証情報を他の業務サーバでも信頼する。

（Ｓ１９−１：サーバアクセス認証ステップ）では、認証が完了したユーザが業務サーバへアクセスする。ユーザが業務サーバへアクセスする場合に、例えば、ＨＴＴＰリクエストなどのリクエスト情報をクライアントからサーバへ送信する。ここでは、上述したように業務サーバＡ−１へアクセスする。そして、業務サーバの認証認可エージェント７は、リクエスト情報を受付け、認証認可サーバ１へリクエスト情報を送信する（Ｓ３０：認証リクエスト送信ステップ）。（Ｓ２０）から（Ｓ２６）までは、実施の形態１と同様である。

以上のように、実施の形態３にかかる認証認可システム１０００によれば、認証認可サーバ１がエージェント方式の場合でも、認証認可サーバ１がリバースプロキシ方式である場合と同様に、システム利用時の職務に応じてアクセス権限を変えることにより、厳密なアクセス制御が可能である。

つまり、実施の形態３にかかる認証認可システム１０００は、ユーザからの直接アクセスのみならず、業務サーバからのリダレクトアクセスにより認証及び認可を実施することを特徴とする。

実施の形態４．
次に実施の形態４について説明する。実施の形態３では、認証認可サーバ１がエージェント方式かつ認証認可サーバ１が単一である場合の認証認可方式を示した。実施の形態４では、認証認可サーバ１がエージェント方式かつ認証認可サーバ１が複数台である場合の認証及びアクセス制御について説明する。

図１４は実施の形態４にかかる認証認可システム１０００の概要構成を示す構成図である。企業Ａの業務サーバ５Ａ−１と業務サーバ５Ａ−２とで認証認可エージェントＡ７ａが動作し、企業Ｂの業務サーバ５Ｂ−１と業務サーバ５Ｂ−２とで認証認可エージェントＢ７ｂが動作する。各業務サーバ（業務サーバ５Ａ−１、業務サーバ５Ａ−２、業務サーバ５Ｂ−１、業務サーバ５Ｂ−２）は同じドメインである。その他は、実施の形態２の構成と同様である。

実施の形態４にかかる認証認可システム１０００の機能ブロック図は、クライアントからのアクセスを各業務サーバ経由で受けることを除き、実施の形態１と同様である。
また、実施の形態４における認証処理及び認可処理は実施の形態２および実施の形態３を組み合わせた処理となる。つまり、認証処理については、図９に示す実施の形態２にかかる認証処理の（Ｓ２）、（Ｓ３）、（Ｓ６）を、図１２に示す実施の形態３にかかる認証処理の（Ｓ２−１）、（Ｓ３−１）、（Ｓ６−１）に置き換える。また、（Ｓ６−１）の次に、（Ｓ２８）と（Ｓ２９）とを実行する。また、認可処理については、図１３に示す実施の形態３の認可処理と同様である。

以上のように、実施の形態４にかかる認証認可システム１０００によれば、認証認可サーバ１がエージェント方式かつ認証認可サーバ１が複数台である場合でも、認証認可サーバ１がエージェント方式かつ認証認可サーバ１が単一である場合と同様に、システム利用時の職務に応じてアクセス権限を変えることにより、厳密なアクセス制御が可能である。

つまり、実施の形態４にかかる認証認可システム１０００は、認証認可サーバ１を複数の異なる筐体に備え、異なるサーバ間においてもシングルサインオンおよびユーザ間のリンクから属性情報を取得してアクセス制御を行うとともに、さらに、ユーザからの直接アクセスのみならず、業務サーバからのリダレクトアクセスにより認証及び認可を実施することを特徴とする。

実施の形態５．
次に実施の形態５について説明する。上述した実施の形態では、利用ユーザが現在の職務を意識して業務システムを利用する場合の認証認可方式を示した。実施の形態５では、利用ユーザが現在の職務を意識しないで業務システムを利用する場合の認証及びアクセス制御について説明する。

図１５は実施の形態５にかかる認証認可システム１０００の概要構成を示す構成図である。実施の形態５にかかる認証認可システム１０００は、アクセス経路マッピングＤＢ（Ｄａｔａ Ｂａｓｅ）８を有する。また、企業Ａ５ａはポータルサーバＡを備え、企業Ｂ５ｂはポータルサーバＢを備える。ポータルサーバＡ、ポータルサーバＢは、各業務サーバ（業務サーバＡ−１、業務サーバＡ−２、業務サーバＢ−１、業務サーバＢ−２）へアクセスする場合に経由されるサーバである。その他は、実施の形態１の構成と同様である。

図１６は、アクセス経路マッピングＤＢ８の一例について示す図である。アクセス経路マッピングＤＢ８は、ユーザ毎にサーバへのアクセスの経路情報と上記経路情報に割当てられたグループを識別するグループ識別情報とを記憶装置に記憶する。ここでは、図１６に示すように、アクセス経路マッピングＤＢ８は、主職務用企業コード（グループ識別情報）、アクセス経路１とアクセス経路２とを備えるアクセス経路を有する。

次に、図１７、図１８、図１９に基づき認証認可システム１０００の機能と動作とを説明する。図１７は、実施の形態５にかかる認証認可システム１０００の機能を示す機能ブロック図である。
実施の形態５にかかる認証認可サーバ１は、経路取得部７２、経路判定部７４、グループ識別情報取得部７６を備える。また、ユーザ属性情報取得部３０は、第１ユーザ属性情報取得部３２、第２ユーザ属性情報取得部３４、第３ユーザ属性情報取得部３８を備える。また、第２ユーザ属性情報取得部は、リンク先ユーザ属性情報取得部３５、リンク元ユーザ属性情報取得部３６を備える。その他は、実施の形態１と同様である。

図１８は、実施の形態５における認証認可サーバ１の認証処理のフローチャートである。図１９は、実施の形態５における認証認可サーバ１の認可処理のフローチャートである。これらは、認証認可システム１０００及び認証認可サーバ１の認証認可処理（認証認可方法、認証認可プログラム）の一例である。

（Ｓ１）から（Ｓ４）までは、実施の形態１と同様である。但し、（Ｓ２で認証済）の場合、（Ｓ５−１）へ進む。また、（Ｓ３）では、ログイン画面６−１を送信する。（Ｓ５−１：識別情報入力ステップ）では、ユーザが、ログイン画面６にてユーザを識別するユーザＩＤ（ユーザ識別情報の一例）、パスワードを入力し、ＳＵＢＭＩＴボタンを押下する。すると、認証認可サーバ１へユーザが入力した情報が送信される（Ｓ６−１：識別情報送信ステップ）。ここでは、ユーザはユーザＩＤとして「ユーザＡ」を入力したとする。

（Ｓ７−１：識別情報受信ステップ）では、認証認可サーバＡ１ａの識別情報受信部１０は、ユーザＡが送信したユーザＩＤ、パスワードを、通信装置９８８を介して受信する。次に、認証リポジトリ検索部２０は、アクセス先のＵＲＬなどのアクセス先を特定する情報から認証に使用する認証リポジトリを処理装置９８０により検索して決定する（Ｓ８−２：認証リポジトリ検索ステップ）。例えば、ここでは、ユーザＡは業務サーバＡ−１にアクセスするものとする。業務サーバＡ−１は企業Ａのサーバである。そのため、認証リポジトリ検索部２０は、認証に使用する認証リポジトリを企業Ａ（第１グループの一例）に割当てられた「認証リポジトリＡ２ａ」（第１認証リポジトリの一例）に決定する。（Ｓ９）から（Ｓ１２）までは、実施の形態１と同様である。リンク情報取得部４０は、第１ユーザ属性情報取得部３２が取得したユーザ属性情報のリンク情報に値が設定されているか処理装置９８０によりチェックする（Ｓ１３）。リンク情報がないとリンク情報取得部４０が判定した場合（Ｓ１３でなし）、リンク情報取得部４０は（Ｓ１６）へ進む。一方、リンク情報があるとリンク情報取得部４０が判定した場合（Ｓ１３であり）、リンク情報取得部４０は、リンク元情報が設定されているか処理装置９８０によりチェックする（Ｓ３１：リンク元情報判定ステップ）。リンク元情報がないとリンク情報取得部４０が判定した場合（Ｓ３１でなし）、リンク情報取得部４０は、（Ｓ１４−１）へ進む。一方、リンク元情報があるとリンク情報取得部４０が判定した場合（Ｓ３１であり）、リンク情報取得部４０は先の職務は副職務とし（Ｓ３２）：第１職務変更ステップ）、リンク元ユーザ属性情報取得部３６はリンク元のユーザ属性情報を取得して、主職務とする（Ｓ３３：第２職務変更ステップ）。そして、（Ｓ１４−１：リンク情報取得ステップ）では、リンク情報取得部４０は、リンク先情報を取得する。（Ｓ１５−１：第２ユーザ属性情報取得ステップ）では、リンク先ユーザ属性情報取得部３５は、リンク情報が示すリンク先認証リポジトリからユーザ属性情報を取得して記憶装置９８４に記憶する。そして、認証認可サーバ１は認証完了する（Ｓ１６）。つまり、ここでは、リンク先情報はあるが、リンク元情報はないため、第１ユーザ属性情報取得部３２は、企業Ａ、総務、課長を主職務として記憶する。また、第２ユーザ属性情報取得部３４は、企業Ｂ、経理、担当を副職務として記憶する。

そして、認証が完了したユーザＡが、認証認可サーバ１経由で、企業Ａの業務サーバＡ−１へアクセスする（Ｓ１９）。次に、経路取得部７２は、ユーザＡがアクセスする業務サーバへのアクセス経路であるユーザ経路情報を取得して記憶装置９８４に記憶する（Ｓ３４：経路取得ステップ）。経路判定部７４は、記憶装置９８４に記憶したユーザ経路情報とアクセス経路マッピングＤＢ８が記憶する経路情報とを比較して一致する経路情報があるか否かを処理装置により判定する（Ｓ３５：経路判定ステップ）。一致する経路情報があると経路判定部７４が判定した場合（Ｓ３５であり）、グループ識別情報取得部７６は、アクセス経路マッピングＤＢ８から上記経路情報に割当てられた主職務用企業コードを取得して記憶装置９８４に記憶する。そして、第３ユーザ属性情報取得部は、主職務用企業コードに割当てられた認証リポジトリ（第３認証リポジトリの一例）から取得したユーザ属性情報を主職務とし、これまで主職務としていたユーザ属性情報を副職務とする（Ｓ３６：権限レベル変更ステップ）。それにともない、メモリ上のアクセス履歴をクリアする（Ｓ３７：取得経路削除ステップ）。一方、一致する経路情報がないと経路判定部７４が判定した場合（Ｓ３５でなし）、経路判定部７４は、（Ｓ２０）へ進む。（Ｓ２０）以降は、実施の形態１と同様である。

ここでは、ユーザＡがポータルＡを介して業務サーバＡ−１へアクセスするため、図１６に示すアクセス経路マッピングＤＢに該当する経路情報があり、その主職務用企業コードは「Ａ」である。したがって、この場合には、企業Ａに割当てられた認証リポジトリＡ２ａから取得したユーザ属性情報を主職務とするため、特に変更はない。

つまり、認証認可処理部６０は、リンク元の企業（リンク元グループの一例）のサーバへのクライアント４からのアクセスに対しては、上記企業に割当てられた認証リポジトリ（リンク元リポジトリの一例）から取得したユーザ属性情報に基づき処理装置９８０によりアクセス制御を行う。
また、権限情報取得部５０は、リンク元の企業のサーバへのクライアント４からのアクセスに対しては、ＡＣＬＤＢ３から、主職務（第１レベルの一例）に割当てられたＡＣＬをアクセス経路から判定された企業に割当てられた認証リポジトリから取得したユーザ属性情報に基づき取得し、認証認可処理部６０は、権限情報取得部５０が取得したＡＣＬ（第３権限情報の一例）に基づきアクセス制御を行う。一方、権限情報取得部５０は、リンク元の企業以外の企業のサーバへのクライアント４からのアクセスに対しては、副職務（第２レベルの一例）に割当てられたＡＣＬを各認証リポジトリから取得したユーザ属性情報に基づき取得し、認証認可処理部６０は、権限情報取得部５０が取得したＡＣＬ（第１権限情報及び第２権限情報の一例）に基づきアクセス制御を行う。

また、認証認可処理部６０は、アクセス経路から判定された企業（第３グループの一例）のサーバへのクライアント４からのアクセスに対しては、上記企業に割当てられた認証リポジトリ（第３認証リポジトリの一例）から取得したユーザ属性情報に基づき処理装置９８０によりアクセス制御を行う。
また、権限情報取得部５０は、アクセス経路から判定された企業のサーバへのクライアント４からのアクセスに対しては、主職務（第１レベルの一例）に割当てられたＡＣＬをアクセス経路から判定された企業に割当てられた認証リポジトリから取得したユーザ属性情報に基づき取得し、認証認可処理部６０は、権限情報取得部５０が取得したＡＣＬ（第１権限情報の一例）に基づきアクセス制御を行う。一方、権限情報取得部５０は、アクセス経路から判定された企業以外の企業のサーバへのクライアント４からのアクセスに対しては、副職務（第２レベルの一例）に割当てられたＡＣＬを各認証リポジトリから取得したユーザ属性情報に基づき取得し、認証認可処理部６０は、権限情報取得部５０が取得したＡＣＬ（第２権限情報の一例）に基づきアクセス制御を行う。

以上のように、実施の形態５にかかる認証認可システム１０００によれば、利用者のアクセス経路により、現在の職務を判断することが可能である。したがって、利用者が職務を意識しないでシステムを利用した場合でも、適切な職務に応じてアクセス権限を変え、厳密なアクセス制御が可能である。

また、実施の形態５にかかる認証認可システム１０００によれば、リンク情報に主従関係を持たせ、その主従関係により職務を判断することが可能である。

また、上記では、主職務用企業コードに割当てられた認証リポジトリから取得したユーザ属性情報を主職務とした。しかし、主職務用企業コードに割当てられた認証リポジトリから取得したユーザ属性情報が取得されていない場合には、第３ユーザ属性情報取得部３８は、主職務用企業コードに割当てられた認証リポジトリからユーザ属性情報を取得するとしても構わない。

また、（Ｓ３３）では、リンク元のユーザ属性情報を取得した場合、（Ｓ１４−１）へ進んでいた。しかし、（Ｓ３１）へ戻り、取得したリンク元のユーザ属性情報にさらにリンク元情報を有しているかチェックしても構わない。つまり、リンク元が存在する限り、リンク元のユーザ属性情報を取得して、本元にあるユーザ属性情報を主職務としても構わない。この場合、（Ｓ１４−１）において、取得したユーザ属性情報のリンク情報をすべて取得し、（Ｓ１５−１）において、取得したリンク情報のユーザ属性情報をすべて取得するとしても構わない。

つまり、実施の形態５にかかる認証認可システム１０００は、ユーザのアクセス履歴により利用ユーザの職務および権限をユーザのアクセス履歴から自動的に現在の職務権限の決定を行うことを特徴とする。

実施の形態６．
次に実施の形態６について説明する。実施の形態５では、単一の認証認可サーバ１、かつ、利用ユーザが現在の職務を意識しないで業務システムを利用する場合の認証認可方式を示した。実施の形態６では、認証認可サーバ１が複数台、かつ、利用ユーザが現在の職務を意識しないで業務システムを利用する場合の場合の認証及びアクセス制御について説明する。

図２０は実施の形態６にかかる認証認可システム１０００の概要構成を示す構成図である。実施の形態６にかかる認証認可システム１０００は、実施の形態５と同様のアクセス経路マッピングＤＢ８を有する。その他は、実施の形態２の構成と同様である。

実施の形態６にかかる認証認可システム１０００の機能ブロック図は、認証認可サーバがアクセス経路マッピングＤＢ８と通信することを除き、実施の形態１と同様である。
実施の形態６における認証処理及び認可処理は実施の形態２および実施の形態５を組み合わせた処理となる。つまり、認証処理については、図１８に示す実施の形態５にかかる認証処理の（Ｓ８−２）を、図９に示す実施の形態２にかかる認証処理の（Ｓ８−１）に置き換える。また、認可処理については、図１９に示す実施の形態５の認可処理と同様である。

以上のように、実施の形態６にかかる認証認可システム１０００によれば、認証認可サーバ１が複数台存在した場合も、単一サーバと同様に、利用者のアクセス履歴により現在の職務を判断することが可能である。したがって、利用者が職務を意識しないでシステムを利用した場合でも、適切な職務に応じた、厳密なアクセス制御が可能である。

つまり、実施の形態４にかかる認証認可システム１０００は、認証認可サーバ１を複数の異なる筐体に備え、異なるサーバ間においてもシングルサインオンおよびユーザ間のリンクから属性情報を取得してアクセス制御を行うとともに、さらに、ユーザのアクセス履歴により利用ユーザの職務および権限をユーザのアクセス履歴から自動的に現在の職務権限の決定を行うことを特徴とする。

実施の形態にかかる認証認可システム１０００の外観の一例を示した図。 実施の形態における認証認可サーバ１００のハードウェア構成の一例を示す図。 実施の形態１にかかる認証認可システム１０００の概要構成を示す構成図。 実施の形態１にかかる認証認可システム１０００の機能を示す機能ブロック図。 実施の形態１における認証認可サーバ１の認証処理のフローチャート。 実施の形態１における認証認可サーバ１の認可処理のフローチャート。 実施の形態２にかかる認証認可システム１０００の概要構成を示す構成図。 実施の形態２にかかる認証認可システム１０００の機能を示す機能ブロック図。 実施の形態２における認証認可サーバＡ１ａ、認証認可サーバＢ１ｂの認証処理のフローチャート。 実施の形態３にかかる認証認可システム１０００の概要構成を示す構成図。 実施の形態３にかかる認証認可システム１０００の機能を示す機能ブロック図。 実施の形態３における認証認可サーバ１の認証処理のフローチャート。 実施の形態３における認証認可サーバ１の認可処理のフローチャート。 実施の形態４にかかる認証認可システム１０００の概要構成を示す構成図。 実施の形態５にかかる認証認可システム１０００の概要構成を示す構成図。 アクセス経路マッピングＤＢ８の一例について示す図。 実施の形態５にかかる認証認可システム１０００の機能を示す機能ブロック図。 実施の形態５における認証認可サーバ１の認証処理のフローチャート。 実施の形態５における認証認可サーバ１の認可処理のフローチャート。 実施の形態６にかかる認証認可システム１０００の概要構成を示す構成図。

符号の説明

１ 認証認可サーバ、２ａ 認証リポジトリＡ、２ｂ 認証リポジトリＢ、３ ＡＣＬＤＢ、４ クライアント、６ ログイン画面、１０ 識別情報受信部、２０ 認証リポジトリ検索部、３０ ユーザ属性情報取得部、３２ 第１ユーザ属性情報取得部、３４ 第２ユーザ属性情報取得部、３５ リンク先ユーザ属性情報取得部、３６ リンク元ユーザ属性情報取得部、３８ 第３ユーザ属性情報取得部、４０ リンク情報取得部、５０ 権限情報取得部、５２ 第１権限情報取得部、５４ 第２権限情報取得部、６０ 認証認可処理部、６２ 第１認証認可処理部、６４ 第２認証認可処理部、７２ 経路取得部、７４ 経路判定部、７６ グループ識別情報取得部、９０ 認証判定部、９０１ ＣＲＴ表示装置、９０２ Ｋ／Ｂ、９０３ マウス、９０４ ＦＤＤ、９０５ ＣＤＤ、９０８ データベース、９０９ システムユニット、９１１ ＣＰＵ、９１２ バス、９１３ ＲＯＭ、９１４ ＲＡＭ、９１５ 通信ボード、９１６ 外部サーバ、９１７ サーバＡ、９１８ サーバＢ、９２０ 磁気ディスク装置、９２１ ＯＳ、９２２ ウィンドウシステム、９２３ プログラム群、９２４ ファイル群、９３１ 電話器、９３２ ＦＡＸ機、９４０ インターネット、９４１ ゲートウェイ、９４２ ＬＡＮ、９８０ 処理装置、９８２ 入力装置、９８４ 記憶装置、９８６ 表示装置、９８８ 通信装置。

Claims (12)

1. 属性情報と、リンクする認証リポジトリを示すリンク情報とを含むユーザ毎に割当てられたユーザ属性情報を記憶装置に記憶する複数の認証リポジトリから、所定の認証リポジトリを処理装置により検索する認証リポジトリ検索部と、
   上記認証リポジトリ検索部が検索した認証リポジトリである第１認証リポジトリから所定のユーザのユーザ属性情報を取得して記憶装置に記憶する第１ユーザ属性情報取得部と、
   上記第１ユーザ属性情報取得部が取得したユーザ属性情報からリンク情報を取得して記憶装置に記憶するリンク情報取得部と、
   上記リンク情報取得部が取得したリンク情報が示す認証リポジトリである第２認証リポジトリから上記ユーザのユーザ属性情報を取得して記憶装置に記憶する第２ユーザ属性情報取得部と、
   上記第１認証リポジトリが割当てられたグループである第１グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記第１ユーザ属性情報取得部が取得したユーザ属性情報に基づき処理装置によりアクセス制御を行い、上記第２認証リポジトリが割当てられたグループである第２グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記第２ユーザ属性情報取得部が取得したユーザ属性情報に基づき処理装置によりアクセス制御を行う認証認可処理部と
   を備えることを特徴とする認証認可サーバ。
2. 上記認証認可サーバは、さらに、
   権限レベル毎にアクセス権限情報を記憶するＡＣＬＤＢ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ Ｄａｔａ Ｂａｓｅ）により記憶された権限レベルが第１レベルのアクセス権限情報から上記第１ユーザ属性情報取得部が取得したユーザ属性情報に含まれる属性情報に基づきアクセス権限情報を第１権限情報として取得し、上記ＡＣＬＤＢにより記憶された権限レベルが第２レベルのアクセス権限情報から上記第２ユーザ属性情報取得部が取得したユーザ属性情報に含まれる属性情報に基づきアクセス権限情報を第２権限情報として取得して記憶装置に記憶する権限情報取得部を備え、
   上記認証認可処理部は、上記第１グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記権限情報取得部が取得した第１権限情報に基づいてアクセス制御を行い、上記第２グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記権限情報取得部が取得した第２権限情報に基づいてアクセス制御を行う
   ことを特徴とする請求項１記載の認証認可サーバ。
3. 上記認証リポジトリ検索部は、属性情報と、リンク先認証リポジトリとリンク元認証リポジトリとを示すリンク情報とを含むユーザ毎に割当てられたユーザ属性情報を記憶する複数の認証リポジトリから、所定の認証リポジトリを検索し、
   上記第２ユーザ属性情報取得部は、上記リンク情報取得部が取得したリンク情報が示すリンク先認証リポジトリから上記ユーザのユーザ属性情報を取得するリンク先ユーザ情報取得部と、上記リンク情報が示すリンク元認証リポジトリから上記ユーザのユーザ属性情報を取得するリンク元ユーザ情報取得部とを備え、
   上記認証認可サーバは、さらに、
   権限レベル毎にアクセス権限情報を記憶するＡＣＬＤＢ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ Ｄａｔａ Ｂａｓｅ）により記憶された権限レベルが第２レベルのアクセス権限情報から、上記第１ユーザ属性情報取得部が取得したユーザ属性情報に含まれる属性情報に基づきアクセス権限情報を第１権限情報として取得し、上記ＡＣＬＤＢにより記憶された権限レベルが第２レベルのアクセス権限情報から上記リンク先ユーザ属性情報取得部が取得したユーザ属性情報に含まれる属性情報に基づきアクセス権限情報を第２権限情報として取得し、上記ＡＣＬＤＢにより記憶された権限レベルが第１レベルのアクセス権限情報から上記リンク元ユーザ属性情報取得部が取得したユーザ属性情報に含まれる属性情報に基づきアクセス権限情報を第３権限情報として取得する権限情報取得部を備え、
   上記認証認可処理部は、上記第１グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記権限情報取得部が取得した第１権限情報に基づいてアクセス制御を行い、上記リンク先認証リポジトリが割当てられたリンク先グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記権限情報取得部が取得した第２権限情報に基づいてアクセス制御を行い、上記リンク元認証リポジトリが割当てられたリンク元グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記権限情報取得部が取得した第３権限情報に基づいてアクセス制御を行う
   ことを特徴とする請求項１記載の認証認可サーバ。
4. 上記認証認可サーバは、さらに、
   ユーザを識別するユーザ識別情報とグループを識別するグループ識別情報とを、通信装置を介して受信する識別情報受信部を備え、
   上記認証リポジトリ検索部は、上記識別情報受信部が受信したグループ識別情報によって識別されるグループに割当てられた認証リポジトリを上記所定の認証リポジトリとして検索し、
   上記第１ユーザ属性情報取得部は、上記認証リポジトリ検索部が検索した第１認証リポジトリから、上記識別情報受信部が受信したユーザ識別情報によって識別されるユーザを所定のユーザとしてユーザ属性情報を取得する
   ことを特徴とする請求項１記載の認証認可サーバ。
5. 上記識別情報受信部は、ユーザによりユーザ端末からアクセスされた上記グループのサーバからユーザ識別情報とグループ識別情報とを受信する
   ことを特徴とする請求項４記載の認証認可サーバ。
6. 上記認証認可サーバは、さらに、
   ユーザによりユーザ端末からサーバへアクセスされた場合、上記ユーザを識別するユーザ識別情報を通信装置を介して受信する識別情報受信部を備え、
   上記認証リポジトリ検索部は、上記ユーザ端末によりアクセスされたサーバが属するグループに割当てられた認証リポジトリを上記所定の認証リポジトリとして検索し、
   上記第１ユーザ属性情報取得部は、上記認証リポジトリ検索部が検索した第１認証リポジトリから、上記識別情報受信部が受信したユーザ識別情報によって識別されるユーザを所定のユーザとしてユーザ属性情報を取得する
   ことを特徴とする請求項１記載の認証認可サーバ。
7. 上記認証認可サーバは、さらに、
   上記ユーザ端末から上記サーバへアクセスした経路を示すユーザ経路情報を取得して記憶装置に記憶する経路取得部と、
   ユーザ毎に、サーバへのアクセスの経路情報と上記経路情報に割当てられたグループを識別するグループ識別情報とを記憶するアクセス経路マッピングＤＢ（Ｄａｔａ Ｂａｓｅ）を検索して、上記経路取得部が取得したユーザ経路情報が上記ユーザに割当てられた経路情報として存在するか否かを処理装置により判定する経路判定部と、
   上記ユーザが上記サーバへアクセスした経路が存在すると上記経路判定部が判定した場合、上記経路情報に割当てられたグループ識別情報を取得して記憶装置に記憶するグループ識別情報取得部とを備え、
   上記認証リポジトリ検索部は、上記グループ識別情報取得部が取得したグループ識別情報により識別されるグループである第３グループに割当てられた第３認証リポジトリを検索し、
   上記認証認可サーバは、さらに、
   上記認証リポジトリ検索部が検索した第３認証リポジトリから上記ユーザのユーザ属性情報を取得して記憶装置に記憶する第３ユーザ属性情報取得部と、
   権限レベル毎にアクセス権限情報を記憶するＡＣＬＤＢ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ Ｄａｔａ Ｂａｓｅ）により記憶された権限レベルが第１レベルのアクセス権限情報から、第３ユーザ属性情報取得部が取得したユーザ属性情報に含まれる属性情報に基づきアクセス権限情報を第１権限情報として取得して記憶装置に記憶する権限情報取得部と、
   上記認証認可処理部は、上記第３グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記権限情報取得部が取得した第１権限情報に基づいてアクセス制御を行う
   ことを特徴とする請求項６記載の認証認可サーバ。
8. 上記権限情報取得部は、ＡＣＬＤＢにより記憶された権限レベルが第２レベルのアクセス権限情報から、上記第３認証リポジトリを除いた他の認証リポジトリから取得したユーザ属性情報に含まれる属性情報に基づきアクセス権限情報を第２権限情報として取得し、
   上記認証認可処理部は、上記第３グループ以外のグループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記権限情報取得部が取得した第２権限情報に基づいてアクセス制御を行う
   ことを特徴とする請求項７記載の認証認可サーバ。
9. 複数のグループの各グループに割当てられたサーバへのアクセス制御を行う認証認可システムにおいて、
   上記複数のグループの１つのグループである第１グループに割当てられた第１認証リポジトリと、
   上記第１グループに割当てられたサーバへのアクセス制御を行う第１認証認可サーバと、
   上記第１認証認可サーバにより特定される第２認証リポジトリと、
   上記第２認証リポジトリが割当てられた第２グループに割当てられたサーバへのアクセス制御を行う第２認証認可サーバとを備え、
   上記第１認証リポジトリは、
   属性情報と、リンクする認証リポジトリを示すリンク情報とを含むユーザ毎に割当てられたユーザ属性情報を記憶装置に記憶するユーザ属性情報記憶部を備え、
   上記第１認証認可サーバは、
   ユーザを識別するユーザ識別情報を通信装置を介して受信する識別情報受信部と、
   上記第１認証リポジトリから上記識別情報受信部が受信したユーザ識別情報によって識別されるユーザのユーザ属性情報を取得する第１ユーザ属性情報取得部と、
   上記第１ユーザ属性情報取得部が取得したユーザ属性情報からリンク情報を取得して記憶装置に記憶するリンク情報取得部と、
   上記リンク情報取得部が取得したリンク情報が示す認証リポジトリを上記第２認証リポジトリとして特定し、上記第２認証リポジトリから上記リンク情報が示すユーザのユーザ属性情報を取得して記憶装置に記憶する第２ユーザ属性情報取得部と、
   上記第１グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記第１ユーザ属性情報取得部が取得したユーザ属性情報に基づき処理装置によりアクセス制御を行う第１認証認可処理部とを備え、
   上記第２認証認可サーバは、
   上記第２グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記第２ユーザ属性情報取得部が取得したユーザ属性情報に基づき処理装置によりアクセス制御を行う第２認証認可処理部を備える
   ことを特徴とする認証認可システム。
10. 上記認証認可システムは、さらに、
    第１グループに割当てられ、権限レベル毎にアクセス権限情報を記憶する第１ＡＣＬＤＢ（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔ Ｄａｔａ Ｂａｓｅ）と、
    第２グループに割当てられ、権限レベル毎にアクセス権限情報を記憶する第２ＡＣＬＤＢを備え、
    上記第１認証認可サーバは、さらに、
    上記第１ＡＣＬＤＢにより記憶された権限レベルが第１レベルのアクセス権限情報から上記第１ユーザ属性情報取得部が取得したユーザ属性情報に含まれる属性情報に基づきアクセス権限情報を第１権限情報として取得する第１権限情報取得部を備え、
    上記第２認証認可サーバは、さらに、
    上記第２ＡＣＬＤＢにより記憶された権限レベルが第２レベルのアクセス権限情報から上記第２ユーザ属性情報取得部が取得したユーザ属性情報に含まれる属性情報に基づきアクセス権限情報を第２権限情報として取得して記憶装置に記憶する第２権限情報取得部を備え、
    上記第１認証認可処理部は、上記第１グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記権限情報取得部が取得した第１権限情報に基づいてアクセス制御を行い、
    上記第２認証認可処理部は、上記第２グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記権限情報取得部が取得した第２権限情報に基づいてアクセス制御を行う
    ことを特徴とする請求項９記載の認証認可システム。
11. 認証認可サーバの認証認可方法において、
    属性情報と、リンクする認証リポジトリを示すリンク情報とを含むユーザ毎に割当てられたユーザ属性情報を記憶装置に記憶する複数の認証リポジトリから、所定の認証リポジトリを認証リポジトリ検索部が処理装置により検索する認証リポジトリ検索ステップと、
    上記認証リポジトリ検索ステップで検索した認証リポジトリである第１認証リポジトリから所定のユーザのユーザ属性情報を取得して第１ユーザ属性情報取得部が記憶装置に記憶する第１ユーザ属性情報取得ステップと、
    上記第１ユーザ属性情報取得ステップで取得したユーザ属性情報からリンク情報を取得してリンク情報取得部が記憶装置に記憶するリンク情報取得ステップと、
    上記リンク情報取得ステップで取得したリンク情報が示す認証リポジトリである第２認証リポジトリから上記ユーザのユーザ属性情報を取得して第２ユーザ属性情報取得部が記憶装置に記憶する第２ユーザ属性情報取得ステップと、
    上記第１認証リポジトリが割当てられたグループである第１グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記第１ユーザ属性情報取得ステップで取得したユーザ属性情報に基づき認証認可処理部が処理装置によりアクセス制御を行い、上記第２認証リポジトリが割当てられたグループである第２グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記第２ユーザ属性情報取得ステップで取得したユーザ属性情報に基づき認証認可処理部が処理装置によりアクセス制御を行う認証認可処理ステップと
    を備えることを特徴とする認証認可方法。
12. 認証認可サーバの認証認可プログラムにおいて、
    属性情報と、リンクする認証リポジトリを示すリンク情報とを含むユーザ毎に割当てられたユーザ属性情報を記憶装置に記憶する複数の認証リポジトリから、所定の認証リポジトリを処理装置により検索する認証リポジトリ検索処理と、
    上記認証リポジトリ検索処理で検索した認証リポジトリである第１認証リポジトリから所定のユーザのユーザ属性情報を取得して記憶装置に記憶する第１ユーザ属性情報取得処理と、
    上記第１ユーザ属性情報取得処理で取得したユーザ属性情報からリンク情報を取得して記憶装置に記憶するリンク情報取得処理と、
    上記リンク情報取得処理で取得したリンク情報が示す認証リポジトリである第２認証リポジトリから上記ユーザのユーザ属性情報を取得して記憶装置に記憶する第２ユーザ属性情報取得処理と、
    上記第１認証リポジトリが割当てられたグループである第１グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記第１ユーザ属性情報取得処理で取得したユーザ属性情報に基づき処理装置によりアクセス制御を行い、上記第２認証リポジトリが割当てられたグループである第２グループのサーバへの上記ユーザによるユーザ端末からのアクセスに対して、上記第２ユーザ属性情報取得処理で取得したユーザ属性情報に基づき処理装置によりアクセス制御を行う認証認可処理処理と
    をコンピュータに実行させることを特徴とする認証認可プログラム。

Images