JP4750020B2 - ユーザ認証のためのシステム、方法、およびプログラムならびに該プログラムを記録した記録媒体 - Google Patents

Description

本発明は、一般的には、ユーザ認証技術に関し、より詳細には、連邦化されたコンピューティング環境において、ユーザを認証するシステム、方法およびプログラムに関する。

近年、多くのコンピュータ関連企業は、インターネット技術を利用してビジネス取引を自動化するためにウェブ・サービス関連技術の開発を進めている。ウェブ・サービスは、複数の企業システム間での電子商取引の効率化を実現することを目的の一つとする。より詳細には、ウェブ・サービスは、ウェブベースのアプリケーション・プログラムが自動的に関連する他のアプリケーション・プログラムを探し出すことで、複数の企業システム間の連携を実現する仕組みを提供する。

そのようなウェブ・サービスのためのセキュリティ仕様である”ＷＳ−Ｓｅｃｕｒｉｔｙ”がインターナショナル・ビジネス・マシーンズ・コーポレーション、マイクロソフト・コーポレーションおよびベリサイン・インクによって公開された（非特許文献１）。“ＷＳ−Ｓｅｃｕｒｉｔｙ”では、互いに信頼関係が確立された複数のサーバを含む連邦化されたコンピューティング環境でシングル・サインオンを実現する仕組みを定義している。ここで、「信頼関係」とは、２以上のサーバのうちのいずれか１つの認証システムにおいてユーザ認証に成功したことをもって、他のサーバに対してもそのユーザを認証されたとして取り扱う場合の当該２以上のサーバの間の関係をいう。なお、前述の連邦化の仕様の一例は、”ＷＳ−Ｆｅｄｅｒａｔｉｏｎ”として公開されている（非特許文献２）。

背景技術では、ユーザは、複数のサーバを含む連邦化されたコンピューティング環境を利用しようとする場合、セキュリティ・トークンを取得するために複数のサーバのうちのいずれかのサーバの認証システムを使用してユーザ認証を行う。次に、取得したセキュリティ・トークンを含むＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）メッセージに署名をした上で、ウェブ・サービスを提供するサーバにそのＳＯＡＰメッセージを送信する。ＳＯＡＰメッセージを受信したサーバは、そのＳＯＡＰメッセージに含まれるセキュリティ・トークンを検証し、検証に成功したことに応じて、ユーザに対してサービスの返信をする。

上記の”ＷＳ−Ｓｅｃｕｒｉｔｙ”の仕様が正式に受理され、製品として実装されることで普及すれば、企業間システムのシームレスな連携が加速され、例えば、多数の企業システムが参加する大規模なサプライチェーン・システムが実現するだろう。

丸山宏ほか著、「Ｗｅｂ Ｓｅｒｖｉｃｅ Ｓｅｃｕｒｉｔｙ（ＷＳ−Ｓｅｃｕｒｉｔｙ）」、２００２年 ４月 ５日、インターナショナル・ビジネス・マシーンズ・コーポレーション／マイクロソフト・コーポレーション／ベリサイン・インク発行 丸山宏ほか著、「Ｗｅｂ Ｓｅｒｖｉｃｅ Ｆｅｄｅｒａｔｉｏｎ Ｌａｎｇｕａｇｅ（ＷＳ−Ｆｅｄｅｒａｔｉｏｎ）」、２００３年 ７月 ８日、インターナショナル・ビジネス・マシーンズ・コーポレーション／マイクロソフト・コーポレーション／ベリサイン・インク発行

連邦化されたコンピューティング環境において、すべてのサーバの認証システムが同一の認証ポリシー（認証ポリシーは、指紋認証、声紋認証その他の認証形式や個々の認証形式における規約（文字数、有効期限、データサイズその他）、およびそれらの組合せを含むユーザ認証の形式の全てを含む概念である。）を採用しているのであれば、ユーザは、同一の認証情報を登録することで、いずれのサーバの認証システムを自分が使用しているのかを意識することなく、自己の「唯一の」認証情報を使用してユーザ認証を行い、連邦化されたコンピューティング環境を利用することができるだろう。

しかしながら、連邦化されたコンピューティング環境に含まれる複数のサーバの認証システムは、それぞれ異なる認証ポリシーを採用することが多い。なぜなら、連邦化されたコンピューティング環境は、独立して運用され得る複数のシステムが参加することが予定されているからである。そのような性質に起因して連邦化されたコンピューティング環境に含まれる第１のサーバと第２のサーバが異なる認証ポリシーを採用している場合、ユーザは第１のサーバと第２のサーバそれぞれに対して、異なった認証ポリシーに適合する認証情報を設定することになる。

このようなコンピューティング環境では、ユーザは、サーバの認証システムと認証情報の対応を記憶した上で、いま自分がどの認証システムにおいて認証を試みているかを正確に意識して当該認証システムに対応する認証情報を入力することを強いられる。連邦化されたコンピューティング環境に参加するサーバの増加に比例して、ユーザが記憶すべき認証情報の数も増加するので、このオペレーションはユーザの大きな負担となる可能性がある。

そこで本発明は、上記の課題を解決することができる認証システム、認証方法、認証プログラムを提供することを目的とする。

上記課題を解決するために、本発明の第１の態様によれば、互いに信頼関係が確立された複数のサーバを含むコンピューティング環境に対するユーザ認証を行うためのシステムであって、複数のサーバのうちの少なくとも１つの認証ポリシーを登録した認証ポリシーテーブルと、ユーザから認証情報を受ける手段と、認証ポリシーテーブルを用いて、複数のサーバから認証情報と適合する認証ポリシーを採用するサーバを少なくとも１つ特定する手段と、サーバを特定する手段によって特定されたサーバの認証機構に、認証情報を用いてユーザ認証を行うように命令する信号を送信する手段と、ユーザ認証が成功したことを条件として、ユーザのコンピューティング環境へのアクセスを許可する手段と、を備えたシステムが提供される。

また、本発明の第２の態様によれば、互いに信頼関係が確立された複数のサーバを含むコンピューティング環境における方法であって、複数のサーバのうちの少なくとも１つの認証ポリシーを登録した認証ポリシーテーブルを少なくとも１つ保持し、ユーザから認証情報を受けるステップと、認証ポリシーテーブルを用いて、複数のサーバから認証情報と適合する認証ポリシーを採用するサーバを少なくとも１つ特定するステップと、サーバを特定するステップにおいて特定されたサーバの認証機構に、認証情報を用いてユーザ認証を行うように命令する信号を送信するステップと、ユーザ認証が成功したことを条件として、コンピューティング環境へのアクセスが許可されるステップと、を含む方法が提供される。

さらに、本発明の第３の態様によれば、互いに信頼関係が確立された複数のサーバを含むコンピューティング環境におけるプログラムであって、複数のサーバの少なくとも１つの認証ポリシーを登録した認証ポリシーテーブルを少なくとも１つ保持し、認証プログラムは、ユーザから認証情報を受けるステップと、認証ポリシーテーブルを用いて、複数のサーバから認証情報と適合する認証ポリシーを採用するサーバを少なくとも１つ特定するステップと、サーバを特定するステップにおいて特定されたサーバの認証機構に、認証情報を用いてユーザ認証を行うように命令する信号を送信するステップと、ユーザ認証が成功したことを条件として、コンピューティング環境へのアクセスが許可されるステップと、をコンピュータに実行させるプログラムが提供される。

また、本発明の第４の態様として、上述したプログラムを記録したコンピュータ可読の記憶媒体のようなコンピュータ・プログラム製品が提供される。

本発明によれば、連邦化されたコンピューティング環境において、より利便性の高いユーザ認証が可能となる。

以下、本発明を実施するための最良の形態を図面に基づいて詳細に説明する。なお、本発明は多くの異なる態様で実施することが可能であり、実施の形態の記載内容に限定して解釈されるべきものではなく、また実施の形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須とは限らないことに留意されたい。また、実施の形態の説明の全体を通じて同じ要素には同じ番号を付している。

以下の実施の形態では、主に方法およびシステムについて説明するが、当業者であれば明らかな通り、本発明はコンピュータで使用可能なプログラムとしても実施できる。したがって、本発明は、ハードウェアとしての実施形態、ソフトウェアとしての実施形態またはソフトウェアとハードウェアとの組合せの実施形態をとることができる。プログラムは、ハードディスク、ＣＤ−ＲＯＭ、光記憶装置または磁気記憶装置等の任意のコンピュータ可読媒体に記録できる。

図１は、本発明の実施の形態における連邦化されたコンピューティング環境１０００のシステム構成の一例を示した概念図である。連邦化されたコンピューティング環境１０００は、ネットワーク２００で互いに接続されたクライアント１００および複数のサーバ３００−１〜３００−Ｎ（以下、必要に応じてサーバ３００と総称する）を含んでいる。

クライアント１００は、周知のインターネットに接続可能な端末である。当業者は、そのようなクライアント１００を容易に実施することができる。また、クライアント１００とネットワーク２００の接続は、ダイアルアップ接続等によりＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｅｒ、図示せず）を介して行うとよい。なお、クライアント１００からＩＳＰへの接続はダイアルアップ接続に制限されるものではなく、例えば、専用線、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）、ＣＡＴＶ（Ｃａｂｌｅ ＴｅｌｅｖｉＳｉｏｎ）を用いた常時接続により行ってもよい。

ネットワーク２００は、クライアント１００、サーバ３００を接続する通信経路であり、一例としてインターネットにより実現することができる。インターネットであるネットワーク２００は周知の通り、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いてシステム間を接続する。ネットワーク２００ではグローバルアドレスまたはローカルアドレスで表されるＩＰアドレスによって相互に通信するシステムが特定される。

サーバ３００は、クライアント１００からの要求に応じてサービスを提供するコンピュータ装置である。より詳細には、サーバ３００−１〜３００−Ｎは、周知のウェブ・サービス技術を使用して、クライアント１００からのサービス要求に対して、互いに連携してウェブ・サービスを提供する。好適には、サーバ３００−１〜３００−Ｎは、前述の”ＷＳ−Ｆｅｄｅｒａｔｉｏｎ”仕様に従って、互いに信頼関係が確立された連邦化されたコンピューティング環境１０００を形成する。

図２は、本実施の形態におけるサーバ３００の機能ブロック図である。図２の機能ブロック図に示す各要素は、後述する図１１に例示したハードウェア構成を有するコンピュータにおいて、ハードウェア資源とソフトウェアを協働させることで実現することができる。

サーバ３００は、通信制御部３１０、ユーザ認証処理部３２０、アプリケーション実行部３３０を含む。通信制御部３１０は、ネットワーク２００から受けたデータを、ユーザ認証処理部３２０またはアプリケーション実行部３３０へ転送する。通信制御部３１０は、ユーザ認証処理部３２０またはアプリケーション実行部３３０から受けたデータを、ネットワーク２００へ送出することもできる。

ユーザ認証処理部３２０は、通信制御部３１０を通じて受けたクライアント１００のユーザのアクセス要求に応じて認証処理を行う。好適には、アクセス要求は、クライアント１００のウェブ・ブラウザにおいて生成され、ネットワーク２００に送出されサーバ３００に受信されたＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストとして実装されるが、これに限定されない。ユーザ認証処理部３２０は、認証要求処理部３２１、認証情報管理部３２２、ＬＤＡＰクライアント３２３、認証ポリシーテーブル３２４、例外ＩＤテーブル３２５および認証情報ＬＤＡＰ３２６を含む。

認証要求処理部３２１は、クライアント１００のユーザからのアクセス要求を解析し、アクセス要求を送信したユーザが未認証であると判定された場合は、ユーザ認証を実行する。つまり、認証要求処理部３２１は、認証ポリシーテーブル３２４を参照して、連邦化されたコンピューティング環境１０００に含まれる他のサーバの認証システムと連携してユーザ認証を実行する。

より詳細には、認証要求処理部３２１は、アクセス要求を送信したクライアント１００のユーザが未認証であると判定されたことに応じて、認証情報の入力を促すウェブ・ページのデータをクライアント１００に送信する機能を有する。また、認証要求処理部３２１は、認証情報入力用ウェブ・ページ使用して入力されたユーザの認証情報を受け、認証ポリシーテーブル３２４を使用して、当該認証情報が、連邦化されたコンピューティング環境１０００に含まれる複数のサーバのうち、いずれのサーバの認証システムの認証ポリシーに適合するかを特定し、特定されたサーバの認証システムの認証機構において、認証情報を用いてユーザ認証を命令する信号を送信する機能を有する。

さらに、認証要求処理部３２１は、認証情報が自身の認証ポリシーに適合すると判定された場合に、当該認証情報と、ＬＤＡＰクライアント３２３を通じて入手した認証情報ＬＤＡＰ３２６に格納された認証情報の突き合わせを行う認証機構を有する。さらに、認証要求処理部３２１は、ユーザ認証が成功した場合に、クライアント１００に連邦化されたコンピューティング環境１０００へのアクセスを許可するセキュリティ・トークンを送信する機能している。本実施の形態では、好適には、セキュリティ・トークンは、クレデンシャルおよびクッキーである。

認証情報管理部３２２は、連邦化されたコンピューティング環境１０００における認証情報の管理を行う。好適には、認証情報管理部３２２は、連邦化されたコンピューティング環境１０００に含まれるサーバの認証システムの認証ポリシーの認証ポリシーテーブル３２４への登録、更新および参照の処理を行う機能を有する。また、認証情報管理部３２２は、ＬＤＡＰクライアント３２３を通じて、ユーザから受けた認証情報を認証情報ＬＤＡＰへ登録する機能を有する。さらに、認証情報管理部３２２は、新規ユーザのユーザＩＤを登録する際に、同一の認証ポリシーを採用する他のサーバの認証システムに同一のユーザＩＤが既に登録されているかどうかを判定し、同一のユーザＩＤが登録されていると判定された場合に、当該ユーザＩＤを例外ＩＤテーブル３２５に登録する機能を有する。

ＬＤＡＰクライアント３２３は、認証情報ＬＤＡＰ３２６へのインターフェースを提供する。より詳細には、ＬＤＡＰクライアント３２３は、サーバ３００のプログラム・コンポーネントまたは他のコンピュータからの認証情報ＬＤＡＰ３２６へのアクセスを制御する機能を有する。ＬＤＡＰクライアント３２３は、少なくとも、認証情報管理部３２２から受けた認証情報を認証情報ＬＤＡＰ３２６へ登録することができ、また、認証要求処理部３２１等の要求に応じて認証情報ＬＤＡＰ３２６に登録されている認証情報を取り出すことができる。

認証ポリシーテーブル３２４は、連邦化されたコンピューティング環境１０００に含まれる各サーバの認証システムの認証ポリシーを登録するテーブルである。

図９は、本発明の実施形態における認証ポリシーテーブル３２４の一例を示した図である。認証ポリシーテーブル３２４には、連邦化されたコンピューティング環境１０００に含まれるサーバの一部または全部のアドレス・ロケーション（好適には、当該サーバのＵＲＬアドレス）が、認証ポリシーと関連付けられて登録されている。図９に例示する認証ポリシーテーブル３２４では、第一列に認証ポリシーが登録され、第二列に第一列の認証ポリシーを採用するサーバのアドレスが登録されている。

なお、認証ポリシーテーブル３２４には、連邦化されたコンピューティング環境１０００に含まれるすべてのサーバのアドレス・ロケーションおよび認証ポリシーが登録されることが好ましい。しかし、後述するように、本実施形態のユーザ認証は、認証ポリシーテーブル３２４にアドレス・ロケーションおよび認証ポリシーが登録されたサーバのいずれかにおいてユーザ認証が成功したことに応じて連邦化されたコンピューティング環境１０００へのアクセスを許可するものであるので、連邦化されたコンピューティング環境１０００に含まれるサーバのアドレス・ロケーションおよび認証ポリシーが登録されていなくても本実施形態のユーザ認証は動作可能であることに留意されたい。

さらに、本発明の実施形態における認証ポリシーテーブル３２４では、同一の認証ポリシーを採用するサーバが複数存在する場合に、どのサーバの認証システムからユーザ認証の処理を行うかを示すプライオリティがサーバアドレスと関連付けて登録される。プライオリティの値は、システム管理者がマニュアルで入力をしてもよいし、認証システムに登録されているユーザ数の多い順で値を割り振るなど、自動的に決定してもよい。

より具体的には、本発明の実施形態における認証ポリシーテーブル３２４には、ユーザＩＤが「アルファベット３文字＋数字３文字」かつパスワードが「アルファベット４文字」の認証ポリシーを採用する３つのサーバ（アドレスは”server300-1.com”、”server300-2.com”、”server300-3.com”）が登録されている。また、ユーザＩＤが「アルファベット８文字」かつパスワードが「任意」の認証ポリシーを採用する２つのサーバ（アドレスは”server300-4.com”、”server300-5.com”）も登録されている。

さらに、認証ポリシーテーブル３２４には、「指紋認証」かつ指紋認証のバイナリデータのサイズが「100bytes」の認証ポリシーを採用する２つのサーバ（アドレスは”server300-6.com”、”server300-7.com”）および「声紋認証」かつ声紋認証のバイナリデータのサイズが「200bytes」の認証ポリシーを採用する１つのサーバ（アドレスは”server300-8.com”）も登録されている。

例外ＩＤテーブル３２５は、連邦化されたコンピューティング環境１０００に含まれる各サーバの認証システムの間で同一のユーザＩＤを別のユーザが使用している場合に、当該ユーザＩＤを例外ＩＤとして登録するテーブルである。

図１０は、本発明の実施形態における例外ＩＤテーブル３２５の一例を示した図である。例外ＩＤテーブル３２５には、連邦化されたコンピューティング環境１０００に含まれるサーバの一部または全部のアドレス・ロケーション（好適には、当該サーバのＵＲＬアドレス）が、例外ＩＤと関連付けられて登録されている。図１０に例示する例外ＩＤテーブル３２５では、第一列にサーバアドレスが登録され、第二列に第一列のサーバの認証システムの例外ＩＤが登録されている。

アプリケーション実行部３３０は、認証されたユーザのサービス要求を実現するために、クライアント１００および／または連邦化されたコンピューティング環境１０００に含まれるサーバからの要求に応じて、種々のアプリケーション・プログラムを実行する。好適には、アプリケーション実行部３３０によって実行されるアプリケーション・プログラムは、ウェブベースのアプリケーション・プログラムとして実現される。本発明の実施の形態においては、アプリケーションＡ（３３１）、アプリケーションＢ（３３２）、アプリケーションＣ（３３３）およびアプリケーションＤ（３３４）の４種類のアプリケーションを実行することができるようにされている。

図３は、複数のサーバ間の信頼関係を確立する動作フローを示したフローチャートである。本実施の形態においては、複数のサーバ３００−１〜３００−Ｎが互いに信頼関係を確立する場合、まず、サーバ３００−１が、図３に記載した動作フローに従ってまだ信頼関係の確立されていないサーバ３００−２〜３００−Ｎとの信頼関係を確立する。次に、サーバ３００−２が、同様に図４に記載した動作フローに従って、まだ信頼関係の確立されていないサーバ３００−３〜３００−Ｎとの信頼関係を確立する。これをサーバ３００−（Ｎ−１）まで繰り返すことで、複数のサーバ３００−１〜３００−Ｎの互いの信頼関係がすべて確立され、連邦化されたコンピューティング環境１０００が形成される。

以下に、サーバ３００−１がサーバ３００−２〜３００−Ｎとの間で信頼関係を確立する場合を例として、図３に示す動作フローを詳細に説明する。最初に、サーバ３００−１は、自己の認証ポリシーを認証ポリシーテーブル３２４へ登録する（Ｓ３０１０）。次に、周知のＰＫＩ（Ｐｕｂｕｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒａｃｔｕｒｅ）方式に従って電子証明書を交換することで、サーバ３００−１とサーバ３００−２の間の信頼関係を確立する（Ｓ４０２０）。

次に、サーバ３００−１は、Ｓ３０２０において信頼関係を確立した相手方のサーバであるサーバ３００−２の認証ポリシーを入手する。具体的には、サーバ３００−１は、サーバ３００−２にローカルに存在するサーバ３００−２の管理者が作成した認証ポリシーを記述したプロファイル・テーブルにアクセスすることで、サーバ３００−２の認証ポリシーを入手する。そして、入手したサーバ３００−２の認証ポリシーを認証ポリシーテーブル３２４に登録した上で（Ｓ３０３０）、自己の認証ポリシーと相手方サーバ３００−２の認証ポリシーが同一かどうかを判定する（Ｓ３０４０）。サーバ３００−１とサーバ３００−２の認証ポリシーが同一でないと判定された場合は、信頼関係をまだ確立していないサーバが存在するかどうかを判定するためにＮＯの矢印からＳ３０９０へ進む。

Ｓ３０４０においてサーバ３００−１とサーバ３００−２の認証ポリシーが同一と判定された場合は、ＹＥＳの矢印からＳ３０５０へ進み、サーバ３００−１とサーバ３００−２の認証情報ＬＤＡＰ３２６に同一のユーザＩＤが存在するかどうかを調べる。Ｓ３０５０においてサーバ３００−１とサーバ３００−２の認証情報ＬＤＡＰ３２５に同一のユーザＩＤが存在しないと判定された場合は、信頼関係をまだ確立していないサーバが存在するかどうかを判定するためにＮＯの矢印からＳ３０９０へ進む。

Ｓ３０５０においてサーバ３００−１とサーバ３００−２の認証情報ＬＤＡＰに同一のユーザＩＤが存在すると判定された場合は、ＹＥＳの矢印からステップ３０６０へ進み、図６に示す例外ＩＤ登録確認画面を、サーバ間の信頼関係を確立しようとしているシステム管理者の操作する端末へ表示する。本実施の形態では、サーバ３００−１とサーバ３００−２の双方に、“ＡＢＣ００１”というユーザＩＤが登録されていたとして、システム管理者に当該ユーザＩＤが同一のユーザが使用するものかどうかについて確認を促している。なお、例外ＩＤ登録確認画面には、システム管理者に確認のヒントを提示するために、サーバ名、ユーザＩＤと関連付けて登録名（サーバ３００−１のユーザＩＤ“ＡＢＣ００１”に対する登録名として“Ｔａｎａｋａ Ｔａｒｏ”、サーバ３００−２のユーザＩＤ“ＡＢＣ００１”に対する登録名として“Ｈｉｒｏｔａ Ｋｅｉｓｕｋｅ”）が表示される。

次に、Ｓ３０７０に進み、システム管理者が、例外ＩＤ確認画面に表示されたユーザＩＤが、サーバ３００−１とサーバ３００−２で異なるユーザが使用していると判断した場合、システム管理者は、例外ＩＤ確認画面で“登録する”ボタンを押すことになる。“登録する”ボタンが押されたことに応じてフローはＳ３０８０に進み、当該ユーザＩＤは、例外ＩＤテーブル３２５に登録される。その後、信頼関係をまだ確立していないサーバが存在するかどうかを判定するためにＮＯの矢印からＳ３０９０へ進む。

Ｓ３０７０において、システム管理者が、例外ＩＤ確認画面に表示されたユーザＩＤが、サーバ３００−１とサーバ３００−２で同一のユーザが使用していると判断した場合、ユーザは例外ＩＤ確認画面で“登録しない”ボタンを押すことになる。“登録しない”ボタンが押されたことに応じて、フローは、信頼関係をまだ確立していないサーバが存在するかどうかを判定するためにＮＯの矢印からＳ３０９０へ進む。

Ｓ３０９０では、サーバ３００−１がまだ信頼関係を確立していないサーバがあるかどうかが判定される。Ｓ３０９０でまだ信頼関係を確立していないサーバがあると判定された場合は、フローはＳ３０３０へ戻り、まだ信頼関係を確立していないサーバとＳ３０３０〜Ｓ３０８０のステップを実行することでサーバ３００−１は、すべての他のサーバ３００−２〜３００−Ｎと信頼関係を確立することとなる。Ｓ３０９０でまだ信頼関係を確立していないサーバがもう存在しないと判定された場合は、ＹＥＳの矢印に進み、フローは終了する。

上記は、サーバ３００−１が、他のサーバ３００−２〜３００−Ｎと信頼関係を確立することについて説明した。同様の処理を３００−２〜３００−Ｎについても実行することで、サーバ３００−１〜３００−Ｎの間で互いに信頼関係を確立した連邦化されたコンピューティング環境１０００が形成される。

図４は、新規ユーザ認証情報の登録の動作フローを示したフローチャートである。以下に、既に複数のサーバ３００−１〜３００−Ｎで互いに信頼関係が確立された連邦化されたコンピューティング環境１０００に参加するサーバ３００−１の認証システムにおいて、新規ユーザ認証情報を登録する流れを、図４を参照して詳細に説明する。なお、他のサーバ３００−２〜３００−Ｎの認証システムにおいて新規ユーザ認証情報を登録する流れも同様の処理で実現可能であることに留意されたい。

まず、ユーザの操作するクライアント１００から新規認証情報を受け付ける（Ｓ４０１０）。なお、Ｓ４０１０では、サーバ３００−１は、サーバ３００−１の管理者が作成した認証ポリシーを記述したプロファイル・テーブルを使用して、新規認証情報が自己の認証ポリシーに適合しているかどうかの検証も行っている。次に、自己の認証情報ＬＤＡＰ３２６に、クライアント１００から受けた認証情報に含まれるユーザＩＤと同一のユーザＩＤが存在するかどうかを判定する（Ｓ４０２０）。Ｓ４０２０で同一のユーザＩＤが存在すると判定された場合は、同一のサーバの認証システムでは同一のユーザＩＤが存在をすることは許されないので、別の認証情報をユーザから受け付けるためにＹＥＳの矢印からＳ４０１０へ戻り、再度新規ユーザ認証情報を受け付ける。Ｓ４０２０で同一のユーザＩＤが存在しないと判定された場合は、ＮＯの矢印からＳ４０３０へ進む。

Ｓ４０３０では、サーバ３００−１は、自己の記憶装置に記憶されている認証ポリシーテーブルを用いて、連邦化されたコンピューティング環境１０００に存在する自己と同一の認証ポリシーを採用する認証システムを持つサーバを特定する。次に、Ｓ４０３０で自己と同一の認証ポリシーを採用する認証システムを持つサーバとして特定されたサーバのうちの一つの認証情報ＬＤＡＰ３２６に新規ユーザ認証情報に含まれるユーザＩＤと同一のユーザＩＤが存在するかどうかを判定する（Ｓ４０４０）。

Ｓ４０４０において、Ｓ４０３０で特定されたサーバのうちの一つの認証情報ＬＤＡＰ３２６に同一のユーザＩＤが存在しないと判定された場合は、他にＳ４０３０で特定された３００−１と同一の認証ポリシーを採用するサーバが存在するかどうかを判定するためにＮＯの矢印からＳ４０８０へ進む。

Ｓ４０４０において、Ｓ４０３０で特定されたサーバのうちの一つの認証情報ＬＤＡＰ３２６に同一のユーザＩＤが存在すると判定された場合は、ＹＥＳの矢印からＳ４０５０へ進み、図６に示す例外ＩＤ登録確認画面を、認証情報を登録しようとしているユーザが操作するクライアントへ表示する。例外ＩＤ登録確認画面については、図３の説明において既にしたので、ここでは詳細には説明しない。

次に、Ｓ４０６０に進み、認証情報を登録しようとするユーザが、例外ＩＤ確認画面に表示されたユーザＩＤを自分が使用しているものではないと判断した場合、ユーザは例外ＩＤ確認画面で“登録する”ボタンを押すことになる。“登録する”ボタンが押されたことに応じてフローはＳ４０７０に進み、当該ユーザＩＤは、例外ＩＤテーブル３２５に登録される。その後、他にＳ４０３０で特定された３００−１と同一の認証ポリシーを採用するサーバが存在するかどうかを判定するためにＮＯの矢印からＳ４０８０へ進む。

なお、Ｓ４０６０において、認証情報を登録しようとするユーザが、例外ＩＤ確認画面に表示されたユーザＩＤを自分が使用しているものであると判断した場合、ユーザは例外ＩＤ確認画面で“登録しない”ボタンを押すことになる。“登録しない”ボタンが押されたことに応じて、他にＳ４０３０で特定された３００−１と同一の認証ポリシーを採用するサーバが存在するかどうかを判定するためにＹＥＳの矢印からＳ４０８０へ進む。

Ｓ４０８０では、Ｓ４０３０で特定されたサーバ３００−１と同一の認証ポリシーを採用するサーバがまだ残っているかが判定される。Ｓ４０８０でまだ同一の認証ポリシーを採用するサーバが残っていると判定された場合は、フローはＳ４０４０へ戻り、残っているサーバとＳ４０４０〜Ｓ４０７０のステップを実行することで、サーバ３００−１は、必要な情報を例外ＩＤテーブルに登録する。Ｓ４０８０でまだ同一の認証ポリシーを採用するサーバが残っていないと判定された場合は、ＮＯの矢印からＳ４０９０へ進み、サーバ３００−１は、新規ユーザ認証情報を自己の認証情報ＬＤＡＰ３２６に登録する。

図５は、本発明の実施形態におけるユーザ認証の流れを示したフローチャートである。以下、未認証のユーザの操作するクライアント１００から連邦化されたコンピュータ環境１０００に含まれる複数のサーバの一つであるサーバ３００−１に対してアクセス要求があった場合のユーザ認証の流れを図５のフローチャートに従って詳細に説明する。なお、他のサーバ３００−２〜３００−Ｎの認証システムにおいてユーザ認証を行う場合も同様の処理で実現可能であることに留意されたい。

サーバ３００−１は、ユーザからアクセス要求を受ける（Ｓ５０１０）。そして、アクセス要求にセキュリティ・トークンが含まれるかどうかを調査することによって当該アクセス要求を発したユーザが未認証であると判定したサーバ３００−１は、ユーザの操作するクライアントに、図７に示す認証モード選択画面のデータを送信することで、ユーザに認証モードの選択を促す（Ｓ５０２０）。ユーザが、図７に例示する認証モード選択画面に“はい”のボタンを押し、マルチ認証モードを選択した場合は、処理はＳ５０４０へ進む。なお、ユーザが図７に例示する認証モード選択画面に“いいえ”のボタンを押し、通常認証モードが選択した場合は、処理はＳ５０３０へ進み、認証ポリシーテーブルを使わない通常認証でユーザ認証が行われる。通常認証は、周知であるのでここでは詳細には説明されない。

次に、サーバ３００−１は、図８に示すマルチ認証モードで用いられる認証画面のデータをユーザのクライアントに送信する（Ｓ５０４０）。認証画面のデータを受けたユーザは、認証情報を入力する（Ｓ５０５０）。クライアントは、入力された認証情報をサーバ３００−１へ送信する。

より詳細には、ユーザＩＤを使用してユーザ認証を行う場合は、ユーザは、図８に示す認証情報入力画面の第一行にキーボードを操作することでユーザＩＤを入力する。ユーザＩＤを使用せずにユーザ認証を行う場合は、ユーザは、第一行の“使用しない”のチェックボックスをチェックする。また、パスワードを使用してユーザ認証を行う場合は、ユーザは、図８に示す認証画面の第二行にキーボードを操作することでパスワードを入力する。パスワードを使用せずにユーザ認証を行う場合は、ユーザは、第二行の“使用しない”のチェックボックスをチェックする。指紋認証、声紋認証などテキストデータ以外（すなわち、バイナリデータ）を使用してユーザ認証を行う場合は、ユーザは、図８に示す認証画面の第三行の“使用しない”のチェックボックスをチェックせずに“ＯＫ”ボタンを押し、続けてバイナリデータの入力（例えば、指紋認証に対して指紋データ入力パッドに指を置く、声紋認証に対してはマイクに向かって発声するなど）を行う。パスワードを使用せずにユーザ認証を行う場合は、ユーザは、第二行の“使用しない”のチェックボックスをチェックする。

処理はＳ５０５０に進み、サーバ３００−１は、自己の認証ポリシーテーブルを参照し、ユーザが入力した認証情報と適合する認証ポリシーを採用する１以上のサーバのアドレスを取得する（Ｓ５０６０）。例えば、サーバ３００−１が図９の認証ポリシーテーブルを使用し、認証情報にユーザＩＤが“ＸＹＺ００１”、パスワードが“ＷＸＹＺ”が含まれる場合は、ユーザＩＤが「アルファベット３文字＋数字３文字」かつパスワードが「アルファベット４文字」の認証ポリシーに適合するので、サーバ３００−１は、３つのアドレス”server300-1.com”、”server300-2.com”、”server300-3.com”を取得する。

次に、サーバ３００−１は、ユーザからの認証情報に含まれるユーザＩＤが例外ＩＤテーブルに登録されているかどうかを、Ｓ５０６０で取得されたアドレスの示すサーバに対して問合せを行うことで判定する（Ｓ５０７０）。認証情報に含まれるユーザＩＤが例外ＩＤテーブルに登録されていると判定された場合は、ＹＥＳの矢印からＳ５０８０へ進み例外処理が行われる。例外ＩＤテーブルに登録されているユーザＩＤは、いずれの認証システムにおいてユーザ認証すべきかを判別することができないので、例外処理では、サーバ３００−１は、ユーザのクライアントに「このユーザＩＤは例外ＩＤですので、マルチ認証モードを使用することはできません。通常認証にてユーザ認証を行ってください。」というメッセージを返し、処理を終了する。

Ｓ５０７０において、ユーザからの認証情報に含まれるユーザＩＤがいずれかのサーバの例外ＩＤテーブルにも登録されてないと判定された場合は、ＮＯの矢印からＳ５０９０へ進む。Ｓ５０９０では、サーバ３００−１は、Ｓ５０６０において取得したアドレスを使用して、認証ポリシーの合致するサーバに認証情報を送信し、認証情報を受信したサーバの認証機構を使用してユーザ認証を行う。好適には、サーバ３００−１は、いずれのサーバからユーザ認証を行うかを、認証ポリシーテーブル中のプライオリティの値に従って決定する。例えば、サーバ３００−１が図９の認証ポリシーテーブルを使用し、Ｓ５０７０においてサーバ３００−１が３つのアドレス”server300-1.com”、”server300-2.com”、”server300-3.com”を取得した場合は、プライオリティの値が最も高い”server300-1.com”の認証システムがユーザ認証を最初に試みることとなる。

処理はＳ５１００へ進み、ユーザ認証が成功したと判定された場合は、ユーザ認証を行ったサーバは、アイデンティティ情報を取得し（Ｓ５１１０）、取得したアイデンティティ情報を使用して、クレデンシャルおよびクッキーを作成し、ユーザに返信する（Ｓ５１２０）。なお、クレデンシャルおよびクッキーの作成およびユーザへの返信は、ユーザ認証を行ったサーバからユーザ認証が成功した旨の通知を受けたサーバ３００−１が行ってもよい。そして、ユーザは受信したクレデンシャルおよびクッキーを使用して、連邦化されたコンピューティング環境１０００にアクセスをすることが許可され、認証処理は終了する。

なお、本発明の実施形態では、ユーザに連邦化されたコンピューティング環境へのアクセスを許可するために、クレデンシャルおよびクッキーを使用する態様によって説明をした。しかし、クレデンシャルおよびクッキーの代替としてＵＲＬエンコーディング、ＳＡＭＬトークンのような他のいかなる公知の認証技術も使用可能であることは当業者には自明である。

Ｓ５１００でユーザ認証が失敗したと判定された場合は、Ｓ５０６０で特定されたユーザの認証情報に認証ポリシーが適合するサーバが残っているかどうかが判定される（Ｓ６１３０）。Ｓ５１３０において、まだＳ５０６０で特定されたユーザの認証情報に認証ポリシーに適合するサーバが残っていると判定された場合は、フローはＳ５０９０へ戻り、他の残っているサーバに対してＳ５０９０以降の処理を行うことで、再びユーザ認証を試みることとなる。前述のサーバ３００−１が図９の認証ポリシーテーブルを使用し、Ｓ５０７０においてサーバ３００−１が３つのアドレス”server300-1.com”、”server300-2.com”、”server300-3.com”を取得した場合は、既に”server300-1.com”の認証システムによる認証は失敗したので、サーバ３００−１は、プライオリティの値が次に高い”server300-2.com”の認証システムがユーザ認証を最初に試み、それも失敗した場合は、”server300-3.com”の認証システムがユーザ認証を試みることとなる。

Ｓ５１３０で特定されたユーザの認証情報に認証ポリシーに適合するサーバが残っていない、すなわちすべてのサーバにおいて認証が失敗したと判定された場合は、フローはＳ５１４０へ進み、認証失敗としてユーザは連邦化されたコンピューティング環境１０００へのアクセスを許可されないこととなり、認証処理は終了する。

図１１は、本発明の実施の形態において使用されるサーバ３００を実現するために好適なコンピュータ装置のハードウェア構成を例示する図である。サーバ３００は、中央処理装置（ＣＰＵ）１とメインメモリ４を含んでいる。ＣＰＵ１とメインメモリ４は、バス２を介して、補助記憶装置としてのハードディスク装置１３と接続されている。また、フレキシブルディスク装置２０、ＭＯ装置２８、ＣＲ−ＲＯＭ装置２６、２９などのリムーバブルストレージ（記録メディアを交換可能な外部記憶システム）が関連するフレキシブルディスク・コントローラ１９、ＩＤＥコントローラ２５、ＳＣＳＩコントローラ２７などを介してバス２へ接続されている。

フレキシブルディスク装置２０、ＭＯ装置２８、ＣＲ−ＲＯＭ装置２６、２９などのリムーバブルストレージには、それぞれフレキシブルディスク、ＭＯ、ＣＤ−ＲＯＭなどの記憶媒体が挿入され、このフレキシブルディスク等やハードディスク装置１３、ＲＯＭ１４には、オペレーティング・システムと協働してＣＰＵ等に命令を与え、本発明を実施するためのコンピュータ・プログラムのコードを記録することができる。メインメモリ４にロードされることによってコンピュータ・プログラムは実行される。コンピュータ・プログラムは圧縮し、また複数に分割して複数の媒体に記録することもできる。

サーバ３００は、さらに、ユーザ・インターフェイス・ハードウェアとして、マウス等のポインティング・デバイス７、キーボード６や視覚データをユーザに提示するためのディスプレイ１２を有することができる。また、パラレルポート１６を介してプリンタ（図示せず）と接続することや、シリアルポート１５を介してモデム（図示せず）を接続することが可能である。サーバ３００は、シリアルポート１５及びモデムを介し、また、通信アダプタ１８（イーサネット（Ｒ）・カードやトークンリング・カード）等を介してネットワークに接続し、他のコンピュータ等と通信を行うことが可能である。

スピーカ２３は、オーディオ・コントローラ２１によってＤ／Ａ変換（デジタル／アナログ変換）された音声信号をアンプ２２を介して受け取り、音声として出力する。また、オーディオ・コントローラ２１は、マイクロフォン２４から受け取った音声情報をＡ／Ｄ変換（アナログ／デジタル変換）し、システム外部の音声情報をシステムに取り込むことを可能にしている。

以上の説明により、本発明の実施の形態におけるサーバ３００は、メインフレーム、ワークステーション、通常のパーソナルコンピュータ（ＰＣ）等の情報処理装置、または、これらの組み合わせによって実現されることが容易に理解されるであろう。ただし、これらの構成要素は例示であり、そのすべての構成要素が本発明の必須構成要素となるわけではない。

特に、ここで説明したハードウェア構成のうち、フレキシブルディスク装置２０、ＭＯ装置２８、ＣＲ−ＲＯＭ装置２６、２９などのリムーバブルストレージ、パラレルポート１６、プリンタ、シリアルポート１５、モデム、通信アダプタ１８、スピーカ２３、オーディオ・コントローラ２１、アンプ２２、マイクロフォン２４などはなくても、本発明の実施の形態は実現可能であるので、本発明の実施の形態におけるサーバ３００に含めなくともよい。

本発明の実施に使用されるサーバ３００の各ハードウェア構成要素を、複数のマシンを組み合わせ、それらに機能を配分し実施する等の種々の変更は当業者によって容易に想定され得るものであり、それらの変更は、当然に本発明の思想に包含される概念である。

サーバ３００は、オペレーティング・システムとして、マイクロソフト・コーポレーションが提供するＷｉｎｄｏｗｓ（Ｒ）オペレーティング・システム、インターナショナル・ビジネス・マシーンズ・コーポレーションが提供するＡＩＸ、アップル・コンピュータ・インコーポレイテッドが提供するＭａｃＯＳ、あるいはＬｉｎｕｘなどのＧＵＩマルチウィンドウ環境をサポートするものを採用することができる。

サーバ３００は、オペレーティング・システムとして、インターナショナル・ビジネス・マシーンズ・コーポレーションが提供するＰＣ−ＤＯＳ、マイクロソフト・コーポレーションが提供するＭＳ−ＤＯＳなどのキャラクタ・ベース環境のもの採用することもできる。さらに、サーバ３００は、インターナショナル・ビジネス・マシーンズ・コーポレーションが提供するＯＳ／Ｏｐｅｎ、Ｗｉｎｄ Ｒｉｖｅｒ Ｓｙｓｔｅｍｓ，Ｉｎｃ．のＶｘ ＷｏｒｋｓなどのリアルタイムＯＳ、Ｊａｖａ（Ｒ）ＯＳなどのネットワーク・コンピュータに組み込みオペレーティング・システムを採用することもできる。

以上から、サーバ３００は、特定のオペレーティング・システム環境に限定されるものではないことを理解することができる。サーバ３００−１〜３００−Ｎはそれぞれ異なるオペレーティング・システム環境で動作するようにしてもよいことは勿論である。

以上、本実施の形態によれば、ユーザは、連邦化されたコンピューティング環境１０００のいずれかのサーバの認証システムに対するいずれかの認証情報を入力することで、サーバの認証システムと認証情報の対応を記憶することなく、また、いま自分がどの認証システムにおいて認証を試みているかを正確に意識することなくユーザ認証を受けることが可能となる。

また、本実施の形態では、ユーザから受けた認証情報に適合する認証ポリシーを採用するサーバの認証システムにおいてのみユーザ認証を行うので、高速なユーザ認証が実現される。

以上、本発明によれば、連邦化されたコンピューティング環境において、より利便性の高いユーザ認証を実現できることが容易に理解できる。

以上、本発明の実施の形態を用いて説明したが、本発明の技術範囲は上記実施の形態に記載の範囲には限定されない。上記の実施の形態に、種々の変更または改良を加えることが可能であることが当業者に明らかである。従って、そのような変更または改良を加えた形態も当然に本発明の技術的範囲に含まれる。

本発明の実施の形態の連邦化されたコンピューティング環境１００のシステム構成の一例を示した概念図である。 本発明の実施形態におけるサーバ３００の機能ブロック図である。 本発明の実施形態におけるサーバ間の信頼関係を確立する動作フローを示したフローチャートである。 本発明の実施形態における新規ユーザ認証情報の登録の動作フローを示したフローチャートである。 本発明の実施形態におけるユーザ認証の動作フローを示したフローチャートである。 本発明の実施形態における例外ＩＤ登録確認画面のイメージを示した図である。 本発明の実施形態における認証モード選択画面のイメージを示した図である。 本発明の実施形態における認証情報入力画面のイメージを示した図である。 本発明の実施形態における認証ポリシーテーブル３２４の一例を示した概念図である。 本発明の実施形態における例外ＩＤテーブル３２５の一例を示した概念図である。 本発明の実施形態におけるサーバ３００として機能するコンピュータのハードウェア構成の一例を示した図である。

Claims (14)

1. 互いにシステム的に信頼関係が確立された複数のサーバを含むコンピューティング環境に対するユーザ認証を行うためのシステムであって、
   前記複数のサーバのうちの少なくとも１つのユーザ認証の形式の情報を表す認証ポリシーを登録した認証ポリシーテーブルと、
   ユーザから認証情報を受ける手段と、
   前記認証ポリシーテーブルを用いて、前記複数のサーバから前記認証情報と適合する認証ポリシーを採用するサーバを少なくとも１つ特定する手段と、
   前記サーバを特定する手段によって特定されたサーバの認証機構に、前記認証情報を用いてユーザ認証を行うように命令する信号を送信する手段と、
   前記複数のサーバのうちの少なくとも１つの認証ポリシーを、各認証ポリシーを採用するサーバの識別子と関連付けて前記認証ポリシーテーブルに登録する手段と、
   を備える、システム。
2. 前記認証ポリシーは、文字列のユーザＩＤによる認証、クライアント証明書による認証、生体認証、手書き認証のうちの少なくとも一つである、請求項１に記載のシステム。
3. 前記コンピューティング環境へのアクセスを行うためのトークンを生成する手段を含む、請求項１に記載のシステム。
4. 前記トークンは、クッキー、ＵＲＬエンコーディングによる認証情報、ＳＡＭＬトークンのいずれかである、請求項３に記載のシステム。
5. 互いにシステム的に信頼関係が確立された複数のサーバを含むコンピューティング環境における方法であって、コンピュータに以下のステップを実行させることを含み、該ステップが、
   前記複数のサーバのうちの少なくとも１つのユーザ認証の形式の情報を表す認証ポリシーを登録した認証ポリシーテーブルを少なくとも１つ保持し、
   ユーザから認証情報を受けるステップと、
   前記認証ポリシーテーブルを用いて、前記複数のサーバから前記認証情報と適合する認証ポリシーを採用するサーバを少なくとも１つ特定するステップと、
   前記サーバを特定するステップにおいて特定されたサーバの認証機構に、前記認証情報を用いてユーザ認証を行うように命令する信号を送信するステップと、
   複数のサーバのうちの少なくとも１つの認証ポリシーを、各認証ポリシーを採用するサーバの識別子と関連付けて前記認証ポリシーテーブルに登録するステップと、
   を含む、方法。
6. 前記認証ポリシーは、文字列のユーザＩＤによる認証、クライアント証明書による認証、生体認証、手書き認証のうちの少なくとも一つである、請求項５に記載の方法。
7. 前記コンピュータに以下のステップをさらに実行させることを含み、該ステップが、前記コンピューティング環境へのアクセスを行うためのトークンを生成するステップを含む、請求項５に記載の方法。
8. 前記トークンは、クッキー、ＵＲＬエンコーディングによる認証情報、ＳＡＭＬトークンのいずれかである、請求項７に記載の方法。
9. 前記コンピュータに以下のステップをさらに実行させることを含み、該ステップが、
   （Ａ）前記認証ポリシーテーブル登録されている同一の認証ポリシーを採用する２以上のサーバのそれぞれに対してプライオリティを付与するステップと、
   （Ｂ）前記ユーザの認証情報が前記２以上のサーバの採用する認証ポリシーに適合したことに応じて、前記２以上のサーバのうちの前記プライオリティの最も高いサーバの認証機構に、前記認証情報を用いてユーザ認証を行うように命令するステップと、
   （Ｃ）前記ユーザ認証が失敗したことに応じて、前記２以上のサーバのうち次にプライオリティの高いサーバの認証機構に、ユーザ認証を行うように命令するステップと、
   （Ｄ）前記２以上のサーバのいずれかのサーバにおいてユーザ認証が成功するか、前記２以上のサーバすべてにおいてユーザ認証が失敗するまで、前記ステップ（Ｃ）を繰り返すステップと、
   （Ｅ）前記ユーザ認証が成功したことを条件として、前記ユーザの前記コンピューティング環境へのアクセスを許可するステップと、
   を含む請求項５に記載の方法。
10. 互いにシステム的に信頼関係が確立された複数のサーバを含むコンピューティング環境におけるプログラムであって、
    前記複数のサーバの少なくとも１つのユーザ認証の形式の情報を表す認証ポリシーを登録した認証ポリシーテーブルを少なくとも１つ保持し、
    前記認証プログラムは、
    ユーザから認証情報を受けるステップと、
    前記認証ポリシーテーブルを用いて、前記複数のサーバから前記認証情報と適合する認証ポリシーを採用するサーバを少なくとも１つ特定するステップと、
    前記サーバを特定するステップにおいて特定されたサーバの認証機構に、前記認証情報を用いてユーザ認証を行うように命令する信号を送信するステップと、
    前記複数のサーバのうちの１つの認証ポリシーを、各認証ポリシーを採用するサーバの識別子と関連付けて前記認証ポリシーテーブルに登録するステップと、
    をコンピュータに実行させる、プログラム。
11. 前記認証ポリシーは、文字列のユーザＩＤによる認証、クライアント証明書による認証、生体認証、手書き認証のうちの少なくとも一つである、請求項１０に記載のプログラム。
12. 前記コンピューティング環境へのアクセスを行うためのトークンを生成するステップをさらにコンピュータに実行させる、請求項１０に記載のプログラム。
13. 前記トークンは、クッキー、ＵＲＬエンコーディングによる認証情報、ＳＡＭＬトークンのいずれかである、請求項１２に記載のプログラム。
14. 請求項１０ないし１３のいずれかのプログラムを記録したコンピュータ可読の記憶媒体。

Images