米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 計算機;電気通信 -> 株式会社野村総合研究所

発明の名称 アクセス制御システム、アクセス制御方法およびアクセス制御プログラム
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2007−48241(P2007−48241A)
公開日 平成19年2月22日(2007.2.22)
出願番号 特願2005−235003(P2005−235003)
出願日 平成17年8月12日(2005.8.12)
代理人 【識別番号】100083806
【弁理士】
【氏名又は名称】三好 秀和
発明者 森本 修馬 / 渡辺 哲 / 高山 崇
要約 課題
アプリケーションシステムの処理負荷を軽減しつつ、必要なユーザ属性情報をアプリケーションシステムに効率良く引き渡す。

解決手段
認証サーバ3は、ポリシーファイルと、属性ファイルと、業務サーバ2から認証要求を受信する受信手段と、ポリシーファイルおよび属性ファイルを参照し、認証要求のアクセスを許可するか否かを認証する認証手段と、ポリシーファイルから業務サーバ2へ引き渡すユーザ属性を特定する特定手段と、特定手段が特定したユーザ属性に対応するユーザ属性情報を属性ファイルから取得する取得手段と、認証手段が認証した認証結果と取得手段が取得したユーザ属性情報とを、業務サーバ2に送信する送信手段とを有する。
特許請求の範囲
【請求項1】
業務サーバと認証サーバとを有するアクセス制御システムであって、
前記業務サーバは、
クライアントからアクセス要求を受け付けて、当該アクセス要求に対するアクセス可否の認証を、前記認証サーバに要求する認証要求手段と、
前記認証サーバから、アクセス可否の認証結果を受信し、当該認証結果に応じてアクセス制御を行うアクセス制御手段と、を有し、
前記認証サーバは、
アクセス可否のルール、および、前記業務サーバへ引き渡すユーザ属性が記憶されたポリシーファイルと、
ユーザ属性情報が記憶された属性ファイルと、
前記業務サーバから認証要求を受信する受信手段と、
前記ポリシーファイルおよび前記属性ファイルを参照し、前記認証要求のアクセスを許可するか否かを認証する認証手段と、
前記ポリシーファイルを参照し、前記業務サーバへ引き渡すユーザ属性を特定する特定手段と、
前記特定手段が特定したユーザ属性に対応するユーザ属性情報を、前記属性ファイルから取得する取得手段と、
前記認証手段が認証した認証結果と、前記取得手段が取得したユーザ属性情報とを、前記業務サーバに送信する送信手段と、を有し、
前記業務サーバのアクセス制御手段は、前記認証サーバから前記ユーザ属性情報を受信すること
を特徴とするアクセス制御システム。
【請求項2】
請求項1記載のアクセス制御システムであって、
前記認証手段の認証結果がアクセス許可の場合、
前記特定手段は、前記ポリシーファイルを参照し、前記ユーザ属性を特定し、
前記取得手段は、前記特定したユーザ属性に対応するユーザ属性情報を、前記属性ファイルから取得し、
前記送信手段は、前記取得したユーザ属性情報を前記業務サーバに送信し、
前記業務サーバのアクセス制御手段は、前記認証サーバから前記ユーザ属性情報を受信すること
を特徴とするアクセス制御システム。
【請求項3】
業務サーバと認証サーバとを有するアクセス制御システムにおけるアクセス制御方法であって、
前記業務サーバの処理部は、
クライアントからアクセス要求を受け付けて、当該アクセス要求に対するアクセス可否の認証を、前記認証サーバに要求する認証要求ステップと、
前記認証サーバから、アクセス可否の認証結果を受信し、当該認証結果に応じてアクセス制御を行うアクセス制御ステップと、を行い、
前記認証サーバは、
アクセス可否のルールと前記業務サーバへ引き渡すユーザ属性とが記憶されたポリシーファイルと、ユーザ属性情報が記憶された属性ファイルと、処理部と、を有し、
前記処理部は、
前記業務サーバから認証要求を受信する受信ステップと、
前記ポリシーファイルおよび前記属性ファイルを参照し、前記認証要求のアクセスを許可するか否かを認証する認証ステップと、
前記ポリシーファイルを参照し、前記業務サーバへ引き渡すユーザ属性を特定する特定ステップと、
前記特定ステップで特定したユーザ属性に対応するユーザ属性情報を、前記属性ファイルから取得する取得ステップと、
前記認証ステップで認証した認証結果と、前記取得ステップで取得したユーザ属性情報とを、前記業務サーバに送信する送信ステップと、を行い、
前記業務サーバのアクセス制御ステップは、前記認証サーバから前記ユーザ属性情報を受信すること
を特徴とするアクセス制御方法。
【請求項4】
認証サーバが実行するアクセス制御プログラムであって、
前記認証サーバは、
アクセス可否のルールと前記業務サーバへ引き渡すユーザ属性とが記憶されたポリシーファイルと、ユーザ属性情報が記憶された属性ファイルと、処理部と、を有し、
前記処理部に、
クライアントのアクセス要求に対するアクセス可否の認証要求を、業務サーバから受信する受信ステップと、
前記ポリシーファイルおよび前記属性ファイルを参照し、前記認証要求のアクセスを許可するか否かを認証する認証ステップと、
前記ポリシーファイルを参照し、前記業務サーバへ引き渡すユーザ属性を特定する特定ステップと、
前記特定ステップで特定したユーザ属性に対応するユーザ属性情報を、前記属性ファイルから取得する取得ステップと、
前記認証ステップで認証した認証結果と、前記取得ステップで取得したユーザ属性情報とを、前記業務サーバに送信する送信ステップと、を実行させること
を特徴とするアクセス制御プログラム。

発明の詳細な説明
【技術分野】
【0001】
本発明は、クライアントからのアクセス要求の可否を認証し、アクセスの制御を行うアクセス制御技術に関する。
【背景技術】
【0002】
一度の認証で複数のシステムへアクセス可能なシングルサインオンを実現する技術として、SAML(Security Assertion Markup Language)がある。SAMLのプロトコルを用いることで、認証情報やアクセス制御情報を送受信することができる。
【0003】
また、SAML上で、きめ細かなアクセス制御を行うための記述言語としてXACML(eXtensible Access Control Markup Language)がある。
【0004】
また、特許文献1には、利用制御ルールであるポリシーを用いて、複数の装置間でリソースの操作を行う分散協調型情報利用制御方法が記載されている。
【特許文献1】特開2005−63028
【発明の開示】
【発明が解決しようとする課題】
【0005】
さて、SAMLおよびXACMLを用いた認証システムでは、ユーザの認証やアクセス権限の判定を行い、所望のアプリケーションシステムへのアクセス制御を行う。そして、アクセスが許可されたアプリケーションシステムにおいて、所定のユーザ属性情報が必要な場合は、アプリケーションシステムが自らユーザ属性情報を認証システムに要求し、取得する。
【0006】
しかしながら、複数のアプリケーションシステム各々が、ユーザ属性情報を認証システムから取得することは、プログラムの開発工数または保守性の観点から好ましくない。また、アプリケーションシステムと認証システム間でのネットワークトラフィックが増大する。また、各アプリケーションシステムでは各種の実装言語が使用されているため、認証システム側ではそれぞれの言語に対応した仕組みが必要となる。
【0007】
本発明は上記事情に鑑みてなされたものであり、本発明の目的は、アプリケーションシステムの処理負荷を軽減しつつ、必要なユーザ属性情報をアプリケーションシステムに効率良く引き渡すことにある。
【課題を解決するための手段】
【0008】
上記課題を解決するために、本発明は、例えば、業務サーバと認証サーバとを有するアクセス制御システムであって、業務サーバは、クライアントからアクセス要求を受け付けて、当該アクセス要求に対するアクセス可否の認証を、前記認証サーバに要求する認証要求手段と、前記認証サーバから、アクセス可否の認証結果を受信し、当該認証結果に応じてアクセス制御を行うアクセス制御手段と、を有し、認証サーバは、アクセス可否のルール、および、前記業務サーバへ引き渡すユーザ属性が記憶されたポリシーファイルと、ユーザ属性情報が記憶された属性ファイルと、前記業務サーバから認証要求を受信する受信手段と、前記ポリシーファイルおよび前記属性ファイルを参照し、前記認証要求のアクセスを許可するか否かを認証する認証手段と、前記ポリシーファイルを参照し、前記業務サーバへ引き渡すユーザ属性を特定する特定手段と、前記特定手段が特定したユーザ属性に対応するユーザ属性情報を、前記属性ファイルから取得する取得手段と、前記認証手段が認証した認証結果と、前記取得手段が取得したユーザ属性情報とを、前記業務サーバに送信する送信手段と、を有し、前記業務サーバのアクセス制御手段は、前記認証サーバから前記ユーザ属性情報を受信する。
【発明の効果】
【0009】
本発明では、アプリケーションシステムの処理負荷を軽減しつつ、必要なユーザ属性情報をアプリケーションシステムに効率良く引き渡すことができる。
【発明を実施するための最良の形態】
【0010】
以下、本発明の実施の形態について説明する。
【0011】
図1は、本発明の一実施形態が適用されたアクセス制御システムの全体構成図である。なお、本実施形態のアクセス制御システムでは、SAML(Security Assertion Markup Language)のプロトコルを用いるものとする。図示するアクセス制御システムは、クライアント1と、少なくとも1つのアプリケーションサーバ2と、認証サーバ3と、を有する。
【0012】
なお、クライアント1とアプリケーションサーバ2は、インターネットなどの第1のネットワーク4により接続され、メッセージの送受信にはHTTP(HyperText Transfer Protocol)などが用いられる。また、アプリケーションサーバ2と認証サーバ3は、第2のネットワーク5により接続され、メッセージの送受信にはHTTPまたはSOAP(Simple Object Access Protocol)などが用いられる。なお、第1のネットワーク4と第2のネットワーク5とを統合した1つのネットワークに、各装置が接続されていることとしてもよい。
【0013】
クライアント1は、Webブラウザ(不図示)などを備え、ユーザの指示を受け付けて所望のアプリケーションサーバ2にアクセスする。
【0014】
アプリケーションサーバ2は、例えばWebサーバなどであって、各種のサービスをクライアント1に提供する。図示するアプリケーションサーバ2は、アクセス制御を行うPEP(Policy Enforcement Point:ポリシー実行点)21と、業務処理部24とを有する。PEP21は、クライアント1からアクセス要求を受け付け、認証サーバ3にアクセス可否を問い合わせる認証要求部22と、認証サーバ3の認証結果(アクセス許可、アクセス拒否)に基づいてアクセス制御を行うアクセス制御部23と、を有する。
【0015】
認証サーバ3は、アプリケーションサーバ2のPEP21から受け付けたアクセス可否の問い合わせに対して、アクセス可否を判定する。図示する認証サーバ3は、アクセス可否の判定を行うPDP(Policy Decision Point:ポリシー決定点)31と、認証エージェント36と、属性エージェント38と、を有する。
【0016】
PDP31は、制御部32と、認可決定部33と、ポリシーファイル34と、を有する。制御部32は、認可決定部33を制御して、PEP21から受け付けた問い合わせのアクセス可否を決定するとともに、PEP21にユーザ属性情報を提供する。認可決定部33は、制御部32の指示に基づいて、ポリシーファイル34を参照し、アクセス可否を決定する。
【0017】
ポリシーファイル34には、アプリケーションサーバ2の各リソース(または、サービス)に対するアクセス制御のルール(規則)が記述されたポリシーが、記憶されている。なお、ポリシーについては、後述する。
【0018】
認証エージェント36は、制御部からの要求を受け付けて、認証データベース(以下、「認証DB」)37を参照し、認証応答(認証アサーション(Assertion))を返す。認証DB37は、ユーザの本人性(Identity)を認証するためのデータベースであって、例えば、パスワードファイル、PKI(Public Key Infrastructure)の証明書などが記憶されている。
【0019】
属性エージェント38は、制御部32または認可決定部33からの要求を受け付けて、ユーザ属性データベース(以下、「ユーザ属性DB」)39を参照し、属性応答(属性アサーション)を返す。ユーザ属性DB39には、リソースへのアクセス可否を判断するために必要なユーザ属性情報、または、アプリケーションサーバ2やクライアント1に引き継ぐユーザ属性情報が記憶されている。
【0020】
上記説明した、クライアント1、アプリケーションサーバ2、認証サーバ3は、いずれも、例えば図2に示すようなCPU901と、メモリ902と、HDD等の外部記憶装置903と、キーボードやマウスなどの入力装置904と、ディスプレイやプリンタなどの出力装置905と、ネットワークと接続するための通信制御装置906と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、CPU901がメモリ902上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。
【0021】
例えば、アプリケーションサーバ2および認証サーバ3の各機能は、アプリケーションサーバ2用のプログラムの場合はアプリケーションサーバ2のCPU901が、そして、認証サーバ3用のプログラムの場合は認証サーバ3のCPU901が、それぞれ実行することにより実現される。なお、認証サーバ3のポリシーファイル34、認証DB37、ユーザ属性DB39には、認証サーバ3のメモリ902または外部記憶装置903が、用いられるものとする。また、入力装置904および出力装置905については、各装置が必要に応じて備えるものとする。
【0022】
次に、ポリシーファイル34に記述されたポリシーについて説明する。
【0023】
図3は、ポリシーの一例を示したものである。本実施形態では、ポリシー記述言語として、XACML(eXtensible Access Control Markup Language)を用いることとする。XACMLで記述されたポリシーは、対象(Target)34aと、ルール(Rule)34bと、責務(Obligation)34cと、を有する。対象34aには、アクセス制御の対象となる主体(Subject)、資源(Resources)、動作(Action)の3つの要素に対する規則が記述される。
【0024】
ルール34bには、対象34aに記述された主体、資源、動作に対するアクセス制御の規則が記述される。すなわち、ルール34bには、アクセス要求の主体、資源、動作の属性が、当該ルールに適合した場合に決定する値(許可:Permitまたは不許可:Deny)をルールの属性(Effect)として設定されている。
【0025】
責務34cには、アプリケーションサーバ2のPEP21に責務として実行を強制する指示が記述される。責務34cが記述されている場合、PDP31は、当該責務をPEP21に示して、責務34cの実行をPEP21に課す。本実施形態では、アプリケーションサーバ2の業務処理部24またはクライアント1に、所定のユーザ属性情報を引き継ぐことを、責務としている。なお、図示する例では、ユーザ属性情報のメールアドレスおよび電話番号を引き継ぐこと責務として記述している。
【0026】
次に、本実施形態のアクセス制御処理の流れについて説明する。
【0027】
図4および図5は、アクセス制御処理のフローチャートである。
【0028】
まず、クライアント1は、アプリケーションサーバ2に所定のリソースへのアクセス要求を送信する。なお、アクセス要求には、アクセス先のリソース情報と、ユーザ識別情報(アーティファクト)とが含まれている。なお、リソースとしては、アプリケーションサーバ2が提供するWebページなどが考えられる。
【0029】
そして、図4に示すように、アプリケーションサーバ2の認証要求部22は、クライアント1からアクセス要求を受信し、当該アクセス要求の可否を問い合わせるアクセスチェック要求を、認証サーバに送信する(S11)。なお、アクセスチェック要求には、受信したアクセス要求のリソース情報と、ユーザ識別情報とが含まれる。
【0030】
認証サーバ3の制御部32は、アクセスチェック要求をアプリケーションサーバ2から受信する。そして、制御部32は、アクセスチェック要求に含まれるユーザ識別情報の認証チェックを、認証エージェント36に要求する(S12)。
【0031】
認証エージェント36は、認証DB37を参照し、要求されたユーザ識別情報のユーザが、正当なユーザか否かを判別(認証)する。すなわち、認証エージェント36は、ユーザに関する問い合わせに対し、その本人性(Identity)を確認するため、認証DB37のパスワードファイルまたはPKI(Public Key Infrastructure)の証明書などを検証して、ユーザの本人性を認証する。
【0032】
そして、認証エージェント36は、正当なユーザであると判別した場合、正当なユーザであることを証明する認証応答(認証アサーション)を、制御部32に発行する(S13)。制御部32は、認証応答を受け付けて、認可決定部33に認可要求を送出する(S14)。
【0033】
認可決定部33は、ポリシーファイル34を参照し、認可決定に必要なユーザ属性を特定する。そして、認可決定部33は、特定したユーザ属性を、属性エージェント38に要求する(S15)。
【0034】
属性エージェント38は、ユーザ属性DB39を参照し、要求されたユーザ属性のユーザ属性情報を取得する。そして、属性エージェント38は、取得したユーザ属性情報を含む属性応答(属性アサーション)を、認可決定部33に送出する(S16)。
【0035】
そして、認可決定部33は、ポリシーファイル34に記憶されたポリシーのルールを参照し、取得したユーザ属性情報が当該ルールに適合するか否かを判定する(S17)。ポリシーのルールに適合する場合(S17:YES)、認可決定部33は、クライアント1のアクセスを許可する決定をする。なお、アクセス許可の決定後の処理については、図5を用いて後述する。
【0036】
一方、ポリシーのルールに適合しない場合(S17:NO)、認可決定部33は、クライアント1のアクセスを拒否する決定をする。そして、認可決定部33は、アクセス拒否の判定結果を含む認可応答(認可アサーション)を、制御部32に送出する(S18)。そして、制御部32は、アクセス拒否の認可応答を受け付けて、アプリケーションサーバ2にアクセス拒否の応答を送信する(S19)。
【0037】
アプリケーションサーバ2のアクセス制御部23は、アクセス拒否の応答を受信し、要求元のクライアント1にアクセス権限がない旨を示すエラーメッセージを送信する(S20)。
【0038】
図5は、アクセス許可の決定後(S17:YES)の処理のフローチャートである。
【0039】
認可決定部33は、ポリシーファイル34を参照し、ポリシーの責務34cを取得する(S21)。本実施形態の責務は、ユーザ属性情報を業務処理部24に引き渡すこととを、アプリケーションサーバ2のPEP21に指示するものである。そして、認可決定部33は、アクセス許可の判定結果と責務とを含む認可応答(認可アサーション)を、制御部32に送出する(S22)。
【0040】
図6は、認可応答のメッセージの一例を示したものである。図示するメッセージでは、ユーザ属性のメールアドレスと電話番号とを取得する責務61が記述されている。
【0041】
そして、制御部32は、アクセス許可の認可応答を受け付け、当該認可応答に含まれる責務に基づいて、ユーザ属性情報を属性エージェント38に要求する(S23)。
【0042】
属性エージェント38は、ユーザ属性DB39を参照し、要求されたユーザ属性情報を取得する。そして、属性エージェント38は、取得したユーザ属性情報を含む属性応答(属性アサーション)を、制御部32に送出する(S24)。
【0043】
図7は、属性応答のメッセージの一例を示したものである。図示するメッセージには、属性DB39から取得したメールアドレスと電話番号のユーザ属性情報が記述されている。
【0044】
そして、制御部32は、アクセス許可の判定結果と、責務のユーザ属性情報と、を含むアクセス許可の応答を、アプリケーションサーバ2に送信する(S25)。
【0045】
図8は、アクセス許可の応答メッセージの一例を示した図である。図示するメッセージには、アプリケーションサーバ2に引き渡すメールアドレスと電話番号のユーザ属性情報が記述されている。
【0046】
アプリケーションサーバ2のアクセス制御部23は、アクセス許可の応答を受信し、クライアント1から要求されたリソースへアクセスを許可する制御を行う(S26)。また、アクセス制御部23は、認証サーバ3から受信したユーザ属性情報を、業務処理部24に引き渡す責務を実行する(S27)。具体的には、アクセス制御部23は、業務処理部24が利用するメモリ領域に、受信したユーザ属性情報を設定する。
【0047】
業務処理部24は、クライアントが要求したリソース先(例えば、Webページ)をクライアントに送信するとともに、認証サーバ3から引き渡されたユーザ属性情報をクライアント1に送信する。
【0048】
以上、本発明の一実施形態を説明した。
【0049】
本実施形態では、認証サーバ3が、アプリケーションサーバ2のアクセス可否の問い合わせに対して、アクセス可否の判断を行うとともに、アプリケーションサーバ2の業務処理部24が必要とするユーザ属性情報を送信する。これにより、アプリケーションサーバ2の処理負荷を軽減し、必要なユーザ属性情報をアプリケーションサーバ2に効率良く引き渡すことができる。また、アプリケーションサーバ2と認証サーバ3間でのネットワークトラフィックの増加を抑制することができる。
【0050】
また、本実施形態では、認証サーバ3の制御部32が、ポリシーファイル34に設定された責務に基づいて、アプリケーションサーバ2に引き渡すユーザ属性情報を取得する。したがって、認証サーバ3では、アプリケーションサーバ2の実装言語各々に対応する仕組みを備える必要がない。
【0051】
また、本実施形態では、認証サーバ3の認可決定部33がアクセス許可の決定をした場合にのみ、アプリケーションサーバ2に引き渡すユーザ属性情報を取得する。すなわち、アクセス拒否の決定の場合は、不要なユーザ属性情報を取得しないため、認証サーバ3の処理負荷を軽減することができる。
【0052】
なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【図面の簡単な説明】
【0053】
【図1】本発明の一実施形態が適用されたアクセス制御システムの全体構成を示す図である。
【図2】各装置のハードウェア構成例を示す図である。
【図3】ポリシーファイルに記憶されたポリシーの一例を示す図である。
【図4】アクセス制御処理のフローチャートである。
【図5】アクセス制御処理のフローチャートである。
【図6】認可応答メッセージの一例を示す図である。
【図7】属性応答メッセージの一例を示す図である。
【図8】アクセス許可応答メッセージの一例を示す図である。
【符号の説明】
【0054】
1:クライアント、2:アプリケーションサーバ、21:PEP、22:認証要求部、23:アクセス制御部、24:業務処理部、3:認証サーバ、31:PDP、32:制御部、33:認可決定部、34:ポリシーファイル、36:認証エージェント、37:認証DB、38:属性エージェント、39:ユーザ属性DB、4:第1のネットワーク、4:第2のネットワーク




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013