JP4764494B2 - 情報連携基盤プログラム - Google Patents

Description

本発明は、サービス提供を要求するユーザの認証後にアクセス管理サーバから提供されるユーザの属性情報をサービスロジックに連携するための情報連携基盤システムに用いられる情報連携基盤プログラムに関する。

ユーザがWebアプリケーションシステムを利用する際の認証技術に、シングルサインオンと呼ばれる技術がある。この技術は、一度の認証で複数のWebサイトを利用可能にするものであり、ユーザに対してWebサイト毎に認証を受ける手間を省略し、ユーザのログイン時の負担を軽減可能とするものである。

近年、このシングルサインオンの機能を持つアクセス管理サーバ製品が、多くのベンダから提供されている。アクセス管理サーバは、シングルサインオンの方式としてエージェント型とリバースプロキシ型に大きく分類される。

エージェント型は、Webサーバもしくはアプリケーションサーバにエージェントと呼ばれるモジュールを設置し、未認証のユーザがクライアント端末からWeb／アプリケーションサーバにリクエストを送信した際に、エージェントがそのリクエストをアクセス管理サーバにリダイレクトさせて、クライアント端末とアクセス管理サーバとの間で認証処理を行わせる方式である。エージェント型においては、認証処理が成功すると、クライアント端末からのリクエストは再びWeb／アプリケーションサーバに戻される。

一方、リバースプロキシ型は、クライアント端末とWeb／アプリケーションサーバとの間にプロキシサーバとして動作するアクセス管理サーバを設置し、未認証のユーザからのリクエストをアクセス管理サーバが受け、認証処理を行う方式である。リバースプロキシ型においては、認証処理が成功すると、アクセス管理サーバはクライアント端末からのリクエストをWeb／アプリケーションサーバに受け渡す。Web／アプリケーションサーバからのレスポンスは、アクセス管理サーバを経由してクライアント端末に返される。

アクセス管理サーバは、ユーザの属性情報を格納したデータベースを管理している。そして、アクセス管理サーバは、エージェント型、リバースプロキシ型ともに、認証に成功した場合、当該データベース内のユーザの属性情報をWeb／アプリケーションサーバに受け渡す。なお、どの属性情報を引き渡すかは予め設定ファイルに設定されている。

Web／アプリケーションサーバ上のアプリケーションは、アクセス管理サーバから取得した属性情報をセッションに格納し、画面表示やアクセス制御に利用する。

特許文献１に記載の技術では、Web／アプリケーションサーバに送信するユーザの属性情報をアクセス管理サーバ側で特定し、必要な属性情報だけをWeb／アプリケーションサーバに引き渡す構成により、Web／アプリケーションサーバ側の処理負荷を軽減し、属性情報の引渡しを効率化している。

特開２００７−４８２４１号公報

しかしながら、Web／アプリケーションサーバに属性情報を受け渡す場合、アクセス管理サーバの製品毎に、属性情報の提供方法や属性名が異なっている。例えば、ある製品では、メールアドレスをmailという属性名で属性情報に格納し、この属性情報をクッキー（Cookie）情報でWeb／アプリケーションサーバに渡すという属性情報提供方法を用いている。また、別の製品では、同じメールアドレスをmailAddressという属性名で属性情報に格納し、この属性情報をHTTP(Hypertext Transfer Protocol)ヘッダでWeb／アプリケーションサーバに渡すという属性情報提供方法を用いている。すなわち、アクセス管理サーバの製品毎に、異なる属性情報の提供方法や属性名を用いている。

このようなアクセス管理サーバの製品の違いから、アクセス管理サーバを移行する毎に、移行後のアクセス管理サーバの製品に応じてユーザの属性情報を取得する機能を、Web／アプリケーションサーバ側のサービス提供手段としてのサービスロジックに実装する必要が生じてしまう。

まとめると、Web／アプリケーションサーバ側では、ユーザの属性情報を取得する観点から、属性情報の提供方法や属性名が異なるアクセス管理サーバの製品毎に、サービスロジックの実装を変更する必要が生じてしまう不都合がある。

本発明は上記実情を考慮してなされたもので、サービスロジックの実装を変更せずに、属性情報の提供方法や属性名が異なるアクセス管理サーバからユーザの属性情報を取得し得る情報連携基盤プログラムを提供することを目的とする。

本発明の一つの局面によれば、リクエストを端末から受信すると、前記リクエストを送信したユーザの認証処理を実行し、前記認証処理の成功後、リクエスト側属性名毎に前記ユーザの属性値を含む属性情報が格納された前記リクエストを送信するアクセス管理サーバ装置と、互いに対応するアプリケーション側属性名及び前記属性値を含むアプリケーションセッションに基づいて、前記端末にサービス情報を提供するサービス提供手段を備えたアプリケーションサーバ装置と、前記アプリケーションサーバ装置に設けられ、前記アクセス管理サーバ装置から送信されたリクエストに対して情報連携処理を実行し、この情報連携処理によって前記アプリケーションセッションを前記サービス提供手段に送出する情報連携基盤システムとのうち、前記情報連携基盤システムに用いられる情報連携基盤プログラムであって、前記アプリケーションサーバ装置を、互いに対応するリクエスト側属性名、アプリケーション側属性名及び属性情報取得先を含む属性情報取得方法を定義した属性情報取得方法定義手段、前記属性情報取得方法に基づいて、前記送信されたリクエストから属性情報を取得すると共に、この属性情報内のリクエスト側属性名及び属性値のうち、リクエスト側属性名をアプリケーション側属性名に替えて当該アプリケーション側属性名及び当該属性値を前記アプリケーションサーバ装置の記憶手段に書き込む属性情報取得手段、前記記憶手段内に当該アプリケーション側属性値及び属性値を含むアプリケーションセッションが存在するか否かを検証するアプリケーションセッション検証手段、前記検証の結果、否の場合に、当該アプリケーション側属性値及び属性値を含むアプリケーションセッションを生成するアプリケーションセッション生成手段、前記生成したアプリケーションセッションを前記記憶手段に書き込んだ後、前記記憶手段内のアプリケーションセッションを前記サービス提供手段に送出するアプリケーションセッション送出手段、として機能させるための情報連携基盤プログラムである。

なお、本発明の一つの局面は「プログラム」として表現したが、これに限らず、「装置」、「方法」又は「プログラムを記憶したコンピュータ読取り可能な記憶媒体」といった他の表現を用いてもよい。

（作用）
本発明の一つの局面においては、互いに対応するリクエスト側属性名、アプリケーション側属性名及び属性情報取得先を含む属性情報取得方法に基づいて、リクエストから属性情報を取得すると共に、この属性情報内のリクエスト側属性名及び属性値のうち、リクエスト側属性名をアプリケーション側属性名に替えて当該アプリケーション側属性名及び属性値をアプリケーションサーバ装置の記憶手段に書き込み、記憶手段内のアプリケーション側属性値及び属性値を含むアプリケーションセッションを生成して当該アプリケーションセッションをサービス提供手段に送出する。

これにより、サービスロジックの実装を変更せずに、属性情報の提供方法や属性名が異なるアクセス管理サーバからユーザの属性情報を取得できる。

以上説明したように本発明によれば、サービスロジックの実装を変更せずに、属性情報の提供方法や属性名が異なるアクセス管理サーバからユーザの属性情報を取得できる。

本発明の第１の実施形態に係る情報連携基盤プログラムが適用された情報連携基盤システムを含むサービス提供システムの構成例を示す模式図である。 同実施形態における属性情報記憶部の構成を示す模式図である。 同実施形態における属性情報取得方法定義部の構成を示す模式図である。 同実施形態における一時記憶部の構成を示す模式図である。 同実施形態におけるアプリケーションセッション記憶部の構成を示す模式図である。 同実施形態における動作を説明するためのフローチャートである。 本発明の第２の実施形態に係る情報連携基盤プログラムが適用された情報連携基盤システムを含むサービス提供システムの構成例を示す模式図である。 同実施形態における属性情報検証ルール定義部の構成を示す模式図である。 同実施形態における動作を説明するためのフローチャートである。 本発明の第３の実施形態に係る情報連携基盤プログラムが適用された情報連携基盤システムを含むサービス提供システムの構成例を示す模式図である。 同実施形態における属性情報変換ルール定義部の構成を示す模式図である。 同実施形態における動作を説明するためのフローチャートである。 同実施形態におけるアプリケーションセッションの記憶動作を説明するための模式図である。 本発明の第４の実施形態に係る情報連携基盤プログラムが適用された情報連携基盤システムを含むサービス提供システムの構成例を示す模式図である。 同実施形態における動作を説明するためのフローチャートである。

以下、本発明の各実施形態について図面を用いて説明する。なお、以下の各装置は、装置毎に、ハードウェア構成、又はハードウェア資源とソフトウェアとの組合せ構成のいずれでも実施可能となっている。組合せ構成のソフトウェアとしては、予めネットワーク又は記憶媒体から対応する装置のコンピュータにインストールされ、対応する装置の機能を実現させるためのプログラムが用いられる。

（第１の実施形態）
図１は本発明の第１の実施形態に係る情報連携基盤プログラムが適用された情報連携基盤システムを含むサービス提供システムの構成例を示す模式図であり、図２乃至図５は同サービス提供システム内の各記憶部又は定義部の構成例を示す模式図である。このサービス提供システムは、クライアント端末１０、Webサーバ装置２０、アクセス管理サーバ装置３０及びアプリケーションサーバ装置４０を備えている。

ここで、クライアント端末１０は、任意のWebブラウザ部（図示せず）が設けられている。Webブラウザ部は、メモリ内の任意のWebブラウザを実行するＣＰＵの一機能からなり、例えば、ユーザの操作により、リクエスト側属性名毎にユーザの属性値を含む属性情報が格納されたリクエストをWebサーバ装置２０に送信する機能と、アプリケーションサーバ装置４０からWebサーバ装置２０を介して提供されるサービス情報を表示する機能とをもっている。

Webサーバ装置２０は、クライアント端末１０から送信されたサービスリクエストを受け付け、アプリケーションサーバ装置４０に受け渡すとともに、アプリケーションサーバ装置４０からの応答をクライアント端末１０に受け渡す。Webサーバ装置２０には、アクセス管理サーバ装置３０と情報の送受信を行うためのエージェント部２１が設けられている。エージェント部２１は、メモリ内のエージェントプログラムを実行するＣＰＵの一機能からなり、例えば、未認証のユーザが操作するクライアント端末１０から送信されたリクエストをアクセス管理サーバ装置３０にリダイレクトさせる処理、アクセス管理サーバ装置３０に属性情報取得要求を送信する処理、認証済みのユーザの属性情報をアクセス管理サーバ装置３０から取得し、アプリケーションサーバ装置４０に引き渡す処理を行う。

アクセス管理サーバ装置３０は、属性情報記憶部３１及びアクセス管理部３２を備えている。本実施形態では、エージェント型のアクセス管理サーバ装置３０を用いる場合を例示するが、リバースプロキシ型のアクセス管理サーバ装置を用いてもよい。

属性情報記憶部３１は、アクセス管理部３２から読出／書込可能なデータベースであり、図２に示す如き、ユーザの属性情報テーブル３１ａを記憶している。属性情報テーブル３１ａは、それぞれリクエスト側の属性名としてのuid（ユーザ識別名）、cn（氏名）、telephoneNumber（電話番号）、facsimileTelephoneNumber（FAX番号）、mail（メールアドレス）に対応する属性値を含む各フィールドからなるレコードをユーザ毎に格納している。

アクセス管理部３２は、リクエストをクライアント端末１０から受信すると、リクエストを送信したユーザの認証処理を実行し、認証処理の成功後、リクエスト側属性名毎にこのユーザの属性値を含む属性情報が格納されたリクエストをWebサーバ装置２０に送信する機能をもっている。認証処理は、例えば、リクエスト内の属性情報と属性情報記憶部３１内の属性情報とを照合して両者の一致を確認する処理や、リクエスト内のユーザＩＤ及びパスワードと、属性情報記憶部３１内のユーザＩＤ及びパスワード（図示せず）とを照合して両者の一致を確認する処理などが適宜使用可能となっている。なお、アクセス管理部３２は、クライアント端末１０からのリクエストがユーザＩＤ及びパスワードを含むが、サービス提供に必要な属性情報を含まない場合、認証処理の成功後、Webサーバ装置２０からの属性情報取得要求により、属性情報記憶部３１内の属性情報をWebサーバ装置２０に送信する機能をもっている。

一方、アプリケーションサーバ装置４０は、属性情報処理部５０及びセッション処理部６０により情報連携処理を実行する情報連携基盤システム７０と、サービス提供手段としてのサービスロジック部８０とを備えている。なお、情報連携基盤システム７０は、アプリケーションサーバ装置４０に設けられ、例えばメモリ内のプログラムを実行するＣＰＵの一機能からなり、Webサーバ装置２０を介してアクセス管理サーバ装置３０から送信されたリクエストに対して情報連携処理を実行し、この情報連携処理によってアプリケーションセッションをサービスロジック部８０に送出するものである。

属性情報処理部５０は、属性情報取得方法定義部５１、属性情報取得部５２及び一時記憶部５３を備えている。

属性情報取得方法定義部５１は、予め操作者の設定操作により、図３に一例を示すように、アクセス管理サーバ装置３０からどのようにユーザの属性情報を取得するかを示す属性情報取得方法５１ａを定義する。なお、「定義」の用語は、「設定」と読み替えてもよく、これは本明細書中の他の説明箇所でも同様である。属性情報取得方法５１ａは、互いに対応するリクエスト側属性名（以下、属性名（リクエスト側）ともいう）、アプリケーション側属性名（以下、属性名（アプリ側）ともいう）及び属性情報取得先を含んでおり、図３の例では、セッション格納フラグを更に含んでいる。但し、全ての属性情報をアプリケーションセッションに格納することが定義されている場合、セッション格納フラグは省略してもよい。

属性情報取得方法５１ａの「属性名（アプリ側）」は、アプリケーション側での属性名を示し、「属性名（リクエスト側）」は、アクセス管理サーバ装置３０での属性名を示している。この２通りの属性名の定義によって、アクセス管理サーバ装置３０から「属性名（リクエスト側）」の属性値を取得し、アプリケーションサーバ装置４０側で「属性名（アプリ側）」の属性値に設定可能となる。「属性情報取得先」は、アクセス管理サーバ装置３０から提供される属性情報をどこから取得するかを定義する。本実施形態では、「cookie」はクッキー（Cookie）情報から取得、「header」はHTTPヘッダから取得することを示している。「セッション格納フラグ」は、アクセス管理サーバ装置３０から取得した属性情報をアプリケーションセッションに格納するか否かを定義する。ここでは、値が「TRUE」の場合はアプリケーションセッションに格納するとし、「FALSE」の場合は格納しないとしている。

属性情報取得部５２は、属性情報取得方法定義部５１で定義された属性情報取得方法５１ａに基づいて、アクセス管理サーバ装置３０から送信されたリクエストからユーザの属性情報を取得する。具体的には、属性情報取得部５２は、属性情報取得方法定義部５１に定義された属性情報取得方法に基づいて、当該送信されたリクエストから属性情報を取得すると共に、この属性情報内のリクエスト側属性名及び属性値のうち、リクエスト側属性名をアプリケーション側属性名に替えて当該アプリケーション側属性名及び当該属性値を一時記憶部５３に書き込む機能をもっている。

一時記憶部５３は、属性情報取得部５２及びアプリケーションセッション生成部６３から読出／書込可能な記憶エリアであり、図４に示すように、アプリケーション側属性名及び属性値からなる属性情報５３ａが一時的に記憶される。なお、一時記憶部５３及びアプリケーション記憶部６１は、アプリケーションサーバ装置３０の記憶手段を構成する。

セッション処理部６０は、アプリケーションセッション記憶部６１、アプリケーションセッション検証部６２及びアプリケーションセッション生成部６３を備えている。

アプリケーションセッション記憶部６１は、アプリケーションセッション検証部６２及びアプリケーションセッション生成部６３から読出／書込可能な記憶エリアであり、図５に示すように、アプリケーションサーバ装置４０で提供されるサービス情報を利用するユーザのアプリケーションセッション６１ａの情報を記憶する。ここで、アプリケーションセッション６１ａは、セッションＩＤ毎に、アプリケーション側属性名及び属性値を含んでいる。

アプリケーションセッション検証部６２は、サービス情報を利用したいユーザのアプリケーション側属性名及び属性値を含むアプリケーションセッション６１ａがアプリケーションセッション記憶部６１に存在するか否かを検証する。検証の結果、アプリケーションセッション６１ａが存在すれば、そのまま処理を終える。アプリケーションセッション６１ａが存在しない場合（否の場合）は、アプリケーションセッション生成部６３にアプリケーションセッション６１ａの生成を依頼する。

アプリケーションセッション生成部６３は、アプリケーションセッション検証部６２からのアプリケーションセッション生成依頼を受けた場合、属性情報取得部５２で取得された一時記憶部５３内の属性情報５３ａをアプリケーションセッション６１ａに書き込み、このアプリケーションセッション６１ａをアプリケーションセッション記憶部６１に格納した後、アプリケーションセッション記憶部６１内のアプリケーションセッション６１ａをサービスロジック部８０に送出する。

サービスロジック部８０は、ユーザに提供するサービスを実装しているものであり、具体的には、メモリ内のサービス提供用プログラムを実行するＣＰＵの一機能からなり、例えば、互いに対応するアプリケーション側属性名及び属性値を含むアプリケーションセッション６１ａをアプリケーションセッション生成部６３から受けると、このアプリケーションセッション６１ａに基づいて、クライアント端末１０にサービス情報を提供するサービス提供機能をもっている。なお、「サービスロジック部」の名称は、「サービス実装部」、「サービス提供部」又は「サービス情報提供部」などの名称に適宜読み替えてもよい。

また、「サービス情報」は、「ユーザに提供するサービス」が電子商取引におけるコンテンツ販売等のように電子データ（例、暗号化コンテンツ）を提供するサービスの場合には当該電子データであり、「ユーザに提供するサービス」が電子商取引における物品販売等のように物品（例、宅配便等で配送する有体物）を提供するサービスの場合には当該物品販売の受付完了通知（例、顧客側控え情報を含む通知）などが使用可能となっている。すなわち、サービス情報は、サービス内容に応じて任意の情報が使用可能となっている。

次に、以上のように構成された情報連携基盤システムを含むサービス提供システムの動作を図６のフローチャートを用いて説明する。

始めに、クライアント端末１０は、未認証のユーザの操作により、リクエストをWebサーバ装置２０に送信する。

Webサーバ装置２０は、エージェント部２１により、このリクエストをアクセス管理サーバ装置３０にリダイレクトさせる。

アクセス管理サーバ装置３０は、リダイレクトにより再送されたリクエストをクライアント端末１０から受信すると、アクセス管理部３２により、リクエストに基づいてユーザの認証処理を実行し、認証処理の成功後、リクエストをWebサーバ装置２０にリダイレクトさせる。

Webサーバ装置２０においては、エージェント部２１により、アクセス管理サーバ装置３０に属性情報取得要求を送信し、当該ユーザのリクエスト側属性名毎にこのユーザの属性値を含む属性情報を取得する。取得後、当該リクエストにこの属性情報を格納し、アプリケーションサーバ装置４０に送信する。
（ステップＳ１）
アプリケーションサーバ装置４０は、このリクエストを受けると、属性情報取得部５２は、属性情報取得方法定義部５１で定義された属性情報取得方法５１ａを読み込む。

（ステップＳ２）
属性情報取得部５２は、ステップＳ１で取得した属性情報取得方法５１ａに基づいて、リクエストに含まれる属性情報を一つずつ取得する。例えば、リクエスト側属性名sessionidの属性値をクッキー（Cookie）情報から取得し、リクエスト側属性名uidの属性値をHTTPヘッダから取得する。

（ステップＳ３）
属性情報取得部５２は、ステップＳ２で取得した属性情報について、属性情報取得方法５１ａの「セッション格納フラグ」がTRUE／FALSEのどちらであるかを確認し、「格納する」を示すTRUEであればステップＳ４に進む。「格納しない」を示すFALSEであればステップＳ５に進む。

（ステップＳ４）
属性情報取得部５２は、取得したユーザの属性情報内の「属性名（リクエスト側）」の属性値を「属性名（アプリ側）」の属性値として一時記憶部５３に記憶する。本実施形態では、図４に示した如き、属性値が設定される。一時記憶部５３はメモリであっても、ＨＤＤ（Hard Disk Drive）であってもよい。

（ステップＳ５）
属性情報取得部５２は、未取得の属性情報がリクエスト内に存在するか否かを判定する。未取得の属性情報が存在する場合はステップＳ２に進む。存在しない場合はステップＳ６に進む。

（ステップＳ６）
アプリケーションセッション検証部６２は、サービスを要求してきたユーザのアプリケーションセッション６１ａが既に存在するか否かを判定する。アプリケーションセッション６１ａが存在しない場合はステップＳ７に進む。存在する場合はステップＳ８に進む。

（ステップＳ７）
アプリケーションセッション生成部６３は、新たにアプリケーションセッション６１ａを生成し、アプリケーションセッション記憶部６１に格納する。この際、ステップＳ４で一時記憶部５３に記憶した属性情報５３ａをアプリケーションセッション６１ａに設定する。本実施形態では、図５に示した如き、属性値が設定される。

（ステップＳ８）
しかる後、アプリケーションセッション生成部６３は、アプリケーションセッション６１ａをサービスロジック部８０に送出して処理を受け渡す。

サービスロジック部８０は、このアプリケーションセッション６１ａに基づいて、サービス情報をクライアント端末１０に送信する。

クライアント端末１０は、送信されたサービス情報を表示する。これにより、ユーザはサービスの提供を受ける。

上述したように本実施形態によれば、互いに対応するリクエスト側属性名、アプリケーション側属性名及び属性情報取得先を含む属性情報取得方法に基づいて、リクエストから属性情報を取得すると共に、この属性情報内のリクエスト側属性名及び属性値のうち、リクエスト側属性名をアプリケーション側属性名に替えて当該アプリケーション側属性名及び属性値を一時記憶部５３に書き込み、一時記憶部５３内のアプリケーション側属性値及び属性値を含むアプリケーションセッションを生成してアプリケーションセッション記憶部６１に保存した後、アプリケーションセッション記憶部６１内のアプリケーションセッションをサービスロジック部８０に送出する。

従って、サービスロジック部８０の実装を変更せずに、属性情報の提供方法や属性情報の名称が異なるアクセス管理サーバ装置３０からユーザの属性情報を取得できる。このため、アクセス管理サーバ装置３０を簡単に移行させることができる。

なお、本実施形態ではエージェント部２１を介してアクセス管理サーバ装置３０から受け渡されるリクエストに含まれる属性情報を属性情報取得部５２で取得するよう記述しているが、属性情報が含まれるリクエストは、例えば、リバースプロキシ型のアクセス管理サーバ装置３０から受け渡されるリクエストであってもよく、またリクエストを発行するツールを利用してクライアント端末１０から直接送信されるリクエストであってもよい。

（第２の実施形態）
図７は本発明の第２の実施形態に係る情報連携基盤プログラムが適用された情報連携基盤システムを含むサービス提供システムの構成例を示す模式図であり、図１と同一部分には同一符号を付し、付加された機能部を含む箇所には符号’を付してその詳しい説明を省略し、ここでは付加された機能部について主に述べる。なお、以下の各実施形態も同様にして重複した説明を省略する。

本実施形態は、第１の実施形態の変形例であり、リクエストから取得した属性情報を検証する形態であって、具体的には図１に示した構成に対し、属性情報検証ルール定義部５４及び属性情報検証部５５を付加している。

ここで、属性情報検証ルール定義部５４は、予め操作者の設定操作により、図８に一例を示すように、アクセス管理サーバ装置３０から取得したユーザの属性情報５３ａの属性値に対して検証を行うための属性情報検証ルール５４ａを定義する。

属性情報検証ルール５４ａは、「属性名（リクエスト側）」毎に、「属性検証フラグ」及び「検証ルール」を定義している。

「属性検証フラグ」は検証を行うタイミングを定義する。本実施形態では「TRUE」「FIRST」「FALSE」の３種類のタイミングを定義している。「TRUE」は、ユーザからサービス要求があるたびに毎回検証を行うことを示している。「FIRST」は、ユーザのアプリケーションセッション６１ａが存在しない場合にのみ検証を行うことを示している。「FALSE」は、検証を行わないことを示している。検証のタイミングはこれに限定されることなく、他のタイミングを定義しても構わない。

「検証ルール」には検証のためのルールを定義する。本実施形態では、「Exists」「isNumber」の２つのルールを定義している。「Exists」は属性値の有無（属性値が存在するか否か）を検証するためのルールであり、「isNumber」は属性値が数値データ（数字）か否かを検証するためのルールである。検証ルールはこれに限定されることなく、どのようなルールを定義しても構わない。

属性情報検証部５５は、属性情報検証ルール定義部５４で定義された検証ルール及びタイミングに基づいて、リクエストから取得した属性情報内の属性値を検証するものであり、検証の結果、検証失敗のときには例外メッセージをクライアント端末に送信する機能をもっている。

次に、以上のように構成された情報連携基盤システムを含むサービス提供システムの動作を図９のフローチャートを用いて説明する。第２の実施形態では、第１の実施形態の処理のステップＳ２とステップＳ３の間に新たにステップＳ２−１，Ｓ２−２の処理が追加される。それ以外の処理は第１の実施形態と同様である。従って、第１の実施形態のステップＳ２からステップＳ３の間の処理についてのみ説明する。

（ステップＳ２−１）
前述した通り、ステップＳ２までの処理が実行されたとする。
属性情報検証部５５は、ステップＳ２で取得したユーザの属性情報に対して、属性情報検証ルール定義部５４で定義された「属性検証フラグ」を参照し、検証のタイミングを判定する。判定の結果、“検証しない”、“２回目以降のサービス要求（「FALSE」又は「FIRST」）”の場合は、ステップＳ３に進む。判定の結果、“検証する”又は“初回のサービス要求（「TRUE」又は「FIRST」）”の場合は、ステップＳ２−２に進む。本実施形態では、リクエスト側の属性名がmailの場合のみステップＳ３に進む。

（ステップＳ２−２）
属性情報検証部５５は、ステップＳ２で取得したユーザの属性情報に対して、属性情報検証ルール定義部５４で定義された「検証ルール」を参照し、この「検証ルール」に基づいて検証を実行する。本実施形態では、リクエスト側の属性名であるsessionidとuidとcnに対応する属性値が、「Exists」（存在するかしないか）のルールで検証を行うよう定義されている。これらの属性情報はいずれも属性情報取得部５２で取得済みであるため、検証結果は成功となる。また、リクエスト側の属性名であるtelとfaxに対応する属性値が、「isNumber」（属性値が数字であるかどうか）のルールで、「FIRST」（初回のみ検証）のタイミングで検証を行うよう定義されている。これらの属性情報はいずれも数値であるため、検証結果は成功となる。すべての検証に成功した場合は、ステップＳ３に進む。なお、いずれかの属性情報に対して検証結果が失敗となる場合には、例えば例外メッセージを表示するなどの処理を行い、検証処理を終了する。

以下、前述した通り、ステップＳ３以降の処理が実行される。

上述したように本実施形態によれば、情報連携処理中に属性情報を検証する構成により、第１の実施形態の効果に加え、不足又は不備のある属性情報に基づくアプリケーションセッション６１ａをサービスロジック部８０に送出しないため、情報連携処理の信頼性を向上させることができる。

（第３の実施形態）
図１０は本発明の第３の実施形態に係る情報連携基盤プログラムが適用された情報連携基盤システムを含むサービス提供システムの構成例を示す模式図である。

本実施形態は、第１の実施形態の変形例であり、リクエストから取得した属性情報を変換する形態であって、図１に示した構成に対し、属性情報変換ルール定義部５６及び属性情報変換部５７を付加している。

ここで、属性情報変換ルール定義部５６は、予め操作者の設定操作により、図１１に一例を示すように、アクセス管理サーバ装置３０から取得したユーザの属性情報の属性値５３ａに対して属性値の形式を変換するための属性情報変換ルール５６ａを定義する。

属性情報変換ルール５６ａは、「属性名（リクエスト側）」毎に、「属性変換フラグ」及び「変換ルール」を定義している。

「属性変換フラグ」は属性情報の形式を変換するか否かを定義する。本実施形態では「TRUE」「FALSE」を定義している。「属性変換フラグ」が「TRUE」の場合に変換処理を行う。「属性変換フラグ」が「FALSE」の場合には変換処理を行わない。

「変換ルール」には変換のためのルールを定義する。本実施形態では、属性値に含まれる“ハイフン”を削除するルールを示す「H_DEL」を定義している。「変換ルール」はこれに限定されることなく、属性値の形式の変換であれば、どのような内容を定義しても構わない。「変換ルール」の他の例としては、英語の小文字を大文字に変換、又は大文字を小文字に変換する等が挙げられる。あるいは、メールアドレスのうち、＠以下を削除する等が挙げられる。あるいは、属性値に含まれる不等号“＜”、“＞”を、コンピュータの動作に影響を与えないように“＆ｌｔ；”、“＆ｇｔ；”に変換する等が挙げられる。

属性情報変換部５７は、属性情報変換ルール定義部５６で定義された属性情報変換ルール５６ａに基づいて、属性情報取得部５２で取得した属性情報の属性値の形式を変換するものである。

次に、以上のように構成された情報連携基盤システムを含むサービス提供システムの動作を図１２のフローチャートを用いて説明する。第３の実施形態では、第１の実施形態の処理のステップＳ２とステップＳ３の間に新たにステップＳ２−３，Ｓ２−４の処理が追加される。それ以外の処理は第１の実施形態と同様である。従って、第１の実施形態のステップＳ２からステップＳ３の間の処理についてのみ説明する。

（ステップＳ２−３）
前述した通り、ステップＳ２までの処理が実行されたとする。
属性情報変換部５７は、ステップＳ２で取得したユーザの属性情報に対して、属性情報変換ルール定義部５６で定義された「属性変換フラグ」を参照し、変換を行うか否かを判定する。判定の結果、変換を行わない（「FALSE」）場合は、ステップＳ３に進む。判定の結果、変換する（「TRUE」）場合は、ステップＳ２−４に進む。本実施形態では、属性名がtelephoneNumber、facsimileTelephoneNumberの場合のみステップＳ２−４に進む。

（ステップＳ２−４）
属性情報変換部５７は、ステップＳ２で取得したユーザの属性情報に対して、属性情報変換ルール定義部５６で定義された「変換ルール」を参照し、この「変換ルール」に基づいて、属性値の形式を変換する。本実施形態では、属性名（リクエスト側）telephoneNumber、facsimileTelephoneNumberの属性値（ハイフンを含む数値列データ）に対して、“ハイフン”を削除するルール（「H_DEL」）を適用する。結果として、アプリケーションセッション記憶部６１には図１３に示すように、属性名（アプリ側）tel、faxの属性値として、ハイフンの削除された数値列データを含むアプリケーションセッション６１ａ”が格納される。

以下、前述した通り、ステップＳ３以降の処理が実行される。

上述したように本実施形態によれば、情報連携処理中に属性情報を変換する構成により、第１の実施形態の効果に加え、サービスロジック部８０の処理に適合した属性情報に基づくアプリケーションセッション６１ａをサービスロジック部８０に送出できるため、情報連携処理における情報の整合性を向上させることができる。

（第４の実施形態）
図１４は本発明の第４の実施形態に係る情報連携基盤プログラムが適用された情報連携基盤システムを含むサービス提供システムの構成例を示す模式図である。

本実施形態は、第１〜第３の実施形態を組み合わせた形態であり、図１に示した構成に対し、図７に示した属性情報変換ルール定義部５４及び属性情報検証部５５と、図１０に示した属性情報変換ルール定義部５６及び属性情報変換部５７とを付加している。

ここで、属性情報検証部５５及び属性情報変換ルール定義部５６は、それぞれ第２の実施形態に述べた通りのものである。

属性情報変換ルール定義部５６及び属性情報変換部５７は、それぞれ第３の実施形態に述べた通りのものである。

次に、以上のように構成された情報連携基盤システムを含むサービス提供システムの動作を図１５のフローチャートを用いて説明する。第４の実施形態では、第１の実施形態の処理のステップＳ２とステップＳ３の間に、前述したステップＳ２−１，Ｓ２−２，Ｓ２−３，Ｓ２−４の処理が追加される。それ以外の処理は第１の実施形態と同様である。なお、ステップＳ２とステップＳ３の間において、ステップＳ２−１，Ｓ２−２よりも前に、ステップＳ２−３，Ｓ２−４を実行してもよい。

いずれの順序にしても、ステップＳ２とステップＳ３において、前述した属性情報の検証処理（Ｓ２−１，Ｓ２−２）と、属性情報の変換処理（Ｓ２−３，Ｓ２−４）とが実行される。以下、前述した通り、ステップＳ３以降の処理が実行される。

上述したように本実施形態によれば、図１に示した構成に対し、第２の実施形態の属性情報変換ルール定義部５４及び属性情報検証部５５と、第３の実施形態の属性情報変換ルール定義部５６及び属性情報変換部５７とを付加した構成により、第１〜第３の実施形態の効果を同時に得ることができる。

なお、上記実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどの記憶媒体に格納して頒布することもできる。

また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。

また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が上記実施形態を実現するための各処理の一部を実行しても良い。

さらに、本発明における記憶媒体は、コンピュータと独立した媒体に限らず、ＬＡＮやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。

また、記憶媒体は１つに限らず、複数の媒体から上記実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。

尚、本発明におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、上記実施形態における各処理を実行するものであって、パソコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。

また、本発明におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。

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

１０…クライアント端末、２０…Webサーバ装置、２１…エージェント部、３０…アクセス管理サーバ装置、３１…属性情報記憶部、３１ａ…属性情報テーブル、３２…アクセス管理部、４０，４０’，４０”，４０’”…アプリケーションサーバ装置、５０，５０’，５０”，５０’”…属性情報処理部、５１…属性情報取得定義部、５１ａ…属性情報取得方法、５２…属性情報取得部、５３…一時記憶部、５３ａ…属性情報、５４…属性情報変換ルール定義部、５４ａ…属性情報検証ルール、５５…属性情報検証部、５６…属性情報変換ルール定義部、５６ａ…属性情報変換ルール、５７…属性情報変換部、６０…セッション処理部、６１…アプリケーションセッション記憶部、６１ａ，６１ａ”…アプリケーションセッション、６２…アプリケーションセッション検証部、６３…アプリケーションセッション生成部、７０，７０’，７０”，７０’”…情報連携基盤システム、８０…サービスロジック部。

Claims (3)

1. リクエストを端末から受信すると、前記リクエストを送信したユーザの認証処理を実行し、前記認証処理の成功後、リクエスト側属性名毎に前記ユーザの属性値を含む属性情報が格納された前記リクエストを送信するアクセス管理サーバ装置と、
   互いに対応するアプリケーション側属性名及び前記属性値を含むアプリケーションセッションに基づいて、前記端末にサービス情報を提供するサービス提供手段を備えたアプリケーションサーバ装置と、
   前記アプリケーションサーバ装置に設けられ、前記アクセス管理サーバ装置から送信されたリクエストに対して情報連携処理を実行し、この情報連携処理によって前記アプリケーションセッションを前記サービス提供手段に送出する情報連携基盤システムとのうち、前記情報連携基盤システムに用いられる情報連携基盤プログラムであって、
   前記アプリケーションサーバ装置を、
   互いに対応するリクエスト側属性名、アプリケーション側属性名及び属性情報取得先を含む属性情報取得方法を定義した属性情報取得方法定義手段、
   前記属性情報取得方法に基づいて、前記送信されたリクエストから属性情報を取得すると共に、この属性情報内のリクエスト側属性名及び属性値のうち、リクエスト側属性名をアプリケーション側属性名に替えて当該アプリケーション側属性名及び当該属性値を前記アプリケーションサーバ装置の記憶手段に書き込む属性情報取得手段、
   前記記憶手段内に当該アプリケーション側属性値及び属性値を含むアプリケーションセッションが存在するか否かを検証するアプリケーションセッション検証手段、
   前記検証の結果、否の場合に、当該アプリケーション側属性値及び属性値を含むアプリケーションセッションを生成するアプリケーションセッション生成手段、
   前記生成したアプリケーションセッションを前記記憶手段に書き込んだ後、前記記憶手段内のアプリケーションセッションを前記サービス提供手段に送出するアプリケーションセッション送出手段、
   として機能させるための情報連携基盤プログラム。
2. 請求項１に記載の情報連携基盤プログラムにおいて、
   前記アプリケーションサーバ装置を、
   リクエスト側属性名毎に、属性値を検証する際の検証ルール及びタイミングを定義する属性情報検証ルール定義手段、
   前記検証ルール及び前記タイミングに基づいて、前記リクエストから取得した属性情報内の属性値を検証する属性情報検証手段、
   前記属性情報検証手段による検証の結果、検証失敗のときには例外メッセージを前記クライアント端末に送信する例外メッセージ送信手段、
   として更に機能させるための情報連携基盤プログラム。
3. 請求項１又は請求項２に記載の情報連携基盤プログラムにおいて、
   前記アプリケーションサーバ装置を、
   リクエスト側属性名毎に、属性値の形式を変換する属性情報変換ルールを定義した属性情報変換ルール定義手段、
   前記属性情報変換ルールに基づいて、前記リクエストから取得した属性情報内の属性値の形式を変換する属性情報変換手段、
   として更に機能させるための情報連携基盤プログラム。

Images