(57)【要約】【課題】定義するメニューの数を削減し、システム管理者の運用負荷およびリソースを削減する。【解決手段】メニュー生成システムは、サービスが定義された基本メニュー情報を記憶するメニュー記憶手段と、ユーザの権限とサービスとを対応付けたアクセス権限記憶手段と、ユーザ毎のメニュー情報を生成するメニュー生成手段と、を有し、メニュー生成手段は、ユーザＩＤを含むメニュー生成要求を受け付けて、メニュー記憶手段から基本メニュー情報を読み出し、ユーザＩＤに対応する権限を特定し、当該権限に対応するサービスをアクセス権限記憶手段から抽出して、アクセス可能なサービスリストを生成し、基本メニュー情報に設定されたサービスと前記サービスリストとを比較し、サービスリストに存在しないサービスを前記基本メニュー情報から削除して、ユーザＩＤのメニュー情報を生成する。【選択図】図１
2007065971.tif 000002
【特許請求の範囲】
【請求項１】
メニュー生成システムであって、
少なくとも１つのサービスが定義された基本メニュー情報を記憶するメニュー記憶手段と、
ユーザの権限と、前記サービスとを対応付けたアクセス権限記憶手段と、
前記基本メニュー情報に基づいて、ユーザ毎のメニュー情報を生成するメニュー生成手段と、を有し、
前記メニュー生成手段は、
ユーザＩＤを含むメニュー生成要求を受け付けて、前記メニュー記憶手段から基本メニュー情報を読み出し、
前記ユーザＩＤに対応する権限を特定し、当該権限に対応するサービスを前記アクセス権限記憶手段から抽出して、アクセス可能なサービスリストを生成し、
前記基本メニュー情報に設定されたサービスと前記サービスリストとを比較し、前記サービスリストに存在しないサービスを前記基本メニュー情報から削除して、前記ユーザＩＤのメニュー情報を生成すること
を特徴とするメニュー生成システム。
【請求項２】
請求項１記載のメニュー生成システムであって、
ユーザが所属する会社毎に、アクセス不可能な未提供サービスが記憶された未提供サービス記憶手段を、さらに有し、
前記メニュー生成手段は、
ユーザＩＤおよび会社コードを含むメニュー生成要求を受け付けて、前記メニュー記憶手段から基本メニュー情報を読み出し、
前記未提供サービス記憶手段を参照し、前記受け付けた会社コードに対応する未提供サービスを特定し、当該未提供サービスと一致するサービスが前記基本メニュー情報に設定されている場合、当該未提供サービスを前記基本メニュー情報から削除して、前記ユーザＩＤのメニュー情報を生成すること
を特徴とするメニュー生成システム。
【請求項３】
請求項１記載のメニュー生成システムであって、
ユーザの正当性を認証するための認証テーブルと、
前記認証テーブルを参照してユーザの正当性を認証し、ユーザの正当性を示す証明書を発行する認証手段とを、さらに有し、
前記メニュー生成手段は、前記証明書とともに、前記生成したメニュー情報をクライアントに送信すること
を特徴とするメニュー生成システム。
【請求項４】
請求項１記載のメニュー生成システムであって、
前記メニュー生成手段が生成するメニュー情報は、階層構造を用いて前記サービスが定義されていること
を特徴とするメニュー生成システム。
【請求項５】
情報処理装置が行うメニュー生成方法であって、
前記情報処理装置は、少なくとも１つのサービスが定義された基本メニュー情報を記憶するメニュー記憶部と、ユーザの権限と前記サービスとを対応付けたアクセス権限記憶部と、処理部と、を有し、
前記処理部は、
ユーザＩＤを含むメニュー生成要求を受け付けて、前記メニュー記憶部から基本メニュー情報を読み出すステップと、
前記ユーザＩＤに対応する権限を特定し、当該権限に対応するサービスを前記アクセス権限記憶部から抽出して、アクセス可能なサービスリストを生成するステップと、
前記基本メニュー情報に設定されたサービスと前記サービスリストとを比較し、前記サービスリストに存在しないサービスを前記基本メニュー情報から削除して、前記ユーザＩＤのメニュー情報を生成するステップと、を行うこと
を特徴とするメニュー生成方法。
【請求項６】
情報処理装置が実行するメニュー生成プログラムであって、
前記情報処理装置は、少なくとも１つのサービスが定義された基本メニュー情報を記憶するメニュー記憶部と、ユーザの権限と前記サービスとを対応付けたアクセス権限記憶部と、処理部と、を有し、
前記処理部に、
ユーザＩＤを含むメニュー生成要求を受け付けて、前記メニュー記憶部から基本メニュー情報を読み出すステップと、
前記ユーザＩＤに対応する権限を特定し、当該権限に対応するサービスを前記アクセス権限記憶部から抽出して、アクセス可能なサービスリストを生成するステップと、
前記基本メニュー情報に設定されたサービスと前記サービスリストとを比較し、前記サービスリストに存在しないサービスを前記基本メニュー情報から削除して、前記ユーザＩＤのメニュー情報を生成するステップと、を実行させること
を特徴とするメニュー生成プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザの権限に応じたメニューを生成する技術に関する。
【背景技術】
【０００２】
一度の認証で複数のシステムへアクセス可能なシングルサインオンを実現する技術として、ＳＡＭＬ（Security Assertion Markup Language）がある。ＳＡＭＬのプロトコルを用いることで、認証情報やアクセス制御情報を送受信することができる。
【０００３】
なお、ＳＡＭＬを用いた認証技術としては、例えば、特許文献１に、サービス証明書の記載内容に応じて、サービス手順を切り替える認証決済方法が記載されている。また、特許文献２には、サービス提供事業者間でのユーザ情報の送受信を中継するユーザ情報流通システムが記載されている
【特許文献１】特開２００４−１２６８８７
【特許文献２】特開２００４−３６２１８９
【発明の開示】
【発明が解決しようとする課題】
【０００４】
さて、ＳＡＭＬなどを用いた一般的な認証システムでは、ユーザの認証を行った後に、当該ユーザのアクセス権限に応じて利用可能なサービスが表示されたメニューを、ユーザ（クライアント）に提示する必要がある。
【０００５】
しかしながら、各ユーザのアクセス権限に応じたメニューを、ユーザ毎に定義する場合、ユーザ数の増加に伴い、定義するメニューの数も増加し、運用および管理面での作業負荷が増大する。また、ユーザ毎に定義されたメニューを格納するためのリソースも増大する。
【０００６】
本発明は上記事情に鑑みてなされたものであり、本発明の目的は、定義するメニューの数を削減することにより、システム管理者の運用負荷およびリソースを削減することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明は、例えば、メニュー生成システムであって、少なくとも１つのサービスが定義された基本メニュー情報を記憶するメニュー記憶手段と、ユーザの権限と前記サービスとを対応付けたアクセス権限記憶手段と、前記基本メニュー情報に基づいて、ユーザ毎のメニュー情報を生成するメニュー生成手段と、を有し、前記メニュー生成手段は、ユーザＩＤを含むメニュー生成要求を受け付けて、前記メニュー記憶手段から基本メニュー情報を読み出し、前記ユーザＩＤに対応する権限を特定し、当該権限に対応するサービスを前記アクセス権限記憶手段から抽出して、アクセス可能なサービスリストを生成し、前記基本メニュー情報に設定されたサービスと前記サービスリストとを比較し、前記サービスリストに存在しないサービスを前記基本メニュー情報から削除して、前記ユーザＩＤのメニュー情報を生成する。
【発明の効果】
【０００８】
本発明では、あらかじめ定義するメニューの数を削減することにより、システム管理者の運用負荷およびリソースを、より削減することができる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明の実施の形態について説明する。
【００１０】
図１は、本発明の一実施形態が適用された認証システムの全体構成図である。なお、本実施形態の認証システムでは、ＳＡＭＬのプロトコルを用いるものとする。
【００１１】
図示する認証システムは、クライアント１と、認証プレゼンテーションサーバ（以下、「認証ＰＬサーバ」）２と、認証ビジネスロジックサーバ（以下、「認証ＢＬサーバ」）３と、少なくとも１つのアプリケーションサーバ４と、を有する。
【００１２】
なお、クライアント１と、認証ＰＬサーバ２およびアプリケーションサーバ４とは、インーネットなどの第１のネットワーク８により接続され、メッセージの送受信にはＨＴＴＰ（HyperText Transfer Protocol）などが用いられる。また、認証ＰＬサーバ２およびアプリケーションサーバ４と、認証ＢＬサーバ３とは、第２のネットワーク９により接続され、メッセージの送受信にはＨＴＴＰまたはＳＯＡＰ（Simple Object Access Protocol）などが用いられる。なお、第１のネットワーク８と第２のネットワーク９とを統合した１つのネットワークに、各装置が接続されていることとしてもよい。
【００１３】
クライアント１は、まず、認証ＰＬサーバ２にアクセスする。そして、クライアント１は、認証ＰＬサーバ２および認証ＢＬサーバ３が行うユーザ認証に成功した後に、所望のアプリケーションサーバ４にアクセスする。なお、クライアント１は、Ｗｅｂブラウザ（不図示）などを備えるものとする。また、本実施形態では、クライアント１を使用する各ユーザは、所定の会社に所属する社員ユーザであって、所属する会社の会社コードおよびユーザＩＤがあらかじめ設定されているものとする。
【００１４】
認証ＰＬサーバ２および認証ＢＬサーバ３は、複数のアプリケーションサーバ４に対して、共通の認証処理を行い、シングルサインオンを実現する。すなわち、認証ＰＬサーバ２および認証ＢＬサーバ３は、ユーザ認証後に、ユーザの権限に応じてアクセス可能なサービスが設定されたメニュー情報を生成することにより、ユーザのアクセスを制御する。
【００１５】
認証ＰＬサーバ２は、クライアント１に対する入出力処理を行う。図示する認証ＰＬサーバ２は、制御部２１と、メニュー変換部２２と、を有する。制御部２１は、クライアント１から送信されたデータを受け付けて認証ＢＬサーバ３に送信するとともに、認証ＢＬサーバ３から送信されたデータをクライアント１に送信する。メニュー変換部２２は、認証ＢＬサーバ３が生成したメニュー情報を、ＨＴＭＬ（HyperText Markup Language）などの所定の形式に変換する。
【００１６】
認証ＢＬサーバ３は、認証ＰＬサーバ２の要求に応じてユーザ認証を行い、認証に成功した後に当該ユーザのメニュー情報を動的に生成する。図示する認証ＢＬサーバ３は、認証部３１と、属性情報取得部３２と、メニュー生成部３３と、ユーザ属性ＤＢ３４と、認証テーブル３５と、メニュー情報テーブル３６と、ロールマッピングテーブル３７と、アクセス権限テーブル３８、未提供サービステーブル３９と、サービス定義テーブル４０と、を有する。
【００１７】
認証部３１は、認証テーブル３５を参照して、ユーザの正当性を認証する。属性情報取得部３２は、要求されたユーザの属性情報をユーザ属性ＤＢ３４から取得し、認証ＰＬサーバ２（または、アプリケーションサーバ４）に送信する。メニュー生成部３３は、各種テーブル３５〜４０を参照し、ユーザ毎のメニュー情報を動的に生成する。ユーザ属性ＤＢ３４には、認証ＰＬサーバ２またはアプリケーションサーバ４に引き渡すユーザ属性情報（例えば、住所、氏名、年齢などの個人情報）が記憶されている。なお、各種テーブル３５〜４０については後述する。
【００１８】
アプリケーションサーバ４は、例えばＷｅｂサーバなどであって、各種のサービスをクライアント１に提供する。図示するアプリケーションサーバ４は、アクセス制御部４１と業務処理部４２と、を有する。アクセス制御部４１は、クライアント１からアクセス要求を受け付け、所望のサービスへのアクセスを制御する。なお、アクセス制御部４１は、必要に応じて、認証ＢＬサーバ３にアクセス可否を問い合わせ、認証ＢＬサーバ３の認証結果（アクセス許可、アクセス拒否）に基づいてアクセス制御を行うこととしてもよい。業務処理部４２は、クライアントにサービスを提供する。
【００１９】
上記説明した、クライアント１、認証ＰＬサーバ２、認証ＢＬサーバ３およびアプリケーションサーバ４は、いずれも、例えば図２に示すようなＣＰＵ９０１と、メモリ９０２と、ＨＤＤ等の外部記憶装置９０３と、キーボードやマウスなどの入力装置９０４と、ディスプレイやプリンタなどの出力装置９０５と、ネットワークと接続するための通信制御装置９０６と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。
【００２０】
例えば、認証ＰＬサーバ２、認証ＢＬサーバ３およびアプリケーションサーバ４の各機能は、認証ＰＬサーバ２用のプログラムの場合は認証ＰＬサーバ２のＣＰＵ９０１が、認証ＢＬサーバ３用のプログラムの場合は認証ＢＬサーバ３のＣＰＵ９０１が、そして、アプリケーションサーバ４用のプログラムの場合はアプリケーションサーバ４のＣＰＵ９０１が、それぞれ実行することにより実現される。なお、認証ＢＬサーバ３のユーザ属性ＤＢ３４および各種テーブル３５〜４０には、認証ＢＬサーバ３のメモリ９０２または外部記憶装置９０３が用いられるものとする。また、入力装置９０４および出力装置９０５については、各装置が必要に応じて備えるものとする。
【００２１】
次に、認証ＢＬサーバ３の各種テーブル３５〜４０について説明する。
【００２２】
図３は、各種テーブル３５〜４０の関係を模式的に示したテーブル関連図である。認証テーブル３５は、ユーザの本人性（Identity）を認証するためのテーブルであって、会社コードと、ユーザＩＤと、メニューＩＤと、を有する。メニュー情報テーブル３６は、メニューＩＤと、対応する基本メニュー情報とが記憶されたテーブルである。
【００２３】
ロールマッピングテーブル３７は、ユーザＩＤとロールとを対応付けたテーブルである。ロールは、ユーザの権限（役割）を示すものである。本実施形態では、各ユーザと当該ユーザが使用可能なサービスとを対応づける（紐付ける）ために、ロールという概念を用いるものとする。ロールの種類としては、例えば、通常業務ロールと、経営情報閲覧ロールなどが考えられる。この場合、ロールマッピングテーブル３７では、一般社員のユーザＩＤには通常業務ロールのみが設定され、役員のユーザＩＤには通常業務ロールおよび経営情報閲覧ロールが設定されるものとする。なお、本実施形態では、各システムＩＤに、少なくとも１つのロールが定義されているものとする。また、システムＩＤは、各アプリケーションサーバ４が提供するアプリケーションシステムを識別する識別情報である。
【００２４】
アクセス権限テーブル３８は、各ロールと、当該ロールがアクセス可能なサービスとを対応付けたテーブルである。図示する例では、ロールａはサービスＡ、Ｂに、ロールｂはサービスＢに、そして、ロールｃはサービスＣ、Ｆ、Ｇ、Ｈに、それぞれアクセスできることを示している。未提供サービステーブル３９は、会社毎に、当該会社のユーザには提供しない未提供サービスが定義されたテーブルである。サービス定義テーブル４０は、サービス毎に、メニュー情報の生成に必要な定義情報が記憶されたテーブルである。
【００２５】
図４は、認証テーブル３５の一例を示した図である。認証テーブル３５は、ユーザの正当性を認証するためのテーブルである。図示する認証テーブル３５は、会社コード３５１、ユーザＩＤ３５２、パスワード３５３、メニューＩＤ３５４、パスワード有効期限３５５などを有する。なお、メニューＩＤ３５４は、後述する基本メニュー情報を識別するための識別情報である。
【００２６】
図５は、メニュー情報テーブル３６の一例を示した図である。メニュー情報テーブル３６は、会社コード３６１と、メニューＩＤ３６２と、基本メニュー情報３６３とを有する。基本メニュー情報３６３は、基本となるメニュー画面の定義情報（いわゆる、テンプレート、雛型）である。なお、本実施形態では、基本メニュー情報３６３は、ＸＭＬ（eXtensible Markup Language）を用いて記述されるものとする。なお、ＸＭＬは、文書やデータの意味および構造を記述するためのマークアップ言語である。
【００２７】
また、本実施形態では、基本メニュー情報３６３は、会社毎に、かつ、所定のカテゴリー毎に作成されるものとする。例えば、職種毎に基本メニュー情報を作成する場合、Ａ会社の基本メニュー情報には、営業用基本メニュー情報、総務用基本メニュー情報、財務用基本メニュー情報などがあるものとする。また、役職毎に基本メニュー情報を作成する場合、Ｂ会社の基本メニュー情報には、一般社員用基本メニュー情報、課長用基本メニュー情報、部長用基本メニュー情報などがあるものとする。
【００２８】
所定のカテゴリー毎に基本メニュー情報を作成することにより、例えば、営業用基本メニューでは、営業の業務で使用頻度の高いサービスがメニュー画面の上部に目立つように表示されるなど、使用するユーザにとって使い勝手のよいメニュー画面を生成することができる。
【００２９】
図６は、ロールマッピングテーブル３７の一例を示した図である。ロールマッピングテーブル３７は、ユーザとロールとを対応付けたテーブルである。図示するロールマッピングテーブル３７は、会社コード３７１と、ユーザＩＤ３７２と、システムＩＤ３７３と、ロールを識別するためのロールＩＤ３７４と、を有する。なお、図示するロールマッピングテーブル３７は、１つのレコードで複数のロールＩＤを設定可能なように、ロールＩＤ３７４が配列（繰り返し）構造となっている。また、１人のユーザが、複数のシステムにアクセス可能な場合は、１つのユーザＩＤに対して複数のレコードが作成される。
【００３０】
図７は、アクセス権限テーブル３８の一例を示した図である。アクセス権限テーブル３８は、各ロールと、当該ロールがアクセス可能なサービスとを対応付けたテーブルである。図示するアクセス権限テーブル３８は、会社コード３８１と、システムＩＤ３８２と、ロールＩＤ３８３と、サービスＩＤ３８４とを有する。なお、図示するアクセス権限テーブル３８は、１つのレコードで複数のサービスＩＤを設定可能なように、サービスＩＤ３８４が配列（繰り返し）構造となっている。
【００３１】
図８は、未提供サービステーブル３９の一例を示した図である。図示する未提供サービステーブル３９は、会社コード３９１と、システムＩＤ３９２と、未提供サービスＩＤ３９３とを有する。なお、図示する未提供サービステーブル３９は、１つのレコードで複数の未提供サービスＩＤを設定可能なように、未提供サービスＩＤ３９３が配列（繰り返し）構造となっている。
【００３２】
図９は、サービス定義テーブル４０の一例を示す図である。サービス定義テーブル４０は、システムＩＤ４０１と、サービスＩＤ４０２と、サービス名称４０３と、ＵＲＬ（Uniform Resource Locator）４０４と、表示ウィンドウ情報４０５などを有する。ＵＲＬ４０４には、サービスが存在するネットワーク上の住所（宛先）が設定される。表示ウィンドウ情報４０５には、表示する文字の大きさや色などの文字制御情報や、アイコンの画像情報などが設定される。
【００３３】
次に、本実施形態の認証処理の全体概要について説明する。
【００３４】
図１０は、認証処理のシーケンス図である。
【００３５】
まず、クライアント１は、認証ＰＬサーバ２にログインする（Ｓ１１）。すなわち、クライアント１は、ユーザが入力した会社コード、ユーザＩＤおよびパスワードを受け付け、これらの情報を含むログインメッセージを認証ＰＬサーバ２に送信する。
【００３６】
そして、認証ＰＬサーバ２の制御部２１は、クライアント１からログインメッセージを受信し、当該ログインメッセージの認証要求を、認証ＢＬサーバ３に送信する（Ｓ１２）。なお、認証要求には、受信したログインメッセージの会社コードと、ユーザＩＤと、パスワードとが含まれている。
【００３７】
認証ＢＬサーバ３の認証部３１は、認証要求を認証ＰＬサーバ２から受信する。そして、認証部３１は、認証テーブル３５を参照し、ログインしたユーザが正当なユーザか否かを認証する。すなわち、認証部３１は、認証要求に含まれる会社コード、ユーザＩＤおよびパスワードが、認証テーブル３５に存在する場合は正当なユーザであると判別する。一方、認証テーブル３５に存在しない場合、認証部３１は、不正なユーザであると判別する。
【００３８】
正当なユーザであると判別した場合、認証部３１は、正当なユーザであることを証明するアカウント識別子（アーティファクト）を発行し、認証ＰＬサーバ２に送信する（Ｓ１３）。なお、アカウント識別子は、認証要求に含まれる会社コードおよびユーザＩＤと、認証を行った日時などから生成されるものとする。
【００３９】
そして、認証ＰＬサーバ２の制御部２１は、認証に成功した旨を示すアカウント識別子を受信する。そして、制御部２１は、必要に応じて、ユーザの氏名など所定のユーザ属性情報を要求する属性情報要求を、認証ＢＬサーバ３に送信する（Ｓ１４）。なお、属性情報要求には、認証ＢＬサーバ３から受信したアカウント識別子が付加されているものとする。
【００４０】
認証ＢＬサーバ３の属性情報取得部３２は、属性情報要求を受信し、当該属性情報要求に付加されたアカウント識別子から特定されるユーザの属性情報を、ユーザ属性ＤＢ３４から取得する。そして、属性情報取得部３２は、取得したユーザ属性情報と、アカウント識別子とを、認証ＰＬサーバ２に送信する（Ｓ１５）。
【００４１】
そして、認証ＰＬサーバ２の制御部２１は、メニュー情報の生成要求を認証ＢＬサーバ３に送信する（Ｓ１６）。なお、メニュー情報の生成要求には、アカウント識別子が付加されているものとする。認証ＢＬサーバ３のメニュー生成部３３は、メニュー生成要求を受け付けて、ユーザのアクセス権限に従ったメニュー情報を生成する。なお、メニュー情報の生成処理については、後述する。そして、メニュー生成部３３は、生成したメニュー情報と、アカウント識別子とを、認証ＰＬサーバ２に送信する（Ｓ１７）。そして、認証ＰＬサーバ２のメニュー変換部２２は、受信したメニュー情報を所定の形式に変換し、アカウント識別子とともに、クライアント１に送信する（Ｓ１８）。なお、本実施形態では、ＸＭＬ形式のメニュー情報を、ＨＴＭＬ形式に変換するものとする。
【００４２】
クライアント１は、メニュー情報およびアカウント識別子を受信する。そして、クライアント１は、Ｗｅｂブラウザを用いてメニュー情報を解析し、アクセス可能なサービスが表示されたメニュー画面を出力装置に表示する。
【００４３】
図１１は、クライアント１に表示されたメニュー画面の一例を示す図である。図示するメニュー画面は、階層構造を用いて各サービスが表示されている。具体的には、フォルダ１の下位階層にサービスＡおよびサービスＢが表示され、フォルダ２に接続されたフォルダ２−１の下位階層にサービスＦが表示されている。また、各サービスの表示部分には、サービス定義テーブル４０に設定されたＵＲＬがリンク先として埋め込まれているものとする。また、各サービスの表示は、サービス定義テーブル４０に設定されたウィンドウ情報に従って表示されるものとする。
【００４４】
ユーザは、クライアント１に表示されたメニュー画面を参照し、所望のサービスをクリックするなどして、所望のサービスへのアクセス要求を入力する。クライアント１は、ユーザの入力を受け付けて、入力されたサービスのＵＲＬを宛先として、所定のアプリケーションサーバ４にアクセスする（Ｓ１９）。なお、クライアント１は、アプリケーションサーバにアクセスする際に、アカウント識別子をアプリケーションサーバ４に送信する。アプリケーションサーバ４では、アカウント識別子を受信することにより、クライアント１のユーザを再度認証することなく所望のサービスへのアクセスを許可する。
【００４５】
次に、認証ＢＬサーバ３のメニュー生成処理について説明する。
【００４６】
図１２および図１３は、メニュー生成処理のフローチャートである。
【００４７】
図１２では、認証ＢＬサーバ３のメニュー生成部３３は、アカウント識別子が付加されたメニュー情報の生成要求を、認証ＰＬサーバ２から受信する（図１０：Ｓ１６）。そして、メニュー生成部３３は、アカウント識別子に含まれる会社コードおよびユーザＩＤを特定する（Ｓ２１）。
【００４８】
そして、メニュー生成部３３は、ロールマッピングテーブル３７を参照し、Ｓ２１で特定した会社コードおよびユーザＩＤを検索キーとして、該当する全てのシステムＩＤおよびロールＩＤを取得する（Ｓ２２）。そして、メニュー生成部３３は、アクセス権限テーブル３８を参照し、Ｓ２４で取得したロールＩＤ各々を検索キーとして、各ロールＩＤがアクセス可能なサービスＩＤを全て取得する。そして、メニュー生成部３３は、取得した全てのサービスＩＤが設定された提供サービスリストを生成し、メモリまたは外部記憶装置（以下、「メモリ等」）に記憶する（Ｓ２３）。
【００４９】
そして、メニュー生成部３３は、未提供サービステーブル３９を参照し、Ｓ２１で特定した会社コードを検索キーとして、当該会社に対してサービス提供を行わない未提供サービスＩＤを取得し、メモリ等に記憶する（Ｓ２４）。なお、当該会社コードの未提供サービスＩＤが未提供サービステーブル３９に登録されていない場合は、次の処理に進む。
【００５０】
そして、メニュー生成部３３は、認証テーブル３５を参照し、Ｓ２１で特定した会社コードおよびユーザＩＤのメニューＩＤを取得する（Ｓ２５）。そして、メニュー生成部３３は、メニュー情報テーブル３６を参照し、Ｓ２１で特定した会社コードおよびＳ２５で取得したメニューＩＤを検索キーとして、対応する基本メニュー情報を読み出し、メモリ等に記憶する（Ｓ２６）。なお、基本メニュー情報は、ＸＭＬを用いて記述されて、アクセス可能な各サービスが階層構造で記述されている（図３参照）。
【００５１】
そして、図１３において、メニュー生成部３３は、メモリ等に記憶した基本メニュー情報のタグを解析し、＜ｎｏｄｅ＞エントリを特定する（Ｓ２７）。＜ｎｏｄｅ＞エントリは、サービスを格納するフォルダを示すものである。そして、メニュー生成部３３は、基本メニュー情報のタグを解析し、Ｓ２７で特定した＜ｎｏｄｅ＞エントリの中の＜ｌｅａｆ＞エントリを特定し、当該＜ｌｅａｆ＞エントリに記述されたサービスＩＤを取得する（Ｓ２８）。
【００５２】
そして、メニュー生成部３３は、Ｓ２３で生成した提供サービスリストをメモリ等から読み出し、Ｓ２８で取得したサービスＩＤが当該提供サービスリストに存在するか否かを判別する（Ｓ２９）。提供サービスリストに存在する場合（Ｓ２９：ＹＥＳ）、メニュー生成部３３は、Ｓ２４で取得した未提供サービスＩＤをメモリ等から読み出し、Ｓ２８で取得したサービスＩＤが未提供サービスＩＤのいずれかと一致するか否かを判別する（Ｓ３０）。
【００５３】
未提供サービスＩＤと一致しない場合（Ｓ３０：ＮＯ）、メニュー生成部３３は、サービス定義テーブル４０を参照し、Ｓ２８で取得したサービスＩＤの定義情報を取得する。そして、メニュー生成部３３は、基本メニュー情報のＳ２８で特定した＜ｌｅａｆ＞エントリに、取得した定義情報を記述する（Ｓ３１）。一方、提供サービスリストに存在しない場合（Ｓ２９：ＮＯ）、または、いずれかの未提供サービスＩＤと一致する場合（Ｓ３０：ＹＥＳ）、メニュー生成部３３は、Ｓ２８で特定した＜ｌｅａｆ＞エントリを、基本メニュー情報から削除する（Ｓ３２）。
【００５４】
そして、メニュー生成部３３は、基本メニュー情報を解析し、Ｓ２７で特定した＜ｎｏｄｅ＞エントリの中に、次の＜ｌｅａｆ＞エントリが記述されているか否かを判別する（Ｓ３３）。次の＜ｌｅａｆ＞エントリが記述されている場合（Ｓ３３：ＹＥＳ）、メニュー生成部３３は、Ｓ２８に戻り、繰り返し以降の処理を行う。一方、次の＜ｌｅａｆ＞エントリが記述されていない場合（Ｓ３３：ＮＯ）、メニュー生成部３３は、当該＜ｎｏｄｅ＞エントリの中に、少なくとも１つの＜ｌｅａｆ＞エントリが記述されているか否かを判別する（Ｓ３４）。すなわち、メニュー生成部３３は、Ｓ３２で＜ｌｅａｆ＞エントリが削除された結果、＜ｎｏｄｅ＞エントリに格納されるサービスＩＤが存在しないか否かを判別する。
【００５５】
＜ｌｅａｆ＞エントリが記述されていない場合（Ｓ３４：ＮＯ）、メニュー生成部３３は、当該＜ｎｏｄｅ＞エントリを基本メニュー情報から削除する（Ｓ３５）。そして、メニュー生成部３３は、基本メニュー情報を解析し、次の＜ｎｏｄｅ＞エントリが記述されているか否かを判別する（Ｓ３６）。次の＜ｎｏｄｅ＞エントリが記述されている場合（Ｓ３６：ＹＥＳ）、メニュー生成部３３は、Ｓ２７に戻り、繰り返し以降の処理を行う。一方、次の＜ｎｏｄｅ＞エントリが記述されていない場合（Ｓ３６：ＮＯ）、メニュー生成部３３は、本処理を終了する。
【００５６】
以下に、図３に示すテーブル関連図を用いて、メニュー生成処理を具体的に説明する。図示するメニュー情報テーブル３６の基本メニュー情報では、フォルダ１の＜ｎｏｄｅ＞エントリには、「サービスＡ」および「サービスＢ」の＜ｌｅａｆ＞エントリが記述されている。また、アクセス権限テーブル３８では、ロールａまたはロールｂからサービスＡおよびサービスＢが関連付けられている。したがって、メニュー生成部３３は、サービス定義テーブル４０から「サービスＡ」および「サービスＢ」の定義情報を取得し、基本メニュー情報に追加する。
【００５７】
また、図示する基本メニュー情報では、フォルダ２−１の＜ｎｏｄｅ＞エントリには、「サービスＤ」および「サービスＦ」の＜ｌｅａｆ＞エントリが記述されている。また、アクセス権限テーブル３８では、「サービスＤ」にはいずれのロールも関連付けられていないが、「サービスＦ」にはロールｃが関連付けられている。したがって、メニュー生成部３３は、基本メニュー情報から「サービスＤ」の＜ｌｅａｆ＞エントリを削除する。そして、メニュー生成部３３は、サービス定義テーブル４０から「サービスＦ」の定義情報を取得し、基本メニュー情報に追加する。
【００５８】
また、図示する基本メニュー情報では、フォルダ２−２の＜ｎｏｄｅ＞エントリには、「サービスＨ」の＜ｌｅａｆ＞エントリが記述されている。また、アクセス権限テーブル３８では、「サービスＨ」にはロールｃが関連付けられている。しかしながら、未提供サービステーブル３９には、「サービスＨ」が設定されている。したがって、メニュー生成部３３は、基本メニュー情報から「サービスＨ」の＜ｌｅａｆ＞エントリを削除する。これにより、フォルダ２−２の＜ｎｏｄｅ＞エントリには＜ｌｅａｆ＞エントリが存在しなくなるため、メニュー生成部３３は、基本メニュー情報からフォルダ２−２の＜ｎｏｄｅ＞エントリを削除する。以上説明した処理を行うことにより、図３に示す基本メニュー情報をカスタマイズし、図１１に示すメニュー画面のメニュー情報を生成する。
【００５９】
本実施形態では、メニュー情報テーブルに基本メニュー情報をあらかじめ定義しておき、当該基本メニュー情報をユーザの権限に応じてカスタマイズして、ユーザ固有のメニュー情報を動的に生成する。これにより、ユーザ毎にメニュー情報を定義する必要がなくなり、あらかじめ定義するメニューの数を削減することができる。また、システム管理者の運用負荷およびリソースを削減することができる。
【００６０】
また、本実施形態の基本メニュー情報は、アクセス可能な各サービスを、階層構造をもって定義している。したがって、基本メニュー情報から生成されるメニュー画面は、フォルダ単位に各サービスが表示されるため、ユーザインターフェースが向上する。
【００６１】
また、本実施形態では、所定のカテゴリー毎に基本メニュー情報を複数作成する。これにより、職種や役職などのユーザ属性に適した基本メニューをカスタマイズすることで、より使い勝手のよいメニュー画面を生成することができる。
【００６２】
また、本実施形態の認証ＢＬサーバ３は、未提供サービステーブルを備える。これにより、所定の会社については、提供を行わない未提供サービスを除外したメニュー情報を生成することができる。すなわち、未提供サービスを備えることにより、あらかじめ定義するメニューの数をより削減することができる。
【００６３】
なお、本発明は上記の実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記実施形態では、認証ＰＬサーバ２を有し、認証ＢＬサーバ３が生成したメニュー情報（ＸＭＬ文書）を、ＨＴＭＬ形式に変換する。しかしながら、クライアント１に、認証ＰＬサーバ２の機能を実装したリッチクライアント（rich client）を用いる場合、認証ＰＬサーバ２は不要となる。
【図面の簡単な説明】
【００６４】
【図１】本発明の一実施形態が適用された認証システムの全体構成を示す図である。
【図２】各装置のハードウェア構成例を示す図である。
【図３】各テーブルの関連を示すテーブル関連図である。
【図４】認証テーブルの一例を示す図である。
【図５】メニュー情報テーブルの一例を示す図である。
【図６】ロールマッピングテーブルの一例を示す図である。
【図７】アクセス権限テーブルの一例を示す図である。
【図８】未提供サービステーブルの一例を示す図である。
【図９】サービス定義テーブルの一例を示す図である。
【図１０】認証処理の全体シーケンス図である。
【図１１】メニュー画面の一例を示す図である。
【図１２】メニュー生成処理のフローチャートである。
【図１３】メニュー生成処理のフローチャートである。
【符号の説明】
【００６５】
１：クライアント、２：認証ＰＬサーバ、２１：制御部、２２：メニュー変換部、３：認証ＢＬサーバ、３１：認証部、３２：属性情報取得部、３３：メニュー生成部、３４：ユーザ属性情報、３５：認証テーブル、３６：メニュー情報テーブル、３７：ロールマッピングテーブル、３８：アクセス権限テーブル、３９：未提供サービステーブル、４０：サービス定義テーブル、４：アプリケーションサーバ、４１：アクセス制御部、４２：業務処理部、８：第１のネットワーク、９：第２のネットワーク
【図１】
2007065971.tif 000003
【図２】
2007065971.tif 000004
【図３】
2007065971.tif 000005
【図４】
2007065971.tif 000006
【図５】
2007065971.tif 000007
【図６】
2007065971.tif 000008
【図７】
2007065971.tif 000009
【図８】
2007065971.tif 000010
【図９】
2007065971.tif 000011
【図１０】
2007065971.tif 000012
【図１１】
2007065971.tif 000013
【図１２】
2007065971.tif 000014
【図１３】
2007065971.tif 000015