Ｗｅｂサービスのアクセス制御システム
【課題】
Webサービスへのアクセス制御の均質な適用及び効率的なアクセス制御ができるシステムを提供することを目的とする。
【解決手段】
Webサービスやメッセージに対してアクセス権を設定するアクセス権設定装置と、Policyを配置するPolicyサーバと、ワークフローに従ってWebサービスを連係して実行するBPELサーバとを備える。ユーザが作成したワークフローを解析して資源の情報を抽出し、それらの資源に対するアクセス権設定を行う。設定されたアクセス権を示すPolicyをPolicyサーバ配置し、そのPolicyからアクセス制御サービスを実行するプログラムを作成する。ワークフローに対してはそのプログラムを呼び出す記述を追加し、そのワークフローとプログラムをBPELサーバに配置する。ワークフロー実行時は、ワークフローに沿って該プログラムを実行することにより、Policyに従ったアクセス制御が実現される。
Webサービスへのアクセス制御の均質な適用及び効率的なアクセス制御ができるシステムを提供することを目的とする。
【解決手段】
Webサービスやメッセージに対してアクセス権を設定するアクセス権設定装置と、Policyを配置するPolicyサーバと、ワークフローに従ってWebサービスを連係して実行するBPELサーバとを備える。ユーザが作成したワークフローを解析して資源の情報を抽出し、それらの資源に対するアクセス権設定を行う。設定されたアクセス権を示すPolicyをPolicyサーバ配置し、そのPolicyからアクセス制御サービスを実行するプログラムを作成する。ワークフローに対してはそのプログラムを呼び出す記述を追加し、そのワークフローとプログラムをBPELサーバに配置する。ワークフロー実行時は、ワークフローに沿って該プログラムを実行することにより、Policyに従ったアクセス制御が実現される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Webサービスにおけるアクセス制御技術に関するものである。
【背景技術】
【０００２】
企業の業務システムでは、流通チャンネルとの連携やグループ企業との情報インフラ強化など、企業の内外を問わずシステム間の連携が進んでいる。多くの企業は、システム連携を行うアーキテクチャとして、拡張性・信頼性が高いSOA (Service Oriented Architecture )を採用している。
【０００３】
SOAは、複数のWebサービスをワークフロー(記述言語WS-BPEL(Web Services Business Process Execution Language))によって連携させるためのアーキテクチャである。SOAでは、Webサービス同士の柔軟な組み合わせを実現するために、様々な技術が提案されており、その一つにMOM(Message Oriented Middleware)がある。これは、Webサービス同士が互いに相手のインターフェイスを直接呼び出すのではなく、事前に決められたフローの中で共通に利用される特定の話題に関する情報が階層状に記述されている(Topic Hierarchyな)XML形式のメッセージをWebサービス間で受渡す手法である。すなわち、ワークフローエンジンがWebサービスを呼び出す(invoke)ときに、Topic HierarchyなXMLメッセージ全体または一部分から、XSLT (XSL Transformations)などの技術を利用して、呼び出すWebサービスのインターフェイスに適したXMLメッセージを生成し呼び出す。さらに、Webサービスからの応答メッセージを取得したワークフローエンジンは、応答メッセージの情報をTopic HierarchyなXMLメッセージに反映させる。この手法によって、一つのWebサービスのインターフェイス変更は、局所的なメッセージ変換だけで済むので、フロー全体に影響を与えることがなくなる。結果として、MOMはWebサービスの柔軟な変更や組み換えを実現している。
【０００４】
このようなSOAを業務系システムに適用するには、Webサービスやメッセージに対するRBAC (Role Based Access Control)は必須であり、そのための標準規格として標準化団体OASIS(Organization for the Advancement of Structured Information Standards)が推進しているXACML (eXtensible Access Control Markup Language)が存在する。
【０００５】
図１は、XACMLによるWebサービス１２２へのアクセス制御方法を説明する図である。Policy Set１３２には、事前にどの様な主体がどの資源に対してどの様な操作を行うのを許可または不許可するのかを記述したPolicyの集合（XACMLで記述されている）が保管されている。Webサービスクライアントやワークフローエンジンであるアクセスリクエスタ１１０は、Webサービスサーバ１２０に対してWebサービス１２２によるサービスを要求する(Step１０１)。リクエストを取得したPEP (Policy Enforcement Point)１２１は、Policyサーバ１３０のPDP (Policy Decision Point)１３１に対して許可決定要求を行う。PDP１３１は、その要求事項とPolicy Set１３２とを比較し、要求の許可(Permit)または不許可(Deny)の決定をPEP１２１に応答する(Step１０２)。PDP１３１から要求の許可の応答を得たPEP１２１は、当該アクセスリクエスタ１１０からの要求に対してWebサービス１２２の実行を許可する(Step１０３)。以上のようにして、XACMLはアクセス制御を行う。
【非特許文献１】eXtensible Access Control Markup Language (XACML) Version2.0 Committee draft 04, 6 Dec 2004
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上述したようなアクセス制御をSOAに適用する場合、次の２つの問題点がある。
【０００７】
第１に、均質なアクセス制御の適用の問題がある。SOAへのアクセス制御適用には、アクセス制御を必要とする全てのWebサービスに対して、Policyに変更があっても柔軟に対応できる均質なPEPを適用する仕組みが必要である。しかしながら、従来のPEPは、図１のように各Webサービスに組み込む形で実装されているため、その品質はWebサービスの開発者に依存する。従って、Policyが変更され新たなWebサービスにアクセス制御を適用したり、PDPへの問い合わせ方法が変更されたりした場合、PEP部分を変更せざるを得ず、そのためWebサービスまでもシステム変更せざるを得ない。このように従来の手法では、均質なアクセス制御の仕組みをWebサービスに適用できないという問題があった。
【０００８】
第２に、アクセス権問い合わせのコストについての問題がある。PEPからPDPへの認可決定要求は、属性を持ったユーザである主体(Subject)がWebサービス或いはメッセージの一部または全体の資源(Resources)に対して実行・読み込み・書き込みなどの動作(Actions)を行えるかをXML形式で表現したメッセージを送信する。そのため、非常に複雑なアクセス制御の設定がなされている場合、メッセージのデータ量は大きくなり、ネットワークの負荷の増大やWebサービス実行の遅延などの悪影響を及ぼすという問題があった。
【０００９】
本発明の目的は、Webサービスへのアクセス制御の均質な適用及び効率的なアクセス制御ができるシステムを提供することにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、本発明は、Webサービスやメッセージに対してアクセス権を設定するアクセス権設定装置と、Policyを配置するPolicyサーバと、ワークフローに従ってWebサービスを連係して実行するBPELサーバとを備えるWebサービスのアクセス制御システムであって、前記アクセス権設定装置は、ユーザがBPEL(Business Process Execution Language)で作成したワークフローを解析し、該ワークフローからWebサービスに係る資源の情報とメッセージに係る資源の情報を抽出する手段と、抽出したWebサービスに係る資源とメッセージに係る資源に対してどのような主体がどのような動作を行うことを許可または不許可とするかを示すアクセス権設定を行う手段と、設定されたアクセス権を示すPolicyを前記Policyサーバに配置する手段と、前記Policyからアクセス制御サービスを実行するプログラムを作成する手段と、前記ワークフローに対して、前記アクセス制御サービスを実行するプログラムを呼び出す記述を追加する手段と、前記ワークフローと前記アクセス制御サービスを実行するプログラムを前記BPELサーバに配置する手段とを備え、前記BPELサーバは、Webサービスクライアントからのサービス要求に応じて、前記ワークフローに従いWebサービスを連係して実行することにより、Webサービスを呼び出して利用する手段と、Webサービスを連係して実行する際、前記ワークフロー中に追加されている前記アクセス制御サービスを実行するプログラムの呼び出しを行い、これにより前記ワークフローに従って利用するWebサービスやメッセージに対してアクセス制御を行う手段と、前記Webサービスクライアントに前記ワークフローの実行結果を返す手段とを備えることを特徴とする。
【００１１】
ワークフローを解析して資源の情報を抽出する際には、例えば、ワークフローのタグvariable, assign, invokeからアクセス制御の対象となる、全てのメッセージとWebサービス及びそれらの関係を抽出するようにする。PolicyはXACMLに基づいて作成すればよい。ワークフローに対して、アクセス制御サービスを実行するプログラムを呼び出す記述を追加するときには、Webサービスを呼び出す部分の前後でアクセス制御が行われるようにタグの挿入及び必要な変更を行えばよい。アクセス制御を行う前にPolicyの変更の有無をPolicyサーバに問い合わせ、Policyの変更があるときには、変更後のPolicyに応じたアクセス制御サービスを実行するプログラムの生成を配置のし直しを行うようにする。
【発明の効果】
【００１２】
本発明のアクセス制御システムによれば、次のような効果がある。
【００１３】
第１に、均質なアクセス制御の適用が実現される。ログやトランザクション処理などの横断的な関心事項をシステムに自動的に組込むアスペクト指向の考え方をワークフローに適用し、アクセス制御という横断的な関心事をBPELで記述されたワークフローに自動的に組込むことで、アクセス制御を漏れなく適用でき、またワークフローとアクセス制御を分離したことでPolicyの変化に対しても柔軟に対応できる。
【００１４】
第２に、アクセス権問い合わせのコストを削減できる。アクセス制御を行うプログラムをPolicy Setから自動的に生成することで、どんなにアクセス制御が複雑であっても、通常ワークフロー中で一度PolicyサーバにPolicy Setの更新の有無を問い合わせるだけで済むようになり、アクセス権の問い合わせのコストを大幅に削減することができる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明を適用したアクセス制御システムの一実施の形態について説明する。
【００１６】
図２は、本発明の実施の形態の一例を示すシステム構成図である。本実施形態のアクセス制御システムは、アクセス制御に関するPolicyを設定するPolicy設定PC２４０、設定したPolicyを保持するPolicyサーバ２２０、サービス要求を行うWebサービスクライアント２１０、BPELで記述されたワークフローを実行するBPELサーバ２３０、及び、Webサービス２５１を提供するWebサービスサーバ２５０を備える。
【００１７】
Policy設定PC２４０は、ネットワークを通した通信を行う通信部２４１、ユーザがワークフローのBPELでの記述やPolicyの設定を行う入出力部２４２、及び、各種制御を行う制御部２４５を備える。制御部２４５は、ユーザが記述したワークフローの解析及び変更を行うBPEL解析部２４６、ユーザが設定したPolicyの解析やPolicyサーバへの配置を行うPolicy設定制御部２４７、並びに、アクセス制御を行うアクセス制御サービスの生成及び配置を行うアクセス制御サービス制御部２４８を備える。
【００１８】
Policyサーバ２２０は、ネットワークを通した通信を行う通信部２２１、Policyを保存しておくPolicy Set２２２、各種制御を行う制御部２２５、及び、アクセス要求の許認可を決定するPDP２２６を備える。
【００１９】
BPELサーバ２３０は、ネットワークを通した通信を行う通信部２３１、及び、各種制御を行う制御部２３５を備える。制御部２３５は、BPELで記述されたワークフローを実行するBPEL実行制御部２３６、及び、アクセス制御を行うアクセス制御部２３７を備える。なお、BPELサーバ２３０がワークフローを実行する際に複数のWebサービスを呼び出す場合はそれら複数のWebサービスが存在することになるが、ここでは１台のWebサービスサーバ２５０の１つのWebサービス２５１のみを図示して他は省略した。
【００２０】
図２のシステムにおいて、Webサービスにアクセス制御を適用して実行する過程は、(1) Policyの設定、(2) アクセス制御の実行、の２つの段階から構成される。
【００２１】
まず、(1) Policyの設定について説明する。
【００２２】
図３は、Policy設定PC２４０がPolicyの設定を行う過程を表したフローチャートである。最初にユーザが入出力部２４２を用いてワークフローをBPELで記述する（ステップ３０１）。
【００２３】
図５（ａ）に、BPELで記述したワークフローの定義例（BPELインスタンスの例）SimpleProcess.bpelを示す。５０１は、このワークフローで利用するWebサービスの記述である。この例では、利用するWebサービスとしてsomeWebServiceを記述している。５０２は、XML型式のメッセージのやりとりに利用する変数の定義の記述である。ここではcommonValueを大域的な変数として使用し、request及びresponseを局所的な変数として使うものとする。各変数には５０２でそれぞれエレメントが指定されている。エレメントcommonMessage、serviceRequestMessage、serviceResponseMessageは、図５（ｂ）のSimpleProcess.xsdにおいて、それぞれ５０６、５０７、５０８のようにXML Schemaで定義されている。
【００２４】
<sequence name="main">から</sequence>までが、ワークフローの処理を定義している。５０３は、assignBeforeの名前で、変数commonValueからrequestへデータをコピーする処理を定義している。commonValueとrequestはそれぞれのメッセージタイプに応じた構造を持ち、ここではcommonValueの下位の/common/p1からrequestの下位のparameter1へデータコピーすることを定義している。５０４は、invoke1の名前でWebサービスであるsomeWebServiceを呼び出す処理を定義しているものであり、変数requestを入力としresponseを出力と指定している。５０５は、assignAfterの名前で、変数responseからcommonValueへデータをコピーする処理を定義している。特に、responseの下位のparameter2からcommonValueの下位の/common/p1へデータコピーし、responseの下位のparameter3からcommonValueの下位の/common/p2へデータコピーすることを定義している。なお、ここではワークフローの処理として５０３〜５０５のみを図示したが、これらの処理の前後にも各種の処理が記述されているものである。
【００２５】
ステップ３０１で図５のようなワークフロー定義を作成した後、BPEL解析部２４６は、このようにBPELで記述されたワークフローから資源（Webサービス及びメッセージ（変数））の情報を抽出する（ステップ３０２）。具体的には、BPELインスタンスの<partnerLinks>, <variables>から抽出すればよい。例えば図５の例では、Webサービスの資源として「sampleProcessProvider」と「someWebServiceProvider」が抽出され、メッセージをやりとりするための変数の資源として「commonValue」、「request」、及び「response」が抽出される。次に、Policy設定制御部２４７は、ユーザによって入出力部２４２を通してこれらの資源に対して設定されたアクセス権に関するPolicyを取得する（ステップ３０３）。
【００２６】
図６に、入出力部２４２におけるアクセス権設定画面を示す。ステップ３０２で抽出された資源に対して主体と動作が設定できるようになっている。６０１はWebサービスの資源に対するアクセス権設定を行うウインドウを示し、６０２はメッセージ（変数）に対するアクセス権設定を行うウインドウを示す。この例では、図５のBPELインスタンスから抽出したWebサービスの資源「sampleProcessProvider」に対して主体「manager」が「実行許可」され、「sampleProcessProvider」に対して主体「employee」が「実行拒否」され、「someWebServiceProvider」に対して主体「salesManager」が「実行許可」されるように、設定されている。また、「someWebServiceProvider」に対して主体「salesManager」が「実行許可」されているが、この主体がこのWebサービスを実行する場合に使用する変数「commonValue」に関して、「common/p1」に対しては「read」と「write」が許可され、「common/p2」に対しては「write」が許可されるように、アクセス権が設定されている。
【００２７】
図７は、図６で設定したPolicyの内容の一部であるメッセージに対するアクセス権をXACMLで記述した例である。７０１は主体、７０２は資源、７０３は上記主体が上記資源に対してどのような動作を行うか、をそれぞれ記述している。この例では、図６の画面での設定に応じて、「salesManager」が「commonValue」の下位の「common/p1」に対して「read」及び「write」が可能であると定義している。なお、「common/p2」については省略したが、図６の設定に応じて、「salesManager」が「commonValue」の下位の「common/p2」に対して「write」可能との記述が、図７と同様にして記述されているものとする。また、Policyにはこの他に、図６の「サービスに対するアクセス権設定」で設定した内容を同様に記述したサービスに対するアクセス権に関するPolicyが存在する。
【００２８】
ステップ３０３で上述したようなPolicy（図７）を作成したら、制御部２４５は、通信部２４１を通して当該PolicyをPolicyサーバ２２０に送信する。Policyを受信したPolicyサーバ２２０の制御部２２５は、当該PolicyをPolicy Set２２２に保存する（ステップ３０４）。次に、Policy設定PC２４０のアクセス制御サービス制御部２４８は、Policyサーバ２２０のPolicy Set２２２からPolicyを取得して、当該Policyに従うアクセス制御に必要なアクセス制御サービスを生成する（ステップ３０５）。BPEL解析部２４６は、ユーザが作成したワークフロー（図５）に、ステップ３０５で作成したアクセス制御サービスを実行させるためのコードを記述する（ステップ３０６）。
【００２９】
ステップ３０５，３０６の処理について、さらに詳しく説明する。
【００３０】
図８は、ステップ３０５の処理によりアクセス制御サービス制御部２４８が生成したクラスを示す。予めステップ３０２のワークフロー解析処理により図５の５０３のデータコピー処理は解析されており、一方、このデータコピー処理で使用する変数commonValueには図７のようにsalesManagerが使用する際のアクセス制御が定義されている。そこで、アクセス制御サービス制御部２４８は、ステップ３０５の処理で、図５の記述５０３のコピー処理を行う際のアクセス制御を実現するためのクラスを、図８の８０１のように生成する。このAssignBeforeClass８０１では、主体がsalesManagerのときのみRequest.Parameter1＝CommonValue.Common.P1を実行する関数assignが定義されている。
【００３１】
同様にして、アクセス制御サービス制御部２４８は、ステップ３０５の処理で、図５の記述５０５のコピー処理を行う際のアクセス制御を実現するためのクラスを、図８の８０２のように生成する。このAssignAfterClass８０２では、主体がsalesManagerのときのみCommonValue.Common.P1＝Response.Parameter2とCommonValue.Common.P2＝Response.Parameter3を実行する関数assignが定義されている。
【００３２】
図９は、BPEL解析部２４６がステップ３０６の処理により、図５のBPELインスタンスを変更して、図６のアクセス制御サービスを実行するための仕組みを挿入した例である。９０１，９０２，９０４の記述は、図５の５０１，５０２，５０４と同じである。既にステップ３０５で図６におけるアクセス権設定に応じたクラスを生成してあるので、これに伴って、someWebServiceを呼び出している部分９０４の前後の記述を、図５の記述５０３，５０５から、図８のアクセス制御プログラムを実行する記述９０３，９０５に入れ替えている。
【００３３】
以上の処理の後、制御部２４５は、通信部２４１からBPELサーバ２３０のBPEL実行制御部２３６にステップ３０６で変更したワークフロー（図９）を配置し、アクセス制御部２３７にステップ３０５で作成したアクセス制御サービス（図８）を配置する（ステップ３０７）。
【００３４】
以上で、Policyの設定が完了した。
【００３５】
次に、(2)アクセス制御の実行について説明する。
【００３６】
図４は、Webサービスクライアント２１０からのリクエストによりBPELサーバ２３０がワークフローのプロセスを実行するときのシーケンス図である。図４を用いて、本実施形態のシステムにおけるアクセス制御方法を説明する。
【００３７】
Webサービスクライアント２１０は、BPELサーバ２３０に対してサービス要求を行う（ステップ４０１）。BPELサーバ２３０の制御部２３５は、そのサービス要求を行ったユーザの認証及び役割の特定を行う（ステップ４０２）。認証が成功した場合、アクセス制御部２３７が、Policyサーバ２２０に対してPolicy更新の有無の確認を行う（ステップ４０３）。確認要求を受信したPolicyサーバ２２０の制御部２２５は、Policy Set２２２を参照して、変更の有無の応答を返す。Policyに変更がないことを確認した場合は、BPELサーバ２３０のBPEL実行制御部２３６が、ワークフローのプロセスを実行する。もし、変更があった場合は、ステップ３０５と同じアルゴリズムでアクセス制御サービスを生成し、以前のものを更新する（ステップ４０３）。
【００３８】
次に、BPEL実行制御部２３６は、指定されたワークフロー（例えば図９）に従ってWebサービスを呼び出す。特に、BPEL実行制御部２３６がWebサービス２５１を呼び出す(invoke)ときなどには、アクセス制御部２３７はステップ３０５で作成したアクセス制御サービス（図８）を用いて、Webサービス及びそのWebサービスに渡すパラメータのアクセス制御を行う（ステップ４０４）。BPEL実行制御部２３６は、ステップ４０４でアクセス制御を行った上で、Webサービスサーバ２５０上のWebサービス２５１を呼び出す（ステップ４０５）。Webサービス２５１の結果を共通メッセージ（ここでは広域的に用いている変数）に反映させるときも、アクセス制御部２３７は、アクセス制御を行う（ステップ４０６）。BPEL実行制御部２３６は、ワークフローのプロセスの実行結果をWebサービスクライアント２１０に返す（ステップ４０７）。
【図面の簡単な説明】
【００３９】
【図１】従来のアクセス制御の一実施形態例を示すシステム構成図である。
【図２】本発明の一実施の形態例を示すシステム構成図である。
【図３】Policy設定処理の概要を示すフローチャートである。
【図４】アクセス制御実行時のシーケンス図である。
【図５（ａ）】ワークフローをBPELで記述した記述例（その１）である。
【図５（ｂ）】ワークフローをBPELで記述した記述例（その２）である。
【図６】サービス及びメッセージに対してアクセス権を設定する画面例である。
【図７】サービス及びメッセージに対して設定されたアクセス権に関するPolicyをXACMLで記述した記述例である。
【図８】アクセス制御サービスを行うプログラム例である。
【図９】アクセス制御の仕組みが組込まれたBPELインスタンスの例である。
【符号の説明】
【００４０】
２１０…Webサービスクライアント、２２０…Policyサーバ、２３０…BPELサーバ、２４０…Policyサーバ、２５０…Webサービスサーバ。
【技術分野】
【０００１】
本発明は、Webサービスにおけるアクセス制御技術に関するものである。
【背景技術】
【０００２】
企業の業務システムでは、流通チャンネルとの連携やグループ企業との情報インフラ強化など、企業の内外を問わずシステム間の連携が進んでいる。多くの企業は、システム連携を行うアーキテクチャとして、拡張性・信頼性が高いSOA (Service Oriented Architecture )を採用している。
【０００３】
SOAは、複数のWebサービスをワークフロー(記述言語WS-BPEL(Web Services Business Process Execution Language))によって連携させるためのアーキテクチャである。SOAでは、Webサービス同士の柔軟な組み合わせを実現するために、様々な技術が提案されており、その一つにMOM(Message Oriented Middleware)がある。これは、Webサービス同士が互いに相手のインターフェイスを直接呼び出すのではなく、事前に決められたフローの中で共通に利用される特定の話題に関する情報が階層状に記述されている(Topic Hierarchyな)XML形式のメッセージをWebサービス間で受渡す手法である。すなわち、ワークフローエンジンがWebサービスを呼び出す(invoke)ときに、Topic HierarchyなXMLメッセージ全体または一部分から、XSLT (XSL Transformations)などの技術を利用して、呼び出すWebサービスのインターフェイスに適したXMLメッセージを生成し呼び出す。さらに、Webサービスからの応答メッセージを取得したワークフローエンジンは、応答メッセージの情報をTopic HierarchyなXMLメッセージに反映させる。この手法によって、一つのWebサービスのインターフェイス変更は、局所的なメッセージ変換だけで済むので、フロー全体に影響を与えることがなくなる。結果として、MOMはWebサービスの柔軟な変更や組み換えを実現している。
【０００４】
このようなSOAを業務系システムに適用するには、Webサービスやメッセージに対するRBAC (Role Based Access Control)は必須であり、そのための標準規格として標準化団体OASIS(Organization for the Advancement of Structured Information Standards)が推進しているXACML (eXtensible Access Control Markup Language)が存在する。
【０００５】
図１は、XACMLによるWebサービス１２２へのアクセス制御方法を説明する図である。Policy Set１３２には、事前にどの様な主体がどの資源に対してどの様な操作を行うのを許可または不許可するのかを記述したPolicyの集合（XACMLで記述されている）が保管されている。Webサービスクライアントやワークフローエンジンであるアクセスリクエスタ１１０は、Webサービスサーバ１２０に対してWebサービス１２２によるサービスを要求する(Step１０１)。リクエストを取得したPEP (Policy Enforcement Point)１２１は、Policyサーバ１３０のPDP (Policy Decision Point)１３１に対して許可決定要求を行う。PDP１３１は、その要求事項とPolicy Set１３２とを比較し、要求の許可(Permit)または不許可(Deny)の決定をPEP１２１に応答する(Step１０２)。PDP１３１から要求の許可の応答を得たPEP１２１は、当該アクセスリクエスタ１１０からの要求に対してWebサービス１２２の実行を許可する(Step１０３)。以上のようにして、XACMLはアクセス制御を行う。
【非特許文献１】eXtensible Access Control Markup Language (XACML) Version2.0 Committee draft 04, 6 Dec 2004
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上述したようなアクセス制御をSOAに適用する場合、次の２つの問題点がある。
【０００７】
第１に、均質なアクセス制御の適用の問題がある。SOAへのアクセス制御適用には、アクセス制御を必要とする全てのWebサービスに対して、Policyに変更があっても柔軟に対応できる均質なPEPを適用する仕組みが必要である。しかしながら、従来のPEPは、図１のように各Webサービスに組み込む形で実装されているため、その品質はWebサービスの開発者に依存する。従って、Policyが変更され新たなWebサービスにアクセス制御を適用したり、PDPへの問い合わせ方法が変更されたりした場合、PEP部分を変更せざるを得ず、そのためWebサービスまでもシステム変更せざるを得ない。このように従来の手法では、均質なアクセス制御の仕組みをWebサービスに適用できないという問題があった。
【０００８】
第２に、アクセス権問い合わせのコストについての問題がある。PEPからPDPへの認可決定要求は、属性を持ったユーザである主体(Subject)がWebサービス或いはメッセージの一部または全体の資源(Resources)に対して実行・読み込み・書き込みなどの動作(Actions)を行えるかをXML形式で表現したメッセージを送信する。そのため、非常に複雑なアクセス制御の設定がなされている場合、メッセージのデータ量は大きくなり、ネットワークの負荷の増大やWebサービス実行の遅延などの悪影響を及ぼすという問題があった。
【０００９】
本発明の目的は、Webサービスへのアクセス制御の均質な適用及び効率的なアクセス制御ができるシステムを提供することにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、本発明は、Webサービスやメッセージに対してアクセス権を設定するアクセス権設定装置と、Policyを配置するPolicyサーバと、ワークフローに従ってWebサービスを連係して実行するBPELサーバとを備えるWebサービスのアクセス制御システムであって、前記アクセス権設定装置は、ユーザがBPEL(Business Process Execution Language)で作成したワークフローを解析し、該ワークフローからWebサービスに係る資源の情報とメッセージに係る資源の情報を抽出する手段と、抽出したWebサービスに係る資源とメッセージに係る資源に対してどのような主体がどのような動作を行うことを許可または不許可とするかを示すアクセス権設定を行う手段と、設定されたアクセス権を示すPolicyを前記Policyサーバに配置する手段と、前記Policyからアクセス制御サービスを実行するプログラムを作成する手段と、前記ワークフローに対して、前記アクセス制御サービスを実行するプログラムを呼び出す記述を追加する手段と、前記ワークフローと前記アクセス制御サービスを実行するプログラムを前記BPELサーバに配置する手段とを備え、前記BPELサーバは、Webサービスクライアントからのサービス要求に応じて、前記ワークフローに従いWebサービスを連係して実行することにより、Webサービスを呼び出して利用する手段と、Webサービスを連係して実行する際、前記ワークフロー中に追加されている前記アクセス制御サービスを実行するプログラムの呼び出しを行い、これにより前記ワークフローに従って利用するWebサービスやメッセージに対してアクセス制御を行う手段と、前記Webサービスクライアントに前記ワークフローの実行結果を返す手段とを備えることを特徴とする。
【００１１】
ワークフローを解析して資源の情報を抽出する際には、例えば、ワークフローのタグvariable, assign, invokeからアクセス制御の対象となる、全てのメッセージとWebサービス及びそれらの関係を抽出するようにする。PolicyはXACMLに基づいて作成すればよい。ワークフローに対して、アクセス制御サービスを実行するプログラムを呼び出す記述を追加するときには、Webサービスを呼び出す部分の前後でアクセス制御が行われるようにタグの挿入及び必要な変更を行えばよい。アクセス制御を行う前にPolicyの変更の有無をPolicyサーバに問い合わせ、Policyの変更があるときには、変更後のPolicyに応じたアクセス制御サービスを実行するプログラムの生成を配置のし直しを行うようにする。
【発明の効果】
【００１２】
本発明のアクセス制御システムによれば、次のような効果がある。
【００１３】
第１に、均質なアクセス制御の適用が実現される。ログやトランザクション処理などの横断的な関心事項をシステムに自動的に組込むアスペクト指向の考え方をワークフローに適用し、アクセス制御という横断的な関心事をBPELで記述されたワークフローに自動的に組込むことで、アクセス制御を漏れなく適用でき、またワークフローとアクセス制御を分離したことでPolicyの変化に対しても柔軟に対応できる。
【００１４】
第２に、アクセス権問い合わせのコストを削減できる。アクセス制御を行うプログラムをPolicy Setから自動的に生成することで、どんなにアクセス制御が複雑であっても、通常ワークフロー中で一度PolicyサーバにPolicy Setの更新の有無を問い合わせるだけで済むようになり、アクセス権の問い合わせのコストを大幅に削減することができる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明を適用したアクセス制御システムの一実施の形態について説明する。
【００１６】
図２は、本発明の実施の形態の一例を示すシステム構成図である。本実施形態のアクセス制御システムは、アクセス制御に関するPolicyを設定するPolicy設定PC２４０、設定したPolicyを保持するPolicyサーバ２２０、サービス要求を行うWebサービスクライアント２１０、BPELで記述されたワークフローを実行するBPELサーバ２３０、及び、Webサービス２５１を提供するWebサービスサーバ２５０を備える。
【００１７】
Policy設定PC２４０は、ネットワークを通した通信を行う通信部２４１、ユーザがワークフローのBPELでの記述やPolicyの設定を行う入出力部２４２、及び、各種制御を行う制御部２４５を備える。制御部２４５は、ユーザが記述したワークフローの解析及び変更を行うBPEL解析部２４６、ユーザが設定したPolicyの解析やPolicyサーバへの配置を行うPolicy設定制御部２４７、並びに、アクセス制御を行うアクセス制御サービスの生成及び配置を行うアクセス制御サービス制御部２４８を備える。
【００１８】
Policyサーバ２２０は、ネットワークを通した通信を行う通信部２２１、Policyを保存しておくPolicy Set２２２、各種制御を行う制御部２２５、及び、アクセス要求の許認可を決定するPDP２２６を備える。
【００１９】
BPELサーバ２３０は、ネットワークを通した通信を行う通信部２３１、及び、各種制御を行う制御部２３５を備える。制御部２３５は、BPELで記述されたワークフローを実行するBPEL実行制御部２３６、及び、アクセス制御を行うアクセス制御部２３７を備える。なお、BPELサーバ２３０がワークフローを実行する際に複数のWebサービスを呼び出す場合はそれら複数のWebサービスが存在することになるが、ここでは１台のWebサービスサーバ２５０の１つのWebサービス２５１のみを図示して他は省略した。
【００２０】
図２のシステムにおいて、Webサービスにアクセス制御を適用して実行する過程は、(1) Policyの設定、(2) アクセス制御の実行、の２つの段階から構成される。
【００２１】
まず、(1) Policyの設定について説明する。
【００２２】
図３は、Policy設定PC２４０がPolicyの設定を行う過程を表したフローチャートである。最初にユーザが入出力部２４２を用いてワークフローをBPELで記述する（ステップ３０１）。
【００２３】
図５（ａ）に、BPELで記述したワークフローの定義例（BPELインスタンスの例）SimpleProcess.bpelを示す。５０１は、このワークフローで利用するWebサービスの記述である。この例では、利用するWebサービスとしてsomeWebServiceを記述している。５０２は、XML型式のメッセージのやりとりに利用する変数の定義の記述である。ここではcommonValueを大域的な変数として使用し、request及びresponseを局所的な変数として使うものとする。各変数には５０２でそれぞれエレメントが指定されている。エレメントcommonMessage、serviceRequestMessage、serviceResponseMessageは、図５（ｂ）のSimpleProcess.xsdにおいて、それぞれ５０６、５０７、５０８のようにXML Schemaで定義されている。
【００２４】
<sequence name="main">から</sequence>までが、ワークフローの処理を定義している。５０３は、assignBeforeの名前で、変数commonValueからrequestへデータをコピーする処理を定義している。commonValueとrequestはそれぞれのメッセージタイプに応じた構造を持ち、ここではcommonValueの下位の/common/p1からrequestの下位のparameter1へデータコピーすることを定義している。５０４は、invoke1の名前でWebサービスであるsomeWebServiceを呼び出す処理を定義しているものであり、変数requestを入力としresponseを出力と指定している。５０５は、assignAfterの名前で、変数responseからcommonValueへデータをコピーする処理を定義している。特に、responseの下位のparameter2からcommonValueの下位の/common/p1へデータコピーし、responseの下位のparameter3からcommonValueの下位の/common/p2へデータコピーすることを定義している。なお、ここではワークフローの処理として５０３〜５０５のみを図示したが、これらの処理の前後にも各種の処理が記述されているものである。
【００２５】
ステップ３０１で図５のようなワークフロー定義を作成した後、BPEL解析部２４６は、このようにBPELで記述されたワークフローから資源（Webサービス及びメッセージ（変数））の情報を抽出する（ステップ３０２）。具体的には、BPELインスタンスの<partnerLinks>, <variables>から抽出すればよい。例えば図５の例では、Webサービスの資源として「sampleProcessProvider」と「someWebServiceProvider」が抽出され、メッセージをやりとりするための変数の資源として「commonValue」、「request」、及び「response」が抽出される。次に、Policy設定制御部２４７は、ユーザによって入出力部２４２を通してこれらの資源に対して設定されたアクセス権に関するPolicyを取得する（ステップ３０３）。
【００２６】
図６に、入出力部２４２におけるアクセス権設定画面を示す。ステップ３０２で抽出された資源に対して主体と動作が設定できるようになっている。６０１はWebサービスの資源に対するアクセス権設定を行うウインドウを示し、６０２はメッセージ（変数）に対するアクセス権設定を行うウインドウを示す。この例では、図５のBPELインスタンスから抽出したWebサービスの資源「sampleProcessProvider」に対して主体「manager」が「実行許可」され、「sampleProcessProvider」に対して主体「employee」が「実行拒否」され、「someWebServiceProvider」に対して主体「salesManager」が「実行許可」されるように、設定されている。また、「someWebServiceProvider」に対して主体「salesManager」が「実行許可」されているが、この主体がこのWebサービスを実行する場合に使用する変数「commonValue」に関して、「common/p1」に対しては「read」と「write」が許可され、「common/p2」に対しては「write」が許可されるように、アクセス権が設定されている。
【００２７】
図７は、図６で設定したPolicyの内容の一部であるメッセージに対するアクセス権をXACMLで記述した例である。７０１は主体、７０２は資源、７０３は上記主体が上記資源に対してどのような動作を行うか、をそれぞれ記述している。この例では、図６の画面での設定に応じて、「salesManager」が「commonValue」の下位の「common/p1」に対して「read」及び「write」が可能であると定義している。なお、「common/p2」については省略したが、図６の設定に応じて、「salesManager」が「commonValue」の下位の「common/p2」に対して「write」可能との記述が、図７と同様にして記述されているものとする。また、Policyにはこの他に、図６の「サービスに対するアクセス権設定」で設定した内容を同様に記述したサービスに対するアクセス権に関するPolicyが存在する。
【００２８】
ステップ３０３で上述したようなPolicy（図７）を作成したら、制御部２４５は、通信部２４１を通して当該PolicyをPolicyサーバ２２０に送信する。Policyを受信したPolicyサーバ２２０の制御部２２５は、当該PolicyをPolicy Set２２２に保存する（ステップ３０４）。次に、Policy設定PC２４０のアクセス制御サービス制御部２４８は、Policyサーバ２２０のPolicy Set２２２からPolicyを取得して、当該Policyに従うアクセス制御に必要なアクセス制御サービスを生成する（ステップ３０５）。BPEL解析部２４６は、ユーザが作成したワークフロー（図５）に、ステップ３０５で作成したアクセス制御サービスを実行させるためのコードを記述する（ステップ３０６）。
【００２９】
ステップ３０５，３０６の処理について、さらに詳しく説明する。
【００３０】
図８は、ステップ３０５の処理によりアクセス制御サービス制御部２４８が生成したクラスを示す。予めステップ３０２のワークフロー解析処理により図５の５０３のデータコピー処理は解析されており、一方、このデータコピー処理で使用する変数commonValueには図７のようにsalesManagerが使用する際のアクセス制御が定義されている。そこで、アクセス制御サービス制御部２４８は、ステップ３０５の処理で、図５の記述５０３のコピー処理を行う際のアクセス制御を実現するためのクラスを、図８の８０１のように生成する。このAssignBeforeClass８０１では、主体がsalesManagerのときのみRequest.Parameter1＝CommonValue.Common.P1を実行する関数assignが定義されている。
【００３１】
同様にして、アクセス制御サービス制御部２４８は、ステップ３０５の処理で、図５の記述５０５のコピー処理を行う際のアクセス制御を実現するためのクラスを、図８の８０２のように生成する。このAssignAfterClass８０２では、主体がsalesManagerのときのみCommonValue.Common.P1＝Response.Parameter2とCommonValue.Common.P2＝Response.Parameter3を実行する関数assignが定義されている。
【００３２】
図９は、BPEL解析部２４６がステップ３０６の処理により、図５のBPELインスタンスを変更して、図６のアクセス制御サービスを実行するための仕組みを挿入した例である。９０１，９０２，９０４の記述は、図５の５０１，５０２，５０４と同じである。既にステップ３０５で図６におけるアクセス権設定に応じたクラスを生成してあるので、これに伴って、someWebServiceを呼び出している部分９０４の前後の記述を、図５の記述５０３，５０５から、図８のアクセス制御プログラムを実行する記述９０３，９０５に入れ替えている。
【００３３】
以上の処理の後、制御部２４５は、通信部２４１からBPELサーバ２３０のBPEL実行制御部２３６にステップ３０６で変更したワークフロー（図９）を配置し、アクセス制御部２３７にステップ３０５で作成したアクセス制御サービス（図８）を配置する（ステップ３０７）。
【００３４】
以上で、Policyの設定が完了した。
【００３５】
次に、(2)アクセス制御の実行について説明する。
【００３６】
図４は、Webサービスクライアント２１０からのリクエストによりBPELサーバ２３０がワークフローのプロセスを実行するときのシーケンス図である。図４を用いて、本実施形態のシステムにおけるアクセス制御方法を説明する。
【００３７】
Webサービスクライアント２１０は、BPELサーバ２３０に対してサービス要求を行う（ステップ４０１）。BPELサーバ２３０の制御部２３５は、そのサービス要求を行ったユーザの認証及び役割の特定を行う（ステップ４０２）。認証が成功した場合、アクセス制御部２３７が、Policyサーバ２２０に対してPolicy更新の有無の確認を行う（ステップ４０３）。確認要求を受信したPolicyサーバ２２０の制御部２２５は、Policy Set２２２を参照して、変更の有無の応答を返す。Policyに変更がないことを確認した場合は、BPELサーバ２３０のBPEL実行制御部２３６が、ワークフローのプロセスを実行する。もし、変更があった場合は、ステップ３０５と同じアルゴリズムでアクセス制御サービスを生成し、以前のものを更新する（ステップ４０３）。
【００３８】
次に、BPEL実行制御部２３６は、指定されたワークフロー（例えば図９）に従ってWebサービスを呼び出す。特に、BPEL実行制御部２３６がWebサービス２５１を呼び出す(invoke)ときなどには、アクセス制御部２３７はステップ３０５で作成したアクセス制御サービス（図８）を用いて、Webサービス及びそのWebサービスに渡すパラメータのアクセス制御を行う（ステップ４０４）。BPEL実行制御部２３６は、ステップ４０４でアクセス制御を行った上で、Webサービスサーバ２５０上のWebサービス２５１を呼び出す（ステップ４０５）。Webサービス２５１の結果を共通メッセージ（ここでは広域的に用いている変数）に反映させるときも、アクセス制御部２３７は、アクセス制御を行う（ステップ４０６）。BPEL実行制御部２３６は、ワークフローのプロセスの実行結果をWebサービスクライアント２１０に返す（ステップ４０７）。
【図面の簡単な説明】
【００３９】
【図１】従来のアクセス制御の一実施形態例を示すシステム構成図である。
【図２】本発明の一実施の形態例を示すシステム構成図である。
【図３】Policy設定処理の概要を示すフローチャートである。
【図４】アクセス制御実行時のシーケンス図である。
【図５（ａ）】ワークフローをBPELで記述した記述例（その１）である。
【図５（ｂ）】ワークフローをBPELで記述した記述例（その２）である。
【図６】サービス及びメッセージに対してアクセス権を設定する画面例である。
【図７】サービス及びメッセージに対して設定されたアクセス権に関するPolicyをXACMLで記述した記述例である。
【図８】アクセス制御サービスを行うプログラム例である。
【図９】アクセス制御の仕組みが組込まれたBPELインスタンスの例である。
【符号の説明】
【００４０】
２１０…Webサービスクライアント、２２０…Policyサーバ、２３０…BPELサーバ、２４０…Policyサーバ、２５０…Webサービスサーバ。
【特許請求の範囲】
【請求項１】
Webサービスやメッセージに対してアクセス権を設定するアクセス権設定装置と、Policyを配置するPolicyサーバと、ワークフローに従ってWebサービスを連係して実行するBPELサーバとを備えるWebサービスのアクセス制御システムであって、
前記アクセス権設定装置は、
ユーザがBPEL(Business Process Execution Language)で作成したワークフローを解析し、該ワークフローからWebサービスに係る資源の情報とメッセージに係る資源の情報を抽出する手段と、
抽出したWebサービスに係る資源とメッセージに係る資源に対してどのような主体がどのような動作を行うことを許可または不許可とするかを示すアクセス権設定を行う手段と、
設定されたアクセス権を示すPolicyを前記Policyサーバに配置する手段と、
前記Policyからアクセス制御サービスを実行するプログラムを作成する手段と、
前記ワークフローに対して、前記アクセス制御サービスを実行するプログラムを呼び出す記述を追加する手段と、
前記ワークフローと前記アクセス制御サービスを実行するプログラムを前記BPELサーバに配置する手段と
を備え、
前記BPELサーバは、
Webサービスクライアントからのサービス要求に応じて、前記ワークフローに従いWebサービスを連係して実行することにより、Webサービスを呼び出して利用する手段と、
Webサービスを連係して実行する際、前記ワークフロー中に追加されている前記アクセス制御サービスを実行するプログラムの呼び出しを行い、これにより前記ワークフローに従って利用するWebサービスやメッセージに対してアクセス制御を行う手段と、
前記Webサービスクライアントに前記ワークフローの実行結果を返す手段と
を備えることを特徴とするアクセス制御システム。
【請求項１】
Webサービスやメッセージに対してアクセス権を設定するアクセス権設定装置と、Policyを配置するPolicyサーバと、ワークフローに従ってWebサービスを連係して実行するBPELサーバとを備えるWebサービスのアクセス制御システムであって、
前記アクセス権設定装置は、
ユーザがBPEL(Business Process Execution Language)で作成したワークフローを解析し、該ワークフローからWebサービスに係る資源の情報とメッセージに係る資源の情報を抽出する手段と、
抽出したWebサービスに係る資源とメッセージに係る資源に対してどのような主体がどのような動作を行うことを許可または不許可とするかを示すアクセス権設定を行う手段と、
設定されたアクセス権を示すPolicyを前記Policyサーバに配置する手段と、
前記Policyからアクセス制御サービスを実行するプログラムを作成する手段と、
前記ワークフローに対して、前記アクセス制御サービスを実行するプログラムを呼び出す記述を追加する手段と、
前記ワークフローと前記アクセス制御サービスを実行するプログラムを前記BPELサーバに配置する手段と
を備え、
前記BPELサーバは、
Webサービスクライアントからのサービス要求に応じて、前記ワークフローに従いWebサービスを連係して実行することにより、Webサービスを呼び出して利用する手段と、
Webサービスを連係して実行する際、前記ワークフロー中に追加されている前記アクセス制御サービスを実行するプログラムの呼び出しを行い、これにより前記ワークフローに従って利用するWebサービスやメッセージに対してアクセス制御を行う手段と、
前記Webサービスクライアントに前記ワークフローの実行結果を返す手段と
を備えることを特徴とするアクセス制御システム。
【図１】
【図２】
【図３】
【図４】
【図５（ａ）】
【図５（ｂ）】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５（ａ）】
【図５（ｂ）】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２００７−４５２０（Ｐ２００７−４５２０Ａ）
【公開日】平成１９年１月１１日（２００７．１．１１）
【国際特許分類】
【出願番号】特願２００５−１８４４２９（Ｐ２００５−１８４４２９）
【出願日】平成１７年６月２４日（２００５．６．２４）
【出願人】（０００２３３０５５）日立ソフトウエアエンジニアリング株式会社 (1,610)
【Ｆターム（参考）】
【公開日】平成１９年１月１１日（２００７．１．１１）
【国際特許分類】
【出願日】平成１７年６月２４日（２００５．６．２４）
【出願人】（０００２３３０５５）日立ソフトウエアエンジニアリング株式会社 (1,610)
【Ｆターム（参考）】
[ Back to top ]