(57)【特許請求の範囲】
【請求項１】
業務サーバと認証サーバとを有するアクセス制御システムであって、
前記業務サーバは、
クライアントからアクセス要求を受け付けて、当該アクセス要求に対するアクセス可否の認証を、前記認証サーバに要求する認証要求手段と、
前記認証サーバの認証結果に応じてアクセス制御を行うアクセス制御手段と、を有し、
前記認証サーバは、
アクセス可否のルール、および、前記業務サーバへ引き渡す第１のユーザ属性が記憶されたポリシーファイルと、
ユーザ属性情報が記憶された属性ファイルと、
前記業務サーバから認証要求を受信する受信手段と、
前記ポリシーファイルの前記アクセス可否のルールに記載された、認証に必要な第２のユーザ属性を読み出し、読み出した第２のユーザ属性のユーザ属性情報を前記属性ファイルから取得し、取得したユーザ属性情報が前記アクセス可否のルールに適合する場合、前記認証要求のアクセスを許可する認証手段と、
前記認証手段が前記認証要求のアクセスを許可した場合、前記ポリシーファイルを参照し、前記業務サーバへ引き渡す第１のユーザ属性を特定する特定手段と、
前記特定手段が特定した第１のユーザ属性に対応するユーザ属性情報を、前記属性ファイルから取得する取得手段と、
前記取得手段が取得した第１のユーザ属性情報を、前記業務サーバに送信する送信手段と、を有し、
前記業務サーバのアクセス制御手段は、前記認証サーバから前記第１のユーザ属性情報を受信すること
を特徴とするアクセス制御システム。
【請求項２】
業務サーバの要求に応じて認証を行う認証サーバであって、
アクセス可否のルール、および、前記業務サーバへ引き渡す第１のユーザ属性が記憶されたポリシーファイルと、
ユーザ属性情報が記憶された属性ファイルと、
クライアントのアクセス要求に対するアクセス可否の認証要求を、前記業務サーバから受信する受信手段と、
前記ポリシーファイルの前記アクセス可否のルールに記載された、認証に必要な第２のユーザ属性を読み出し、読み出した第２のユーザ属性のユーザ属性情報を前記属性ファイルから取得し、取得したユーザ属性情報が前記アクセス可否のルールに適合する場合、前記認証要求のアクセスを許可する認証手段と、
前記認証手段が前記認証要求のアクセスを許可した場合、前記ポリシーファイルを参照し、前記業務サーバへ引き渡す第１のユーザ属性を特定する特定手段と、
前記特定手段が特定した第１のユーザ属性に対応するユーザ属性情報を、前記属性ファイルから取得する取得手段と、
前記取得手段が取得した第１のユーザ属性情報を、前記業務サーバに送信する送信手段と、を有すること
を特徴とする認証サーバ。
【請求項３】
業務サーバと認証サーバとを有するアクセス制御システムにおけるアクセス制御方法であって、
前記業務サーバの処理部は、
クライアントからアクセス要求を受け付けて、当該アクセス要求に対するアクセス可否の認証を、前記認証サーバに要求する認証要求ステップと、
前記認証サーバの認証結果に応じてアクセス制御を行うアクセス制御ステップと、を行い、
前記認証サーバは、
アクセス可否のルール、および、前記業務サーバへ引き渡す第１のユーザ属性が記憶されたポリシーファイルと、ユーザ属性情報が記憶された属性ファイルと、処理部と、を有し、
前記処理部は、
前記業務サーバから認証要求を受信する受信ステップと、
前記ポリシーファイルの前記アクセス可否のルールに記載された、認証に必要な第２のユーザ属性を読み出し、読み出した第２のユーザ属性のユーザ属性情報を前記属性ファイルから取得し、取得したユーザ属性情報が前記アクセス可否のルールに適合する場合、前記認証要求のアクセスを許可する認証ステップと、
前記認証ステップで前記認証要求のアクセスが許可された場合、前記ポリシーファイルを参照し、前記業務サーバへ引き渡す第１のユーザ属性を特定する特定ステップと、
前記特定ステップで特定した第１のユーザ属性に対応するユーザ属性情報を、前記属性ファイルから取得する取得ステップと、
前記前記取得ステップで取得した第１のユーザ属性情報を、前記業務サーバに送信する送信ステップと、を行い、
前記業務サーバのアクセス制御ステップは、前記認証サーバから前記第１のユーザ属性情報を受信すること
を特徴とするアクセス制御方法。
【請求項４】
認証サーバが実行するアクセス制御プログラムであって、
前記認証サーバは、
アクセス可否のルール、および、前記業務サーバへ引き渡す第１のユーザ属性が記憶されたポリシーファイルと、ユーザ属性情報が記憶された属性ファイルと、処理部と、を有し、
前記処理部に、
クライアントのアクセス要求に対するアクセス可否の認証要求を、業務サーバから受信する受信ステップと、
前記ポリシーファイルの前記アクセス可否のルールに記載された、認証に必要な第２のユーザ属性を読み出し、読み出した第２のユーザ属性のユーザ属性情報を前記属性ファイルから取得し、取得したユーザ属性情報が前記アクセス可否のルールに適合する場合、前記認証要求のアクセスを許可する認証ステップと、
前記認証ステップで前記認証要求のアクセスが許可された場合、前記ポリシーファイルを参照し、前記業務サーバへ引き渡す第１のユーザ属性を特定する特定ステップと、
前記特定ステップで特定した第１のユーザ属性に対応するユーザ属性情報を、前記属性ファイルから取得する取得ステップと、
前記前記取得ステップで取得した第１のユーザ属性情報を、前記業務サーバに送信する送信ステップと、
を実行させるためのアクセス制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアントからのアクセス要求の可否を認証し、アクセスの制御を行うアクセス制御技術に関する。
【背景技術】
【０００２】
一度の認証で複数のシステムへアクセス可能なシングルサインオンを実現する技術として、ＳＡＭＬ（Security Assertion Markup Language）がある。ＳＡＭＬのプロトコルを用いることで、認証情報やアクセス制御情報を送受信することができる。
【０００３】
また、ＳＡＭＬ上で、きめ細かなアクセス制御を行うための記述言語としてＸＡＣＭＬ（eXtensible Access Control Markup Language）がある。
【０００４】
また、特許文献１には、利用制御ルールであるポリシーを用いて、複数の装置間でリソースの操作を行う分散協調型情報利用制御方法が記載されている。
【特許文献１】特開２００５−６３０２８
【発明の開示】
【発明が解決しようとする課題】
【０００５】
さて、ＳＡＭＬおよびＸＡＣＭＬを用いた認証システムでは、ユーザの認証やアクセス権限の判定を行い、所望のアプリケーションシステムへのアクセス制御を行う。そして、アクセスが許可されたアプリケーションシステムにおいて、所定のユーザ属性情報が必要な場合は、アプリケーションシステムが自らユーザ属性情報を認証システムに要求し、取得する。
【０００６】
しかしながら、複数のアプリケーションシステム各々が、ユーザ属性情報を認証システムから取得することは、プログラムの開発工数または保守性の観点から好ましくない。また、アプリケーションシステムと認証システム間でのネットワークトラフィックが増大する。また、各アプリケーションシステムでは各種の実装言語が使用されているため、認証システム側ではそれぞれの言語に対応した仕組みが必要となる。
【０００７】
本発明は上記事情に鑑みてなされたものであり、本発明の目的は、アプリケーションシステムの処理負荷を軽減しつつ、必要なユーザ属性情報をアプリケーションシステムに効率良く引き渡すことにある。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明は、例えば、業務サーバと認証サーバとを有するアクセス制御システムであって、業務サーバは、クライアントからアクセス要求を受け付けて、当該アクセス要求に対するアクセス可否の認証を、前記認証サーバに要求する認証要求手段と、前記認証サーバから、アクセス可否の認証結果を受信し、当該認証結果に応じてアクセス制御を行うアクセス制御手段と、を有し、認証サーバは、アクセス可否のルール、および、前記業務サーバへ引き渡すユーザ属性が記憶されたポリシーファイルと、ユーザ属性情報が記憶された属性ファイルと、前記業務サーバから認証要求を受信する受信手段と、前記ポリシーファイルおよび前記属性ファイルを参照し、前記認証要求のアクセスを許可するか否かを認証する認証手段と、前記ポリシーファイルを参照し、前記業務サーバへ引き渡すユーザ属性を特定する特定手段と、前記特定手段が特定したユーザ属性に対応するユーザ属性情報を、前記属性ファイルから取得する取得手段と、前記認証手段が認証した認証結果と、前記取得手段が取得したユーザ属性情報とを、前記業務サーバに送信する送信手段と、を有し、前記業務サーバのアクセス制御手段は、前記認証サーバから前記ユーザ属性情報を受信する。
【発明の効果】
【０００９】
本発明では、アプリケーションシステムの処理負荷を軽減しつつ、必要なユーザ属性情報をアプリケーションシステムに効率良く引き渡すことができる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の実施の形態について説明する。
【００１１】
図１は、本発明の一実施形態が適用されたアクセス制御システムの全体構成図である。なお、本実施形態のアクセス制御システムでは、ＳＡＭＬ（Security Assertion Markup Language）のプロトコルを用いるものとする。図示するアクセス制御システムは、クライアント１と、少なくとも１つのアプリケーションサーバ２と、認証サーバ３と、を有する。
【００１２】
なお、クライアント１とアプリケーションサーバ２は、インターネットなどの第１のネットワーク４により接続され、メッセージの送受信にはＨＴＴＰ（HyperText Transfer Protocol）などが用いられる。また、アプリケーションサーバ２と認証サーバ３は、第２のネットワーク５により接続され、メッセージの送受信にはＨＴＴＰまたはＳＯＡＰ（Simple Object Access Protocol）などが用いられる。なお、第１のネットワーク４と第２のネットワーク５とを統合した１つのネットワークに、各装置が接続されていることとしてもよい。
【００１３】
クライアント１は、Ｗｅｂブラウザ（不図示）などを備え、ユーザの指示を受け付けて所望のアプリケーションサーバ２にアクセスする。
【００１４】
アプリケーションサーバ２は、例えばＷｅｂサーバなどであって、各種のサービスをクライアント１に提供する。図示するアプリケーションサーバ２は、アクセス制御を行うＰＥＰ（Policy Enforcement Point：ポリシー実行点）２１と、業務処理部２４とを有する。ＰＥＰ２１は、クライアント１からアクセス要求を受け付け、認証サーバ３にアクセス可否を問い合わせる認証要求部２２と、認証サーバ３の認証結果（アクセス許可、アクセス拒否）に基づいてアクセス制御を行うアクセス制御部２３と、を有する。
【００１５】
認証サーバ３は、アプリケーションサーバ２のＰＥＰ２１から受け付けたアクセス可否の問い合わせに対して、アクセス可否を判定する。図示する認証サーバ３は、アクセス可否の判定を行うＰＤＰ（Policy Decision Point：ポリシー決定点）３１と、認証エージェント３６と、属性エージェント３８と、を有する。
【００１６】
ＰＤＰ３１は、制御部３２と、認可決定部３３と、ポリシーファイル３４と、を有する。制御部３２は、認可決定部３３を制御して、ＰＥＰ２１から受け付けた問い合わせのアクセス可否を決定するとともに、ＰＥＰ２１にユーザ属性情報を提供する。認可決定部３３は、制御部３２の指示に基づいて、ポリシーファイル３４を参照し、アクセス可否を決定する。
【００１７】
ポリシーファイル３４には、アプリケーションサーバ２の各リソース（または、サービス）に対するアクセス制御のルール（規則）が記述されたポリシーが、記憶されている。なお、ポリシーについては、後述する。
【００１８】
認証エージェント３６は、制御部からの要求を受け付けて、認証データベース（以下、「認証ＤＢ」）３７を参照し、認証応答（認証アサーション（Assertion））を返す。認証ＤＢ３７は、ユーザの本人性（Identity）を認証するためのデータベースであって、例えば、パスワードファイル、ＰＫＩ（Public Key Infrastructure）の証明書などが記憶されている。
【００１９】
属性エージェント３８は、制御部３２または認可決定部３３からの要求を受け付けて、ユーザ属性データベース（以下、「ユーザ属性ＤＢ」）３９を参照し、属性応答（属性アサーション）を返す。ユーザ属性ＤＢ３９には、リソースへのアクセス可否を判断するために必要なユーザ属性情報、または、アプリケーションサーバ２やクライアント１に引き継ぐユーザ属性情報が記憶されている。
【００２０】
上記説明した、クライアント１、アプリケーションサーバ２、認証サーバ３は、いずれも、例えば図２に示すようなＣＰＵ９０１と、メモリ９０２と、ＨＤＤ等の外部記憶装置９０３と、キーボードやマウスなどの入力装置９０４と、ディスプレイやプリンタなどの出力装置９０５と、ネットワークと接続するための通信制御装置９０６と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。
【００２１】
例えば、アプリケーションサーバ２および認証サーバ３の各機能は、アプリケーションサーバ２用のプログラムの場合はアプリケーションサーバ２のＣＰＵ９０１が、そして、認証サーバ３用のプログラムの場合は認証サーバ３のＣＰＵ９０１が、それぞれ実行することにより実現される。なお、認証サーバ３のポリシーファイル３４、認証ＤＢ３７、ユーザ属性ＤＢ３９には、認証サーバ３のメモリ９０２または外部記憶装置９０３が、用いられるものとする。また、入力装置９０４および出力装置９０５については、各装置が必要に応じて備えるものとする。
【００２２】
次に、ポリシーファイル３４に記述されたポリシーについて説明する。
【００２３】
図３は、ポリシーの一例を示したものである。本実施形態では、ポリシー記述言語として、ＸＡＣＭＬ（eXtensible Access Control Markup Language）を用いることとする。ＸＡＣＭＬで記述されたポリシーは、対象（Target）３４ａと、ルール（Rule）３４ｂと、責務（Obligation）３４ｃと、を有する。対象３４ａには、アクセス制御の対象となる主体（Subject）、資源（Resources）、動作（Action）の３つの要素に対する規則が記述される。
【００２４】
ルール３４ｂには、対象３４ａに記述された主体、資源、動作に対するアクセス制御の規則が記述される。すなわち、ルール３４ｂには、アクセス要求の主体、資源、動作の属性が、当該ルールに適合した場合に決定する値（許可：Permitまたは不許可：Deny）をルールの属性（Effect）として設定されている。
【００２５】
責務３４ｃには、アプリケーションサーバ２のＰＥＰ２１に責務として実行を強制する指示が記述される。責務３４ｃが記述されている場合、ＰＤＰ３１は、当該責務をＰＥＰ２１に示して、責務３４ｃの実行をＰＥＰ２１に課す。本実施形態では、アプリケーションサーバ２の業務処理部２４またはクライアント１に、所定のユーザ属性情報を引き継ぐことを、責務としている。なお、図示する例では、ユーザ属性情報のメールアドレスおよび電話番号を引き継ぐこと責務として記述している。
【００２６】
次に、本実施形態のアクセス制御処理の流れについて説明する。
【００２７】
図４および図５は、アクセス制御処理のフローチャートである。
【００２８】
まず、クライアント１は、アプリケーションサーバ２に所定のリソースへのアクセス要求を送信する。なお、アクセス要求には、アクセス先のリソース情報と、ユーザ識別情報（アーティファクト）とが含まれている。なお、リソースとしては、アプリケーションサーバ２が提供するＷｅｂページなどが考えられる。
【００２９】
そして、図４に示すように、アプリケーションサーバ２の認証要求部２２は、クライアント１からアクセス要求を受信し、当該アクセス要求の可否を問い合わせるアクセスチェック要求を、認証サーバに送信する（Ｓ１１）。なお、アクセスチェック要求には、受信したアクセス要求のリソース情報と、ユーザ識別情報とが含まれる。
【００３０】
認証サーバ３の制御部３２は、アクセスチェック要求をアプリケーションサーバ２から受信する。そして、制御部３２は、アクセスチェック要求に含まれるユーザ識別情報の認証チェックを、認証エージェント３６に要求する（Ｓ１２）。
【００３１】
認証エージェント３６は、認証ＤＢ３７を参照し、要求されたユーザ識別情報のユーザが、正当なユーザか否かを判別（認証）する。すなわち、認証エージェント３６は、ユーザに関する問い合わせに対し、その本人性（Identity）を確認するため、認証ＤＢ３７のパスワードファイルまたはＰＫＩ（Public Key Infrastructure）の証明書などを検証して、ユーザの本人性を認証する。
【００３２】
そして、認証エージェント３６は、正当なユーザであると判別した場合、正当なユーザであることを証明する認証応答（認証アサーション）を、制御部３２に発行する（Ｓ１３）。制御部３２は、認証応答を受け付けて、認可決定部３３に認可要求を送出する（Ｓ１４）。
【００３３】
認可決定部３３は、ポリシーファイル３４を参照し、認可決定に必要なユーザ属性を特定する。そして、認可決定部３３は、特定したユーザ属性を、属性エージェント３８に要求する（Ｓ１５）。
【００３４】
属性エージェント３８は、ユーザ属性ＤＢ３９を参照し、要求されたユーザ属性のユーザ属性情報を取得する。そして、属性エージェント３８は、取得したユーザ属性情報を含む属性応答（属性アサーション）を、認可決定部３３に送出する（Ｓ１６）。
【００３５】
そして、認可決定部３３は、ポリシーファイル３４に記憶されたポリシーのルールを参照し、取得したユーザ属性情報が当該ルールに適合するか否かを判定する（Ｓ１７）。ポリシーのルールに適合する場合（Ｓ１７：ＹＥＳ）、認可決定部３３は、クライアント１のアクセスを許可する決定をする。なお、アクセス許可の決定後の処理については、図５を用いて後述する。
【００３６】
一方、ポリシーのルールに適合しない場合（Ｓ１７：ＮＯ）、認可決定部３３は、クライアント１のアクセスを拒否する決定をする。そして、認可決定部３３は、アクセス拒否の判定結果を含む認可応答（認可アサーション）を、制御部３２に送出する（Ｓ１８）。そして、制御部３２は、アクセス拒否の認可応答を受け付けて、アプリケーションサーバ２にアクセス拒否の応答を送信する（Ｓ１９）。
【００３７】
アプリケーションサーバ２のアクセス制御部２３は、アクセス拒否の応答を受信し、要求元のクライアント１にアクセス権限がない旨を示すエラーメッセージを送信する（Ｓ２０）。
【００３８】
図５は、アクセス許可の決定後（Ｓ１７：ＹＥＳ）の処理のフローチャートである。
【００３９】
認可決定部３３は、ポリシーファイル３４を参照し、ポリシーの責務３４ｃを取得する（Ｓ２１）。本実施形態の責務は、ユーザ属性情報を業務処理部２４に引き渡すこととを、アプリケーションサーバ２のＰＥＰ２１に指示するものである。そして、認可決定部３３は、アクセス許可の判定結果と責務とを含む認可応答（認可アサーション）を、制御部３２に送出する（Ｓ２２）。
【００４０】
図６は、認可応答のメッセージの一例を示したものである。図示するメッセージでは、ユーザ属性のメールアドレスと電話番号とを取得する責務６１が記述されている。
【００４１】
そして、制御部３２は、アクセス許可の認可応答を受け付け、当該認可応答に含まれる責務に基づいて、ユーザ属性情報を属性エージェント３８に要求する（Ｓ２３）。
【００４２】
属性エージェント３８は、ユーザ属性ＤＢ３９を参照し、要求されたユーザ属性情報を取得する。そして、属性エージェント３８は、取得したユーザ属性情報を含む属性応答（属性アサーション）を、制御部３２に送出する（Ｓ２４）。
【００４３】
図７は、属性応答のメッセージの一例を示したものである。図示するメッセージには、属性ＤＢ３９から取得したメールアドレスと電話番号のユーザ属性情報が記述されている。
【００４４】
そして、制御部３２は、アクセス許可の判定結果と、責務のユーザ属性情報と、を含むアクセス許可の応答を、アプリケーションサーバ２に送信する（Ｓ２５）。
【００４５】
図８は、アクセス許可の応答メッセージの一例を示した図である。図示するメッセージには、アプリケーションサーバ２に引き渡すメールアドレスと電話番号のユーザ属性情報が記述されている。
【００４６】
アプリケーションサーバ２のアクセス制御部２３は、アクセス許可の応答を受信し、クライアント１から要求されたリソースへアクセスを許可する制御を行う（Ｓ２６）。また、アクセス制御部２３は、認証サーバ３から受信したユーザ属性情報を、業務処理部２４に引き渡す責務を実行する（Ｓ２７）。具体的には、アクセス制御部２３は、業務処理部２４が利用するメモリ領域に、受信したユーザ属性情報を設定する。
【００４７】
業務処理部２４は、クライアントが要求したリソース先（例えば、Ｗｅｂページ）をクライアントに送信するとともに、認証サーバ３から引き渡されたユーザ属性情報をクライアント１に送信する。
【００４８】
以上、本発明の一実施形態を説明した。
【００４９】
本実施形態では、認証サーバ３が、アプリケーションサーバ２のアクセス可否の問い合わせに対して、アクセス可否の判断を行うとともに、アプリケーションサーバ２の業務処理部２４が必要とするユーザ属性情報を送信する。これにより、アプリケーションサーバ２の処理負荷を軽減し、必要なユーザ属性情報をアプリケーションサーバ２に効率良く引き渡すことができる。また、アプリケーションサーバ２と認証サーバ３間でのネットワークトラフィックの増加を抑制することができる。
【００５０】
また、本実施形態では、認証サーバ３の制御部３２が、ポリシーファイル３４に設定された責務に基づいて、アプリケーションサーバ２に引き渡すユーザ属性情報を取得する。したがって、認証サーバ３では、アプリケーションサーバ２の実装言語各々に対応する仕組みを備える必要がない。
【００５１】
また、本実施形態では、認証サーバ３の認可決定部３３がアクセス許可の決定をした場合にのみ、アプリケーションサーバ２に引き渡すユーザ属性情報を取得する。すなわち、アクセス拒否の決定の場合は、不要なユーザ属性情報を取得しないため、認証サーバ３の処理負荷を軽減することができる。
【００５２】
なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【図面の簡単な説明】
【００５３】
【図１】本発明の一実施形態が適用されたアクセス制御システムの全体構成を示す図である。
【図２】各装置のハードウェア構成例を示す図である。
【図３】ポリシーファイルに記憶されたポリシーの一例を示す図である。
【図４】アクセス制御処理のフローチャートである。
【図５】アクセス制御処理のフローチャートである。
【図６】認可応答メッセージの一例を示す図である。
【図７】属性応答メッセージの一例を示す図である。
【図８】アクセス許可応答メッセージの一例を示す図である。
【符号の説明】
【００５４】
１：クライアント、２：アプリケーションサーバ、２１：ＰＥＰ、２２：認証要求部、２３：アクセス制御部、２４：業務処理部、３：認証サーバ、３１：ＰＤＰ、３２：制御部、３３：認可決定部、３４：ポリシーファイル、３６：認証エージェント、３７：認証ＤＢ、３８：属性エージェント、３９：ユーザ属性ＤＢ、４：第１のネットワーク、４：第２のネットワーク
【図１】
0004729365.tif 000002
【図２】
0004729365.tif 000003
【図３】
0004729365.tif 000004
【図４】
0004729365.tif 000005
【図５】
0004729365.tif 000006
【図６】
0004729365.tif 000007
【図７】
0004729365.tif 000008
【図８】
0004729365.tif 000009