JP2008310760A - 情報処理システム、情報処理装置、およびプログラム - Google Patents

Abstract

【課題】操作要求の正当性を確実に確認できるようにすること。
【解決手段】第１ワークフロー装置１００は、操作要求対象に対して操作要求を送信するものである。コンテキスト記憶部２１は、操作要求に関してあるアクティビティが実行される毎にその内容を示すアクティビティ情報が登録されるコンテキストを記憶する。通信部１７は、操作要求記憶部２０に記憶される操作要求と、コンテキスト記憶部２１に記憶されるコンテキストとを、第２ワークフロー装置２００へ送信する。正当性検証部１６は、第２ワークフロー装置２００からの操作要求の正当性の検証要求があった場合、当該検証要求と共に第２ワークフロー装置２００から送信されてくるコンテキスト内の個々のアクティビティ情報とコンテキスト記憶部２１に記憶されているコンテキスト内の個々のアクティビティ情報とを比較することによって当該操作要求の正当性を検証する。
【選択図】 図３

Description

本発明は、操作要求の正当性の確認を行える情報処理システム、情報処理装置、およびプログラムに関する。

従来から、企業内において、コンピュータを利用してビジネスプロセスを促進あるいは自動化するワークフローシステムが利用されている。ワークフローシステムでは、ビジネスプロセス定義に従って、ある操作要求（例えば、新規アカウント登録に関する操作要求など）に関して担当者が電子的な処理による申請、承認、回覧等を行う。

このようなワークフローシステムでは、いつ・誰が申請・承認を行ったかを特定することが重要である。ワークフローの文書回覧や申請・承認行為における本人認証の方法も検討されており、その一例としては特許文献１が挙げられる。この特許文献１によれば、文書の閲覧・申請・承認等のデータ送信の際に、文書データと、作成者署名情報と、作成者証明書情報と、捺印枠情報とから構成される電子封筒を作成、送信する。閲覧者端末では、電子封筒に含まれる情報を検証することで文書作成者の本人証明や文書改ざんの有無を確認することができる。
特開２００６−１０７０９９号公報

しかしながら、上記特許文献１を含む従来技術においては、次に述べるような問題がある。

社内システムの大規模化や複雑化に伴い、ネットワークを介し、システムをまたがる環境でワークフロー処理が行われるため、必ずしも操作要求等のメッセージが同期実行されるとは限らない状況が発生する。例えば、あるシステム（以下、システムＡと記述する）から別のシステム（以下、システムＢと記述する）に対して、非同期の操作要求を送信したとする。一定期間経過後にシステムＢで操作要求を実行する際に、送信時と実行時の条件が変化する（異なる）場合もあり、操作要求を実行してはいけない状況が生じる可能性がある。よって、実行時点での操作要求が正当であるかどうかを確認する必要がある。

ここで、操作要求の正当性を次のように定義する。ある操作要求をシステムＡから送信するまでに行われる各アクティビティ（操作要求に関して行われるプロセス、申請、承認、差し戻しなどの処理）の状態、および各アクティビティに関与したアクティビティ実行者の各アクティビティ処理時の状態（役職、所属部署など）と、操作要求実行時の状態とを比較して、前者の各アクティビティの状態と後者の各アクティビティの状態とが変更されていない場合、あるいは前者の各アクティビティの状態が後者の各アクティビティの状態に比べて同レベル以上の状態にある場合、操作要求が正当であるものとする。

例えば、システムＡの担当者ａはシステムＢに対して操作要求できる権限を持っており、システムＢに対してバッチ処理のような操作要求を送信した後の時間経過後のある時点で一括実行するような場合を考える。操作要求の権限をもっていた担当者ａであるが、人事異動で別の組織に異動した場合は、実行する時点では操作要求できる権限がなくなっている。システムＢでは、実行時点での操作要求権限を確かめた上での操作を規定していた場合、担当者ａからの操作要求は実行できないことになる。操作要求が実行できないため、処理が保留になり、システムＡとシステムＢとの間で情報の不整合が発生する可能性がある。このような場合、システムＢはシステムＡからの通知がある、あるいはシステムＢが何らかの方法で操作要求実行時点での状態を確認することができる場合には操作要求を取り消すことができるが、通知がない場合にはシステムＡの担当者ａの部署異動を確認できない。これは、特に組織や企業間を横断する連携を行う場合に発生すると考えられる。

こうしたことから、操作要求を受信した主体がその操作要求が現在でも正当であるか否かを確実に確認できる技術の提示が望まれる。

本発明は上記実情に鑑みてなされたものであり、操作要求の正当性を確実に確認できる情報処理システム、情報処理装置、およびプログラムを提供することを目的とする。

本発明に係る情報処理システムは、操作要求対象に対して操作要求を送信する第１の情報処理装置と、前記第１の情報処理装置から送信される前記操作要求を受付ける第２の情報処理装置と、を含む情報処理システムであって、前記第１の情報処理装置は、前記操作要求に関してあるアクティビティが実行される毎にその内容を示すアクティビティ情報が登録されるコンテキストを記憶する記憶手段と、前記操作要求と前記記憶手段に記憶されるコンテキストとを前記第２の情報処理装置へ送信する手段とを具備し、前記第２の情報処理装置は、前記第１の情報処理装置から送信されてくる前記操作要求と前記コンテキストを受信する手段と、前記受信したコンテキストを前記第１の情報処理装置へ送信して前記受信した操作要求の正当性の検証を前記第１の情報処理装置に要求する手段とを具備し、前記第１の情報処理装置は、前記第２の情報処理装置からの検証要求があった場合、当該検証要求と共に送信されてくるコンテキスト内のアクティビティ情報と前記記憶手段に記憶されているコンテキスト内のアクティビティ情報とを比較することによって当該操作要求の正当性を検証する手段を具備することを特徴とする。

本発明に係る情報処理装置は、操作要求対象に対して操作要求を送信する情報処理装置であって、前記操作要求に関してあるアクティビティが実行される毎にその内容を示すアクティビティ情報が登録されるコンテキストを記憶する記憶手段と、前記操作要求と前記記憶手段に記憶されるコンテキストとを外部の装置へ送信する手段と、前記外部の装置からの検証要求があった場合、当該検証要求と共に送信されてくるコンテキスト内のアクティビティ情報と前記記憶手段に記憶されているコンテキスト内のアクティビティ情報とを比較することによって当該操作要求の正当性を検証する手段とを具備することを特徴とする。

本発明に係るプログラムは、操作要求対象に対して操作要求を送信するコンピュータに使用されるプログラムであって、前記操作要求に関してあるアクティビティが実行される毎にその内容を示すアクティビティ情報が登録されるコンテキストを記憶手段に記憶する機能と、前記操作要求と前記記憶手段に記憶されるコンテキストとを外部の装置へ送信する機能と、前記外部の装置からの検証要求があった場合、当該検証要求と共に送信されてくるコンテキスト内のアクティビティ情報と前記記憶手段に記憶されているコンテキスト内のアクティビティ情報とを比較することによって当該操作要求の正当性を検証する機能とをコンピュータに実現させることを特徴とする。

本発明によれば、操作要求の正当性を確実に確認することができる。

以下、図面を参照して、本発明の実施形態について説明する。

図１は、本発明の各実施形態に共通するメッセージ検証システムの構成の一例を示す図である。

このメッセージ検証システムは、操作要求対象に対して操作要求を送信する第１ワークフロー装置（情報処理装置）１００と、この第１ワークフロー装置１００から送信される操作要求を受付けてその正当性を確認した上で当該操作要求を実行する第２ワークフロー装置（情報処理装置）２００とを含む情報処理システムである。第１ワークフロー装置１００には、例えば第１クライアント端末１Ａ、第２クライアント端末１Ｂ、および第３クライアント端末１Ｃが接続される。一方、第２ワークフロー装置２００には、例えば１つのクライアント端末２が接続される。

第１ワークフロー装置１００側では、ある操作要求（例えば、新規アカウントの登録に関する操作要求）に関して「申請」、「承認(1)」、「承認(2)」の順でワークフローに従った手続が進められるものとする。この場合、例えば、第１クライアント端末１Ａを使用するユーザが「申請」を行い、第２クライアント端末１Ｂを使用するユーザが「承認(1)」を行い、第３クライアント端末１Ｃを使用するユーザが「承認(2)」を行うものとする。

上記「申請」、「承認(1)」、「承認(2)」の各々は、図２に示すように、当該操作要求が第１ワークフロー装置１００から第２ワークフロー装置２００へ送信されるまでに行われる個々のアクティビティ（行為）に相当するものであり、各アクティビティが実行される毎にその内容を示すアクティビティ情報がコンテキストに格納されるようになっている。各アクティビティ情報は、いつ、誰が、何を使って、何をした、等を示す活動情報である。コンテキストは、複数のアクティビティ情報をひとまとめにしたものであり、ワークフローの過程において、個々の活動情報が記述されたデータである。

第１ワークフロー装置１００が第２ワークフロー装置２００へ操作要求を送信する際には、当該操作要求と共にコンテキストも第２ワークフロー装置２００へ送信する。これにより、第２ワークフロー装置２００側では、送信されてくる操作要求がどのようなアクティビティを経たものであるかを判断できるようになっている。

第２ワークフロー装置２００は、要求された操作を実行する前に、現在でもその操作要求が正当（もしくは有効）なものであるかどうかを確認するため、第１ワークフロー装置１００へコンテキストを送信して検証要求を行う。これにより、例えば申請者が退社、降格、もしくは部署移動したような場合に、その操作要求が無効であると判断できる。

以下、各実施形態について詳細に説明する。

（第１の実施形態）
図３は、本発明の第１の実施形態に係るメッセージ検証システムの構成の一例を示す図である。なお、図１と共通する要素には同一の符号を付している。また、説明の簡単化のため、前述した３台のクライアント端末１Ａ，１Ｂ，１Ｃを、１台のクライアント端末１で表現している。

第１ワークフロー装置１００は、アカウントの登録、更新、削除についての申請・承認などのワークフローを行うサーバである。具体的には、第２ワークフロー装置２００自身、あるいは第２ワークフロー装置２００に属するシステム、に対して実行して欲しい操作を操作要求として生成・申請し、操作要求と、後述するコンテキストとを第２ワークフロー装置２００に送信するサーバである。また、第２ワークフロー装置２００からの要求に応じて、後述するアクティビティ情報の検証を行う。

第２ワークフロー装置２００は、第１ワークフロー装置１００から送信されるアカウントの登録、更新、削除についての申請を承認し、申請内容を実行するサーバである。具体的には、第１ワークフロー装置１００より送信された操作要求とコンテキストとを解釈し、操作要求の正当性を確認するサーバである。第２ワークフロー装置２００は、操作要求時にコンテキストの検証を第１ワークフロー装置１００に要求し、コンテキストが正当であることを示す判定が返ってきた場合、第１ワークフロー装置１００より送信された操作要求を実行するか、あるいは第２ワークフロー装置２００に属するシステムに対して操作要求を実行するよう依頼する。

クライアント端末１，２は、それぞれ、第１ワークフロー装置１００，第２ワークフロー装置２００に備えられる各種機能を利用するための端末装置である。ここでは、クライアント端末１，２は、一般的なパーソナルコンピュータや携帯電話などにより構成され、一般的なWebブラウザが利用できるものである。Webブラウザは、ユーザ認証を行うとき、アクティビティを実行するとき、操作要求を実行するとき、正当性検証を要求・確認するときのインタフェースを構成する。

図３では省略しているが、第１ワークフロー装置１００、第２ワークフロー装置２００には操作要求を実行する各種システムや装置が接続されていてもよい。

第１ワークフロー装置１００は、ユーザ認証部１１と、アクティビティ実行者情報管理部１２と、アクティビティ実行部１３と、操作要求管理部１４と、コンテキスト管理部１５と、正当性検証部１６と、通信部１７と、認証情報記憶部１８と、アクティビティ実行者情報記憶部１９と、操作要求記憶部２０と、コンテキスト記憶部２１とを有する。

ユーザ認証部１１は、クライアント端末１のいずれかから送信されるユーザＩＤとパスワードとが、認証情報記憶部１８に記憶されたユーザＩＤとパスワードとに一致しているか否かによりユーザを認証するものである。すなわち、ユーザＩＤとパスワードとが一致している場合には正当ユーザであると判定し、一致していない場合には不正ユーザであると判定する。ただし、これに限る必要はなく、ユーザの認証の方法は、例えば、証明書・生体情報を用いた認証方法であってもよい。上記ユーザ認証部１１は、認証に成功した場合にのみ、操作要求についてのアクティビティを実行できるようにする。また、認証に成功した場合、認証に関するユーザ情報をアクティビティ実行者情報管理部１２に送出する。

アクティビティ実行者情報管理部１２に送出される、認証に関するユーザ情報の一例を図４に示す。図４の例では、認証に関するユーザ情報として、認証されたユーザを識別するユーザＩＤ、認証セッションがいつ開始したか（認証にいつ成功したか）を示す認証成功日時、認証セッションがいつ終了するかを示す認証有効期限日時が示されている。

アクティビティ実行者情報管理部１２は、ユーザが認証に成功した際にユーザによって後述するアクティビティ実行部１３によりアクティビティが実行された場合に、ユーザ認証部１１より送出された認証に関するユーザ情報をアクティビティ実行者情報として生成し、アクティビティ実行者情報記憶部１９に格納する。ただし、アクティビティ実行者情報管理部１２は、ユーザが認証に成功した際に、ユーザ認証部１１により送出された認証に関するユーザ情報アクティビティ実行者情報として生成し、アクティビティ実行者情報記憶部１９に格納してもよい。つまり、アクティビティが実行される前にアクティビティ実行者情報がユーザ情報を利用して生成しても構わないものとする。図１５のステップＳＴ１３とステップＳＴ１４では先にアクティビティ実行者情報が生成され、アクティビティが実行されるものとなっている。上記説明に従い、ステップＳＴ１３とステップＳＴ１４とは順序が入れ替わっても構わない。

アクティビティ実行者情報の一例を図５に示す。図５の例では、アクティビティ実行者情報はXML (eXtensible Markup Language)で記述されており、アクティビティ実行者情報を示す<ActivityActor>要素に、前記ユーザＩＤを示す<Id>要素と、前記認証成功日時を示す<NotBefore>要素と、前記認証有効期限日時を示す<NotOnOrAfter>要素とが含まれている。なお、アクティビティ実行者情報に格納する情報については、本実施形態に制限されるものではなく、図５に示すものの他にも例えば、異なる企業や組織のシステム間でも認証や認可などのセキュリティ情報をやりとりすることができるように定められた標準仕様であるSecurity Assertion Markup Language V2.0 (SAMLv2.0)で規定されている認証ステートメントを含むアサーションも利用できる。アサーションとは、ユーザが確かに認証されたことを他の主体に表明するためのメッセージである。アサーションの利用に関しては、“Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0”、[online]、OASIS Security Services (SAML) TC、[2006年4月19日検索]、インターネット＜URL：http: //www.oasis-open.org/committees/download.php/11898/saml-core-2.0-os.pdf ＞を参照されたい。

アクティビティ実行部１３は、操作要求に関するアクティビティ実行を行うものである。アクティビティの種類としては、操作要求の生成・申請処理、操作要求の変更処理、操作要求の取り消し処理、操作要求の閲覧処理、操作要求の承認処理、操作要求の差し戻し処理、操作要求の送信処理、操作要求の処理状態確認処理、などが挙げられる。なお、アクティビティの種類については、本実施形態に制限されるものではない。アクティビティ実行に関する情報は、コンテキスト管理部１５に送出される。

アクティビティ実行に関する情報の一例を図６に示す。図６の例では、アクティビティ実行に関する情報として、アクティビティを識別するアクティビティＩＤ、どのようなアクティビティが行われたのかを示すアクティビティ名、いつアクティビティが実行されたかを示すアクティビティ実行日時が示されている。

操作要求管理部１４は、アクティビティ実行部１３において生成・申請された操作要求を操作要求記憶部２０に格納するものである。また、操作要求を解釈し、実行する機能も有する。

新規アカウント登録に関する操作要求の一例を図７に示す。図７の例では、操作要求はXMLで記述されており、第２ワークフロー装置２００に対して、Idが”ichiro”であり、その他の属性としてSn：”鈴木”、GivenName：”一郎”、Mail：”ichiro@xxxxxx.xx.xx”であるユーザを登録するための操作要求が示されている。なお、操作要求はコンピュータにより実行されるプログラムに限定されるものではなく、操作内容を記述したテキスト形式のものであってもよい。操作要求の好例としては、サービスを提供する際におけるユーザ管理などの処理を自動化するサービスプロビジョニングに関する標準仕様であるService Provisioning Markup Language V2.0 (SPMLv2.0)を利用したリクエストメッセージも挙げられる。リクエストメッセージに関しては、“OASIS Service Provisioning Markup Language (SPML) Version 2”、[online]、OASIS Provisioning Services TC、[2007年4月19日検索]、インターネット＜URL：http://www.oasis-open.org/committees/download.php/17708/pstc-spml-2.0-os.zip ＞を参照されたい。

コンテキスト管理部１５は、操作要求に対するアクティビティ実行に関する情報をアクティビティ実行情報として生成し、この生成したアクティビティ実行情報と、当該アクティビティ実行情報に対応するアクティビティ実行者情報と、をひとまとめにしたアクティビティ情報を生成し、この生成した複数のアクティビティ情報をさらにひとまとめにしたコンテキストを生成するものである。コンテキスト管理部１５は、この生成したコンテキストをコンテキスト記憶部２１に格納する。なお、コンテキスト管理部１５はアクティビティ実行者情報をアクティビティ実行者情報記憶部１９より取得する。

アクティビティ実行情報の一例を図８に示す。図８の例では、アクティビティ実行情報はXMLで記述されており、アクティビティ実行情報を示す<ActivityAction>要素に、前記アクティビティＩＤを示す<Id>要素と、前記アクティビティ名を示す<ActivityName>要素と、前記アクティビティ実行日時を示す<Date>要素とが含まれている。なお、アクティビティ実行情報に格納する情報については、本実施形態に制限されるものではなく、図８で挙げた以外の情報を含んでもよい。

また、アクティビティ情報の一例を図９に示す。図９の例では、アクティビティ情報はXMLで記述されており、図８に示されるアクティビティ実行情報を含む<ActivityAction>要素と、図５に示されるアクティビティ実行者情報を含む<ActivityActor>要素とを含む。なお、アクティビティ情報に格納する情報については、本実施形態に制限されるものではなく、図９で挙げた以外の情報を含んでもよい。

また、コンテキストの一例を図１０に示す。図１０の例では、コンテキストはXMLで記述されており、コンテキストを示す<Context>要素に、コンテキストを識別する<Id>要素と、当該コンテキストが対応する操作要求を識別する<requestId>要素と、コンテキスト生成日時を示す<Date>要素と、アクティビティ情報を格納する<Activities>要素とが含まれている。アクティビティ情報が複数存在する場合には、これらのアクティビティ情報は<Activities>要素に格納される。なお、コンテキストに格納する情報については、本実施形態に制限されるものではなく、図１０で挙げた以外の情報を含んでもよい。

正当性検証部１６は、コンテキストに含まれる情報についての正当性の検証要求を解釈し、正当性の検証要求を受けてコンテキストの正当性検証を行ない、検証結果を要求元に返すものである。具体的には、第２ワークフロー装置２００から送信された検証要求を解釈し、検証要求の対象であるコンテキストに含まれる各アクティビティ情報について、そのアクティビティ実行情報とアクティビティ実行者情報とがアクティビティ実行時点と比較して正当であるかどうかを検証し、検証結果を検証応答として生成する。

検証要求の一例を図１１に示す。検証要求はXMLで記述されており、検証要求を示す<VerifyRequest>要素に、正当性を検証したいコンテキストを示す<Context>要素が含まれている。なお、検証要求に格納する情報については、本実施形態に制限されるものではなく、図１１で挙げた以外の情報を含んでもよい。

また、検証応答の一例を図１２に示す。図１２の例では、検証応答はXMLで記述されており、検証応答を示す<VerifyResponse>要素に、正当性の検証処理が成功したか失敗したかを示す<Status>要素と、正当性の検証結果を示す<Result>要素とが含まれている。なお、検証応答に格納する情報については、本実施形態に制限されるものではなく、図１２で挙げた以外の情報を含んでもよい。

通信部１７は、他のワークフロー装置に対して送信する情報を適切なプロトコルに変換し、他のワークフロー装置に対して送信するものである。また、他のワークフロー装置から送信された通信メッセージを受信し、解釈する。なお、通信時に利用するプロトコルについては、本実施形態に制限されるものではなく、例えば、HTTP (Hypertext Transfer Protocol)、HTTP (Hypertext Transfer Protocol Security)、FTP (File Transfer Protocol)で規定されたプロトコルを利用してもよいし、電子メールを利用してもよい。

認証情報記憶部１８は、ユーザＩＤと、パスワードと、状態とを格納する。ユーザＩＤとパスワードは、ユーザが本人であるかどうかを認証する際に利用される。状態は、該当するユーザＩＤが有効であるか、無効であるかを指定する際に利用される。認証情報記憶部１８のテーブル構成の一例を図１３に示す。なお、情報の格納方法については、本実施形態に制限されるものではなく、また認証情報記憶部１８は、ユーザＩＤとパスワードと状態以外の情報を含んでもよい。

アクティビティ実行者情報記憶部１９は、アクティビティ実行者情報を格納する。アクティビティ実行者情報記憶部１９に格納されたアクティビティ実行者情報は、コンテキスト管理部１５により、アクティビティ情報を生成する際に利用される。なお、情報の格納方法については、本実施形態に制限されるものではなく、またアクティビティ実行者情報記憶部１９は、アクティビティ実行者情報以外の情報を含んでもよい。

操作要求記憶部２０は、アクティビティ実行部１３において生成・申請された操作要求を格納する。操作要求記憶部２０に格納された操作要求は、通信部１７により、第２ワークフロー装置２００に送信される。また、操作要求記憶部２０に格納された操作要求は、操作要求の承認時などのアクティビティ実行の際にアクティビティ実行部１３により参照されてもよい。なお、情報の格納方法については、本実施形態に制限されるものではなく、また操作要求記憶部２０は、操作要求以外の情報を含んでもよい。

コンテキスト記憶部２１は、コンテキスト管理部１５において生成されたコンテキストを格納する。コンテキスト記憶部２１に格納されたコンテキストは、通信部１７により、第２ワークフロー装置２００に送信される。また、操作要求記憶部２０に格納された操作要求は、操作要求の承認時などのアクティビティ実行の際にアクティビティ実行部１３により参照されてもよい。なお、情報の格納方法については、本実施形態に制限されるものではなく、またコンテキスト記憶部２１は、コンテキスト以外の情報を含んでもよい。

一方、第２ワークフロー装置２００は、操作要求実行部３１と、正当性検証要求部３２と、ユーザ認証部３３と、通信部３４と、認証情報記憶部３５とを有する。

操作要求実行部３１は、第１ワークフロー装置１００より送信された操作要求を解釈し、実行するものである。また、操作要求の実行結果を操作応答として第１ワークフロー装置１００に送信してもよいが、本実施形態ではその過程を省略している。

正当性検証要求部３２は、コンテキストに含まれる情報についての正当性検証を要求し、返信された検証結果を確認するものである。具体的には、正当性検証の要求を検証要求として生成し、返信された検証応答として解釈する。

ユーザ認証部３３と、通信部３４と、認証情報記憶部３５とについては、第１ワークフロー装置１００と同一の処理を行うものであるため、その説明を省略する。

図３の構成におけるメッセージ検証の流れの一シナリオ例を図１４に示す。

ここでは、第１ワークフロー装置１００を管理する管理者taroが第２ワークフロー管理装置に新たなユーザichiroを登録したいという状況を想定している。管理者taroは第１ワークフロー装置１００に認証成功後、第２ワークフローへのユーザ登録要求を申請する（ステップＳ１）。申請したユーザ登録要求は、コンテキストと共に第２ワークフロー装置２００に送信される（ステップＳ２）。一定期間経過後に、第２ワークフロー装置２００を管理する管理者jiroが、ユーザichiroのユーザ登録要求を実行しようとするが、その前にユーザ登録要求が現在でも正当であるかどうかの検証を第１ワークフロー装置１００に要求する（ステップＳ３、Ｓ４）。第１ワークフロー装置１００はユーザ登録要求の正当性を検証し（ステップＳ５）、検証結果を第２ワークフロー装置２００に返す（ステップＳ６）。以下に、このシナリオ例に基づくメッセージ検証の流れの詳細を示す。なお、以下の説明では、第１ワークフロー装置１００と第２ワークフロー装置２００の認証情報記憶部３５に図１３の情報が格納されているものとする。

図１５は、図３の構成において管理者taroがユーザichiroのユーザ登録要求を申請する際の動作を示すフローチャートである。

始めに、第１ワークフロー装置１００は、クライアント端末から認証要求を受信する（ステップＳＴ１１）。第１ワークフロー装置１００は、認証要求を受け取るとユーザＩＤとパスワードとの入力を促すユーザ認証画面をクライアント端末に送信する。管理者taroは、このユーザ認証画面を介して、ユーザＩＤ：taroと、パスワード：abcdefと、を第１ワークフロー装置１００に対して送信する。

続いて、第１ワークフロー装置１００は、クライアント端末１により入力されたユーザＩＤとパスワードとに基づいてユーザの真正性を認証する（ステップＳＴ１２）。詳しくは、クライアント端末により入力されたユーザＩＤおよびパスワードと、認証情報記憶部１８に予め記憶されたユーザＩＤおよびパスワードとが一致するか否かにより、ユーザ認証部１１がユーザを認証する。

ユーザ認証部１１により、管理者taroが正当ユーザであることが認証されると（ステップＳＴ１２のＹＥＳ）、第１ワークフロー装置１００へのログインが許可される。これにより、クライアント端末を利用するユーザが、クライアント端末をインタフェースとして、第１ワークフロー装置１００でアクティビティを実行できるようになる。また、ユーザ認証部１１からアクティビティ実行者情報管理部１２に対して前述の図４に示される認証に関連する情報が送出される。アクティビティ実行者情報管理部１２は、認証に関連する情報を前述の図５に示されるアクティビティ実行者情報として、アクティビティ実行者情報記憶部１９に格納する（ステップＳＴ１３）。

続いて、管理者taroはクライアント端末から操作要求についてのアクティビティを実行する。第１ワークフロー装置１００は、ユーザとのインタフェースとしてGUIを備えていてもよく、管理者taroは例えば図１６に示されるようなユーザ登録申請画面から、ユーザichiroを第２ワークフロー装置２００に登録する申請を行う。これにより、第１ワークフロー装置１００のアクティビティ実行部１３で申請アクティビティが実行される（ステップＳＴ１４）。なお、インタフェースについては、本実施形態に制限されるものではない。

アクティビティ実行部１３は、操作要求管理部１４に対してユーザ登録申請を送出し、操作要求管理部１４はユーザ登録申請の内容を前述の図７に示される操作要求として操作要求記憶部２０に格納する（ステップＳＴ１５のＹＥＳ、ＳＴ１６）。また、コンテキスト管理部１５は、後で生成される個々のアクティビティ情報を格納するためのコンテキストを生成し、これをコンテキスト記憶部２１に記憶しておく（ステップＳＴ１７）。

なお、操作要求に対する承認など、新たな操作要求で無い場合は（ステップＳＴ１５のＮＯ）、操作要求の格納やコンテキストの生成は不要となる。

また、アクティビティ実行部１３は、前述の図６に示されるアクティビティ実行に関する情報をコンテキスト管理部１５に送出する。コンテキスト管理部１５は、アクティビティ実行に関する情報から前述の図８に示されるアクティビティ実行情報を生成し、このアクティビティ実行情報と前述のアクティビティ実行者情報とから前述の図９に示されるアクティビティ情報を生成し（ステップＳＴ１８）、その登録を行う（ステップＳＴ１９）。そして、このアクティビティ情報を前述の図１０のようにコンテキストの中に格納する（ステップＳＴ２０）。

その後、第１ワークフロー装置１００は、第２ワークフロー装置２００に対してユーザ登録申請を送信する要求を受ける（ステップＳＴ２１のＹＥＳ）。本実施形態では、申請処理が終了した後にユーザ登録申請を自動的に第２ワークフロー装置２００に送信するようにしているが、ユーザ登録申請などの操作要求を送信するための要求を出す方法については、本実施形態に制限されるものではなく、例えば、承認処理が終了した後に自動的に操作要求の送信要求を行ってもよいし、ユーザがアクティビティとして操作要求の送信要求を明示的に行うようにしてもよい。

ユーザ登録申請を第２ワークフロー装置２００に対して送信する要求を受け取ると、通信部３４は、操作要求記憶部２０内の指定されたユーザ登録申請（図７）と、コンテキスト記憶部２１内の指定された操作要求に対応するコンテキスト（図１０）とを取得し、取得したユーザ登録申請（操作要求）とコンテキストとを第２ワークフロー装置２００に対して送信する（ステップＳＴ２２）。

次に、図１７〜図１９のシーケンス図を参照し、前述の図１５のフローチャートに示される動作を「申請」、「承認(1)」、「承認(2)」の処理毎に分けて詳細に説明する。

図１７に示されるように、申請者が使用する第１クライアント端末１Ａがユーザ認証部１１にアクセスすると（ステップＡ１）、第１クライアント端末１Ａ側に認証要求が返される。次に、第１クライアント端末１Ａは、申請者により入力されるユーザＩＤとパスワードとをユーザ認証部１１へ送信すると（ステップＡ２）、ユーザ認証部１１は、認証情報記憶部１８内の認証情報を用いてユーザＩＤとパスワードとの認証を行ない（ステップＡ３）、問題無ければ認証成功を得る。ユーザ認証部１１がアクティビティ実行者情報管理部１２へ認証に関する情報を送出すると（ステップＡ４）、アクティビティ実行者情報管理部１２は、アクティビティ実行者情報を生成し、これをアクティビティ実行者情報記憶部１９に格納する（ステップＡ５）。この処理が完了すると、第１クライアント端末１Ａ側ではメニュー画面が表示される。第１クライアント端末１Ａがアクティビティ実行部１３にユーザ登録申請画面の表示を要求すると（ステップＡ６）、第１クライアント端末１Ａ側でユーザ登録申請画面が表示される。

次に、第１クライアント端末１Ａがアクティビティ実行部１３に対してユーザ登録申請を行なうと（ステップＡ７）、アクティビティ実行部１３は、操作要求管理部１４へ操作要求に関する情報を送出する（ステップＡ８）。これにより、操作要求管理部１４は、操作要求を操作要求記憶部２０に格納する（ステップＡ９）。次に、アクティビティ実行部１３がコンテキスト管理部１５に対してコンテキスト生成を要求すると（ステップＡ１０）、コンテキスト管理部１５は、コンテキストを生成し（ステップＡ１１）、生成したコンテキストをコンテキスト記憶部２１に格納する（ステップＡ１２）。次に、アクティビティ実行部１３がコンテキスト管理部１５に対してコンテキストへのアクティビティ情報の格納を要求すると（ステップＡ１３）、コンテキスト管理部１５は、アクティビティ実行部１３に対してアクティビティ実行に関する情報を要求する（ステップＡ１４）。この要求に対し、アクティビティ実行部１３がアクティビティ実行に関する情報をコンテキスト管理部１５に返すと、コンテキスト管理部１５は、アクティビティ実行情報を生成する（ステップＡ１５）。次に、コンテキスト管理部１５は、アクティビティ実行者情報記憶部１９からアクティビティ実行者情報を取得し（ステップＡ１６）、取得したアクティビティ実行者情報と、生成したアクティビティ実行情報とから、アクティビティ情報を生成し（ステップＡ１７）、生成したアクティビティ情報をコンテキスト記憶部２１に格納する（ステップＡ１８）。これにより、第１クライアント端末１Ａ側では、ユーザ登録申請完了が通知される。

図１８に示されるように、第１承認者が使用する第２クライアント端末１Ｂがユーザ認証部１１にアクセスすると（ステップＢ１）、第２クライアント端末１Ｂ側に認証要求が返される。次に、第２クライアント端末１Ｂは、第１承認者により入力されるユーザＩＤとパスワードとをユーザ認証部１１へ送信すると（ステップＢ２）、ユーザ認証部１１は、認証情報記憶部１８内の認証情報を用いてユーザＩＤとパスワードとの認証を行ない（ステップＢ３）、問題無ければ認証成功を得る。ユーザ認証部１１がアクティビティ実行者情報管理部１２へ認証に関する情報を送出すると（ステップＢ４）、アクティビティ実行者情報管理部１２は、アクティビティ実行者情報を生成し、これをアクティビティ実行者情報記憶部１９に格納する（ステップＢ５）。この処理が完了すると、第２クライアント端末１Ｂ側ではメニュー画面が表示される。

次に、第２クライアント端末１Ｂがアクティビティ実行部１３にユーザ登録承認画面の表示を要求すると（ステップＢ６）、アクティビティ実行部１３は、操作要求記憶部２０からユーザ登録申請を取得し（ステップＢ７）、さらに、コンテキスト管理部１５からコンテキストを取得し（ステップＢ８）、第２クライアント端末１Ｂ側にユーザ登録承認画面を表示させる。

次に、第２クライアント端末１Ｂがアクティビティ実行部１３へユーザ登録の承認を伝えると（ステップＢ９）、アクティビティ実行部１３は、コンテキスト管理部１５に対してコンテキストへのアクティビティ情報の格納を要求する（ステップＢ１０）。コンテキスト管理部１５は、アクティビティ実行部１３に対してアクティビティ実行に関する情報を要求し（ステップＢ１１）、アクティビティ実行に関する情報を取得すると、アクティビティ実行情報を生成する（ステップＢ１２）。次に、コンテキスト管理部１５は、アクティビティ実行者情報記憶部１９からアクティビティ実行者情報を取得し（ステップＢ１３）、取得したアクティビティ実行者情報と、生成したアクティビティ実行情報とから、アクティビティ情報を生成し（ステップＢ１４）、生成したアクティビティ情報をコンテキスト記憶部２１に格納する（ステップＢ１５）。これにより、第２クライアント端末１Ｂ側には、ユーザ登録申請の承認完了が通知される。

図１９に示されるように、第２承認者が使用する第３クライアント端末１Ｃがユーザ認証部１１にアクセスすると（ステップＣ１）、第３クライアント端末１Ｃ側に認証要求が返される。次に、第３クライアント端末１Ｃは、第１承認者により入力されるユーザＩＤとパスワードとをユーザ認証部１１へ送信すると（ステップＣ２）、ユーザ認証部１１は、認証情報記憶部１８内の認証情報を用いてユーザＩＤとパスワードとの認証を行ない（ステップＣ３）、問題無ければ認証成功を得る。ユーザ認証部１１がアクティビティ実行者情報管理部１２へ認証に関する情報を送出すると（ステップＣ４）、アクティビティ実行者情報管理部１２は、アクティビティ実行者情報を生成し、これをアクティビティ実行者情報記憶部１９に格納する（ステップＣ５）。この処理が完了すると、第３クライアント端末１Ｃ側ではメニュー画面が表示される。

次に、第３クライアント端末１Ｃがアクティビティ実行部１３にユーザ登録承認画面の表示を要求すると（ステップＣ６）、アクティビティ実行部１３は、操作要求記憶部２０からユーザ登録申請を取得し（ステップＣ７）、さらに、コンテキスト管理部１５からコンテキストを取得し（ステップＣ８）、第３クライアント端末１Ｃ側にユーザ登録承認画面を表示させる。

次に、第３クライアント端末１Ｃがアクティビティ実行部１３へユーザ登録の承認を伝えると（ステップＣ９）、アクティビティ実行部１３は、コンテキスト管理部１５に対してコンテキストへのアクティビティ情報の格納を要求する（ステップＣ１０）。コンテキスト管理部１５は、アクティビティ実行部１３に対してアクティビティ実行に関する情報を要求し（ステップＣ１１）、アクティビティ実行に関する情報を取得すると、アクティビティ実行情報を生成する（ステップＣ１２）。次に、コンテキスト管理部１５は、アクティビティ実行者情報記憶部１９からアクティビティ実行者情報を取得し（ステップＣ１３）、取得したアクティビティ実行者情報と、生成したアクティビティ実行情報とから、アクティビティ情報を生成し（ステップＣ１４）、生成したアクティビティ情報をコンテキスト記憶部２１に格納する（ステップＣ１５）。次に、アクティビティ実行部１３が通信部１７に対してユーザ登録申請の送信を要求すると（ステップＣ１６）、通信部１７は、操作要求記憶部２０からユーザ登録申請を取得し（ステップＣ１７）、さらに、コンテキスト記憶部２１からコンテキストを取得し（ステップＣ１８）、取得したユーザ登録申請（操作要求）とコンテキストとを第２ワークフロー装置２００へ送信する（ステップＣ１９）。これにより、第３クライアント端末１Ｃ側には、ユーザ登録承認の完了およびユーザ登録申請送信の完了が通知される。図２０には、「申請」および「承認」が完了した後のコンテキストの例が示されている。

図２１は、図３の構成において第２ワークフロー装置２００が第１ワークフロー装置１００からユーザ登録申請とコンテキストとを受信した後に行う処理の動作を示すフローチャートである。

第２ワークフロー装置２００は、第１ワークフロー装置１００からユーザ登録申請とコンテキストとを受信する（ステップＳＴ３１）。受信したユーザ登録申請とコンテキストとは、それぞれ、操作要求記憶部２０とコンテキスト記憶部２１とに格納される。

次に、第２ワークフロー装置２００を管理する管理者jiroが、第２ワークフロー装置２００で認証を行う（ＳＴ３２、ＳＴ３３）。認証処理については、第１ワークフロー装置１００での処理（図１５中のステップＳＴ１１、ＳＴ１２）と同一処理であるため、説明を省略する。

認証成功後、管理者jiroは第１ワークフロー装置１００より送信されたユーザ登録申請を実行するが、その前に現在でもユーザ登録申請が正当であるかどうかを検証する要求を行う（ステップＳＴ３４）。ユーザ登録申請が正当であるかどうかを検証する要求については、例えば図２２に示されるユーザ登録確認画面から行うことができるが、要求する方法については、本実施形態に制限されるものではない。検証要求があった場合、第２ワークフロー装置２００の正当性検証要求部３２は、コンテキストの検証を第１ワークフロー装置２００に対して依頼する。検証方法については後述する。検証結果が正当である場合（ステップＳＴ３５のＹＥＳ）、第２ワークフロー装置２００は、操作要求実行部３１においてでユーザichiroの登録を実行する（ステップＳＴ３６）。検証結果が正当でない場合（ステップＳＴ３５のＮＯ）、第２ワークフロー装置２００は、ユーザichiroの登録を実行せず、エラーとして処理する（ステップＳ３７）。

なお、管理者jiroは検証要求を行わずにコンテキストの内容を確認するだけで、ユーザ登録を実行してもよい。また、操作要求とコンテキストとの受信から一定期間経過した操作要求については必ず第１ワークフロー装置１００に検証するようにしてもよく、検査要求を行うか行わないかの判断方法については、特に制限されるものではない。

また、第２ワークフロー装置２００は、ユーザ登録の実行結果を第１ワークフロー装置１００に返信してもよい。操作要求に対する操作応答を返信することについては、特に制限されるものではない。

図２３は、図３の構成において第２ワークフロー装置２００が第１ワークフロー装置１００に対してコンテキストの検証を要求する際の動作を示すフローチャートである。

始めに、第２ワークフロー装置２００において、正当性検証要求部３２は送信されたコンテキストをコンテキスト記憶部２１から取得し（ステップＳＴ４１）、そのコンテキストから前述の図１１に示される検証要求を生成する（ステップＳＴ４２）。通信部３４は、正当性検証要求部３２により生成された検証要求を第１ワークフロー装置１００に対して送信する（ステップＳＴ４３）。

続いて、第１ワークフロー装置１００は、第２ワークフロー装置２００から検証要求を受信する（ステップＳＴ５１）。正当性検証部１６は、受信した検証要求を解釈し、検証要求に含まれるコンテキストに含まれるアクティビティ情報を取得する（ステップＳＴ５３）。正当性検証部１６は、アクティビティ情報が正当であるかを、アクティビティの正当性検証と、アクティビティ実行者の正当性検証と、を行うことで確認する（ステップＳＴ５４、ＳＴ５５，ＳＴ５６）。これらの検証を、コンテキストに含まれるすべてのアクティビティ情報に対して行う。

アクティビティの正当性検証では、ユーザ登録申請に対して実行されたアクティビティがユーザ登録申請を無効にするようなものであるかどうかを検証する。例えば、図２４の判定基準の例に示されるように、ユーザ登録申請とコンテキストとを送信後に、ユーザ登録申請の変更処理が実行されていたり、ユーザ登録申請の取り消し処理が実行されていたり、ユーザ登録申請の差し戻し処理が実行されていたりした場合、アクティビティは正当でないと判定される。図２４に示される個々の判定基準は、適宜組み合わせて採用するようにしてもよい。その際には、個々の判定基準を満たしているかをスコアにより総合的に判断するようにしてもよい。また、その際には、個々のスコアに対して重み付け処理を行ってもよい。なお、アクティビティの正当性の判定基準については、本実施形態に制限されるものではない。

アクティビティ実行者の正当性検証では、認証情報記憶部１８に格納されるアクティビティ実行者の情報を利用してコンテキストに含まれるアクティビティ実行者情報が正当なものであるかどうかを検証する。例えば、図２５の判定基準の例に示されるように、ユーザ登録申請とコンテキストとを送信後に、アクティビティ実行者のユーザＩＤが削除されていたり、アクティビティ実行者のユーザＩＤが無効になっていたりした場合、アクティビティ実行者情報は正当でないと判定される。図２５に示される個々の判定基準は、適宜組み合わせて採用するようにしてもよい。その際には、個々の判定基準を満たしているかをスコアにより総合的に判断するようにしてもよい。また、その際には、個々のスコアに対して重み付け処理を行ってもよい。また、図２４に示される個々の判定基準とも組み合せて総合的に判断するようにしてもよい。なお、アクティビティ実行者の正当性の判定基準については、本実施形態に制限されるものではない。

また、本実施形態は、アクティビティの正当性検証、アクティビティ実行者の正当性検証について、その検証順序を制限するものではなく、どちらを先に行ってもよい。

そして、前述の正当性検証部１６は、アクティビティ情報の検証結果を元に検証応答を生成する（ステップＳＴ５７）。通信部１７は、正当性検証部１６により生成された確認応答を第２ワークフロー装置２００に対して送信する（ステップＳＴ５８）。

続いて、第２ワークフロー装置２００は、第１ワークフロー装置１００から検証応答を受信する（ステップＳＴ４４）。正当性検証要求部３２は受信した検証応答を解釈することで、第２ワークフロー装置２００はコンテキストの正当性を確認できる（ステップＳＴ４５）。

なお、本実施形態では、各ワークフロー装置がそれぞれユーザ認証部を有しているが、ユーザ認証自体は別装置で行われてもよい。この場合、ワークフロー装置は認証結果をユーザ認証が行われた装置から受け取る必要がある。

また、機密性・完全性を維持するために、通信部１７，３４から送信される、操作要求と、コンテキストと、検証要求と、検証応答と、の通信時には、これらのメッセージを暗号化してもよい。また、これらのメッセージにメッセージダイジェスト、あるいはメッセージ識別子をつける、などによりメッセージが改ざんされているかどうかを確認してもよい。

また、本実施形態では、クライアント端末を用いてワークフロー装置でアクティビティを実行しているが、クライアント端末を利用せずにワークフロー装置で直接ユーザがアクティビティを実行してもよい。

このように第１の実施形態では、第１ワークフロー装置１００は、操作要求と、操作要求に対して行ったアクティビティに関する情報（アクティビティ自体の情報、アクティビティ実行者情報）とをまとめたコンテキストを、第２ワークフロー装置２００に対して送信する。第２ワークフロー装置２００では、操作要求に付随したコンテキストを参照することで操作要求がどのようなプロセスで送信されたかを確認できる。さらに、操作要求が操作要求実行時でも正当であるかどうかを確認するために、第２ワークフロー装置２００では、第１ワークフロー装置１００に対してコンテキストの検証を要求することができる。第１ワークフロー装置１００は、コンテキストの内容とユーザの属性情報を比較して、操作要求が現時点でも正当であるかどうかを、第２ワークフロー装置２００に返す。これにより、第２ワークフロー装置２００において操作要求実行時点での操作要求の正当性を確認できる。

（第２の実施形態）
次に、本発明の第２の実施形態について説明する。なお、前述の第１の実施形態と共通する部分の説明を省略し、異なる部分を中心に説明する。

図２６は、本発明の第２の実施形態に係るメッセージ検証システムの構成の一例を示す図である。なお、図３と共通する要素には同一の符号を付している。

第１ワークフロー装置１００は、前述した各要素に加え、ロールポリシ記憶部２２を有する。すなわち、本実施形態では、発明の第１の実施形態における第１ワークフロー装置１００に対して、ロール情報の優先順位をロールポリシとして管理する機能を追加している。ロールポリシを利用することで、ロール情報に優先順位がある場合のロール情報変更に対しても操作要求の正当性を判定できる。

ロール情報とは、権限範囲に基づいた概念情報であり、例えば、業務上の役割（一般利用者、システム管理者、など）、所属（会社、事業部、など）、役職（主任、課長、など）が挙げられる。例えば、操作要求を送信後にアクティビティ実行者の役職が変更されたとする。より上位の役職に変更された場合には操作要求が正当であると判定するが、より下位の役職に変更された場合には操作要求が正当でないと判定したい場合、ロールポリシでロール情報の優先順位を定めておくことで上記の判定を行うことができる。

ユーザ認証部１１は、認証に成功した場合、認証に関するユーザ情報をアクティビティ実行者情報管理部１２に送出する。アクティビティ実行者情報管理部１２に送出される、認証に関するユーザ情報の一例を図２７に示す。図２７では、認証に関するユーザ情報として、認証されたユーザを識別するユーザＩＤ、認証セッションがいつ開始したか（認証にいつ成功したか）を示す認証成功日時、認証セッションがいつ終了するかを示す認証有効期限日時、ユーザの認証時点での役職を示す役職ＩＤ、が示されている。これ以外のユーザ認証部１１の機能については、第１の実施形態と同様である。

アクティビティ実行者情報管理部１２は、ユーザが認証に成功した際に、ユーザ認証部１１より送出された認証に関するユーザ情報をアクティビティ実行者情報として生成し、アクティビティ実行者情報記憶部１９に格納する。アクティビティ実行者情報の一例を図２８に示す。図２８の例では、アクティビティ実行者情報はXMLで記述されており、アクティビティ実行者情報を示す<ActivityActor>要素に、前記ユーザＩＤを示す<Id>要素と、前記認証成功日時を示す<NotBefore>要素と、前記認証有効期限日時を示す<NotOnOrAfter>要素と、前記役職ＩＤを示す<postId>とが含まれている。これ以外のアクティビティ実行者情報管理部１２の機能については、第１の実施形態と同様である。

認証情報記憶部１８は、ユーザＩＤと、パスワードと、状態と、役職ＩＤとを格納する。ユーザＩＤとパスワードは、ユーザが本人であるかどうかを認証する際に利用される。状態は、該当するユーザＩＤが有効であるか、無効であるかを指定する際に利用される。役職ＩＤは、ユーザが現在どのような役職についているかを示すロール情報である。認証情報記憶部１８のテーブル構成の一例を図２９に示す。情報の格納方法については、本実施形態に制限されるものではなく、また認証情報記憶部１８は、ユーザＩＤとパスワードと状態と役職ＩＤ以外の情報を含んでもよい。

ロールポリシ記憶部２２は、ロール情報の優先順位を定義するロールポリシとを格納するものである。ロールポリシは正当性検証部１６においてアクティビティ実行者情報を検証する際に利用される。ロールポリシ記憶部２２のテーブル構成の一例を図３０に示す。図３０では、ロールポリシ情報として、役職を用いており、担当の上位の役職として課長、課長の上位の役職として部長というポリシを設定している。具体的には、ロールポリシ記憶部２２は、役職を識別する役職ＩＤと、役職の名称を示す役職名と、役職の上位の役職を示す上位役職ＩＤと、を格納する。情報の格納方法については、本実施形態に制限されるものではなく、またロールポリシ記憶部２２は、ロールポリシ以外の情報を含んでもよい。

以降、図２６の構成におけるメッセージ検証の流れを前述の図１４に示したシナリオ例を用いて説明する。なお、以下の説明では、第２ワークフロー装置２００の認証情報記憶部３５に図２９の情報が、第１ワークフロー装置１００のロールポリシ記憶部２２に図３０の情報が、それぞれ格納されているものとする。

本実施形態における動作は、基本的には、第１の実施形態の図１５、図１７〜図１９、図２１、図２３で示した動作と同様であるため、説明を省略する。ただし、認証に関するユーザ情報、アクティビティ実行者情報は、それぞれ図２７、図２８に示される情報であるものとする。アクティビティ実行者の正当性の検証について、以下に説明する。

アクティビティ実行者の正当性検証では、例えば、図３１の判定基準の例に基づき、認証情報記憶部１８に格納されるアクティビティ実行者の情報が正当なものであるかどうかを検証する。ロール情報の正当性を検証する際には、認証情報記憶部１８に記憶されるロール情報と、確認要求メッセージに含まれるアクティビティ情報に含まれるアクティビティ実行者情報のロール情報とを比較し、違いがあった場合にはロールポリシ記憶部２２を参照して、ロール情報が正当であるかどうかを検証する。本シナリオ例では、検証要求に含まれるアクティビティ実行者情報の管理者taroの役職ＩＤが1500であるため、認証記憶部に格納されているユーザＩＤ：taroの役職ＩＤが、例えば1400に変更されていた場合には、上位役職に該当するため、アクティビティ実行者情報の役職ＩＤは正当であると検証される。なお、アクティビティ実行者の正当性の判定基準については、本実施形態に制限されるものではなく、例えば、通信メッセージ送信後に、アクティビティ実行者のユーザＩＤが削除されていたり、アクティビティ実行者のユーザＩＤが無効になっていたり、アクティビティ実行者のロール情報がより下位のロール情報に変更されていたりした場合、アクティビティ実行者情報は正当でないと判定される。

このように第２の実施形態では、ロール情報の優先順位を定義するロールポリシを利用して、ロール情報が変更された際の正当性検証を行うことができる。

前述の各実施形態によれば、非同期の操作要求を送信し、一定期間経過後に操作要求を実行する際に、実行時点でも操作要求が正当であるかどうかを確認できる。また、コンピュータを利用してビジネスプロセスを促進あるいは自動化するワークフローに対しても適用できる。特に、アクティビティ実行装置と検証要求装置が別企業に配置されている場合や、操作要求が非同期に実行される（操作要求を受信する日時と、操作要求を実行する日時が離れている）ものである場合に、有効である。

なお、上述した実施形態で述べた本発明に係る各種の処理手順は、コンピュータプログラムとして、コンピュータ（情報処理装置）により読み取り可能な記憶媒体（例えば磁気ディスク，光ディスク，半導体メモリ）に記憶させておき、必要に応じてそれをプロセッサにより読み出して実行するようにしてもよい。また、このようなコンピュータプログラムは、通信媒体を介してあるコンピュータから他のコンピュータに伝送することにより配布することも可能である。

本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

本発明の各実施形態に共通するメッセージ検証システムの構成の一例を示す図。 アクティビティ情報とコンテキストとを説明するための図。 本発明の第１の実施形態に係るメッセージ検証システムの構成の一例を示す図。 認証に関するユーザ情報の一例を示す図。 アクティビティ実行者情報の一例を示す図。 アクティビティ実行に関する情報の一例を示す図。 新規アカウント登録に関する操作要求の一例を示す図。 アクティビティ実行情報の一例を示す図。 アクティビティ情報の一例を示す図。 コンテキストの一例を示す図。 検証要求の一例を示す図。 検証応答の一例を示す図。 認証情報記憶部のテーブル構成の一例を示す図。 メッセージ検証の流れの一シナリオ例を示す図。 管理者taroがユーザichiroのユーザ登録要求を申請する際の動作を示すフローチャート。 ユーザ登録申請画面の一例を示す図。 申請者による申請に関する動作を示すシーケンス図。 第１承認者による承認に関する動作を示すシーケンス図。 第２承認者による承認に関する動作を示すシーケンス図。 「申請」および「承認」が完了した後のコンテキストの一例を示す図。 第２ワークフロー装置が第１ワークフロー装置からユーザ登録申請とコンテキストとを受信した後に行う処理の動作を示すフローチャート。 ユーザ登録確認画面の一例を示す図。 第２ワークフロー装置が第１ワークフロー装置に対してコンテキストの検証を要求する際の動作を示すフローチャート。 アクティビティの正当性検証に使用される判定基準の一例を示す図。 アクティビティ実行者の正当性検証に使用される判定基準の一例を示す図。 本発明の第２の実施形態に係るメッセージ検証システムの構成の一例を示す図。 認証に関するユーザ情報の一例を示す図。 アクティビティ実行者情報の一例を示す図。 認証情報記憶部のテーブル構成の一例を示す図。 ロールポリシ記憶部のテーブル構成の一例を示す図。 アクティビティ実行者の正当性検証に使用される判定基準の一例を示す図。

符号の説明

１，１Ａ，１Ｂ，１Ｃ，２…クライアント端末、１１…ユーザ認証部、１２…アクティビティ実行者情報管理部、１３…アクティビティ実行部、１４…操作要求管理部、１５…コンテキスト管理部、１６…正当性検証部、１７…通信部、１８…認証情報記憶部、１９…アクティビティ実行者情報記憶部、２０…操作要求記憶部、２１…コンテキスト記憶部、２２…ロールポリシ記憶部、３１…操作要求実行部、３２…正当性検証要求部、３３…ユーザ認証部、３４…通信部、１００…第１ワークフロー装置、２００…第２クライアント端末。

Claims (5)

1. 操作要求対象に対して操作要求を送信する第１の情報処理装置と、前記第１の情報処理装置から送信される前記操作要求を受付ける第２の情報処理装置と、を含む情報処理システムであって、
   前記第１の情報処理装置は、前記操作要求に関してあるアクティビティが実行される毎にその内容を示すアクティビティ情報が登録されるコンテキストを記憶する記憶手段と、前記操作要求と前記記憶手段に記憶されるコンテキストとを前記第２の情報処理装置へ送信する手段とを具備し、
   前記第２の情報処理装置は、前記第１の情報処理装置から送信されてくる前記操作要求と前記コンテキストを受信する手段と、前記受信したコンテキストを前記第１の情報処理装置へ送信して前記受信した操作要求の正当性の検証を前記第１の情報処理装置に要求する手段とを具備し、
   前記第１の情報処理装置は、前記第２の情報処理装置からの検証要求があった場合、当該検証要求と共に送信されてくるコンテキスト内のアクティビティ情報と前記記憶手段に記憶されているコンテキスト内のアクティビティ情報とを比較することによって当該操作要求の正当性を検証する手段を具備する、
   ことを特徴とする情報処理システム。
2. 各アクティビティ情報には、アクティビティの種別とアクティビティの実行者を示す情報とが含まれており、前記検証の際にはこれらの情報が使用されることを特徴とする請求項１に記載の情報処理システム。
3. 各アクティビティ情報には、アクティビティの実行者の役職を示す識別情報が含まれており、前記検証の際には当該識別情報が使用されることを特徴とする請求項１乃至請求項２に記載の情報処理システム。
4. 操作要求対象に対して操作要求を送信する情報処理装置であって、
   前記操作要求に関してあるアクティビティが実行される毎にその内容を示すアクティビティ情報が登録されるコンテキストを記憶する記憶手段と、
   前記操作要求と前記記憶手段に記憶されるコンテキストとを外部の装置へ送信する手段と、
   前記外部の装置からの検証要求があった場合、当該検証要求と共に送信されてくるコンテキスト内のアクティビティ情報と前記記憶手段に記憶されているコンテキスト内の個々のアクティビティ情報とを比較することによって当該操作要求の正当性を検証する手段と、
   を具備することを特徴とする情報処理装置。
5. 操作要求対象に対して操作要求を送信するコンピュータに使用されるプログラムであって、
   前記操作要求に関してあるアクティビティが実行される毎にその内容を示すアクティビティ情報が登録されるコンテキストを記憶手段に記憶する機能と、
   前記操作要求と前記記憶手段に記憶されるコンテキストとを外部の装置へ送信する機能と、
   前記外部の装置からの検証要求があった場合、当該検証要求と共に送信されてくるコンテキスト内のアクティビティ情報と前記記憶手段に記憶されているコンテキスト内のアクティビティ情報とを比較することによって当該操作要求の正当性を検証する機能と、
   をコンピュータに実現させることを特徴とするプログラム。

Images