JP2004005647A - アクセス制御を提供する方法、記録媒体及びアクセスを制御するシステム - Google Patents

Abstract

【課題】信頼される外部リソースによって認証されたユーザが、固有でローカルなユーザアカウントも有することを要せずに選択されたオブジェクトに制御されたレベルのアクセスを得ることを可能にし、認証のクレデンシャルの制約された委任を提供する。
【解決手段】動作５５５でＵ２がサーバＹ５０４にログオンしＰＵＩＤ５２４を受け取る。動作５５６でＵ２がサーバＸ５０２に接続しＰＵＩＤ５２４を含む情報を提供する。動作５５７でサーバＸ５０２がＰＵＩＤを認識し対応するＳＩＤ５３２を構築し、Ｕ２に関連するトークン５３０の中に入れる。動作５５８でサーバＸ５０２がトークン５３０とＡＣＬ５１８とのＳＩＤを比較し、Ｕ２がオブジェクト５１６にアクセスするアクセス許可を有するか判定する。ＳＩＤが一致すると、動作５５９で認証コンテキスト５２６が作成されＵ２がオブジェクト５１６にアクセス可能になる。
【選択図】　　　　図５

Description

【０００１】
【発明の属する技術分野】
本発明は、一般にコンピュータアクセス制御に関連した、アクセス制御を提供する方法、記録媒体及びアクセスを制御するシステムに関する。
【０００２】
より詳細には、ユーザの外部認証に基づいてユーザに関するローカルシステムの許可（ａｕｔｈｏｒｉｚａｔｉｏｎ）コンテキストを提供するため、さらには、認証のクレデンシャル（ｃｒｅｄｅｎｔｉａｌ；信任状）の委任（ｄｅｌｅｇａｔｉｏｎ）の範囲を制御するための、アクセス制御を提供する方法、アクセス制御許可を確立する方法、記録媒体、ペアワイズ固有識別子（ＰＵＩＤ）を対応するセキュリティ識別子（ＳＩＤ）に変換する方法、アクセスを制御するシステム及びアクセス制御許可を設定するシステムに関する。
【０００３】
【従来の技術】
アクセス制御は、コンピュータセキュリティに最も重要である。コンピュータシステムの完全性、および重要なデータの機密性を保護するため、許可のないユーザおよび悪意のある攻撃者がコンピュータリソースへのアクセスを得ることを防止する様々なアクセス制御スキームが実施されてきた。
【０００４】
コンピュータセキュリティの包括性を確実にするため、アクセス制御は、しばしば、様々なレベルで実施される。例えば、１つのコンピュータのレベルで、ユーザは、通常、コンピュータが、ユーザがそのコンピュータを使用するのを許可されているかどうかを判定するログオン手続きを経ることを要求される。さらに、コンピュータネットワークのレベルで、ユーザは、様々なネットワークサービスに対するユーザのアクセスを制御する目的で、ユーザ認証プロセスを経ることを一般に要求される。ネットワークアクセス制御サーバがユーザを認証した後でさえ、ユーザは、サービスにアクセスするために特定のサーバに関する許可を要求しなければならない可能性がある。ケルベロス（Ｋｅｒｂｅｒｏｓ）５プロトコルなどの様々なプロトコルに基づく様々なスキームが、ユーザ認証を使用してネットワークアクセス制御を管理するために提案され、実施されてきた。
【０００５】
一般に、コンピュータに関するユーザログオンとネットワークアクセス制御に関するユーザ認証は、２つの別個の手続きである。ただし、様々なアクセス制御スキームを扱う際のユーザにかかる負担を最小限に抑えるため、ユーザログオンとネットワークアクセスに関するユーザ認証は、ときとして、一緒に行われる。例えば、ユーザ認証がケルベロスプロトコルの下で実施されるケースでは、ユーザがコンピュータにログオンしたとき、コンピュータが、ケルベロス認証プロセスも開始することが可能である。ケルベロス認証プロセスでは、コンピュータが、ＫＤＣ（Ｋｅｒｂｅｒｏｓ　Ｋｅｙ　Ｄｉｓｔｒｉｂｕｔｉｏｎ　Ｃｅｎｔｅｒ）にコンタクトして、ユーザのためにＴＧＴ（ｔｉｃｋｅｔ−ｇｒａｎｔｉｎｇ　ｔｉｃｋｅｔ）を最初に獲得する。次に、コンピュータは、ＴＧＴを使用してＫＤＣから、そのコンピュータ自らのためのセッションチケットを獲得することができる。
【０００６】
ネットワークが進化するにつれ、複数の層のサーバ／サービスコンピュータを配置してクライアントコンピュータの要求を扱うようにする傾向がある。簡単な例は、インターネットを介してＷｏｒｌｄ　Ｗｉｄｅ　ＷｅｂのＷｅｂサイトに要求を行うクライアントコンピュータである。この場合、要求のフォーマッティングおよび関連するビジネス規則を扱うフロントエンドＷｅｂサーバと、Ｗｅｂサイトに関するデータベースを管理するバックエンドサーバが存在する可能性がある。さらなるセキュリティのため、Ｗｅｂサイトは、認証プロトコルが、例えば、ユーザのＴＧＴ、および／または、場合により、フロントエンドサーバからの他の情報などのクレデンシャルをバックエンドサーバに転送する（または委任する）ように構成されることが可能である。この慣行は、多くのＷｅｂサイト、および／または他の多層構成ネットワークにおいてますます一般的になっている。
【０００７】
したがって、ユーザのＴＧＴおよび関連する認証符号を所有するあらゆるサーバ／コンピュータが、ユーザ／クライアントに代行してＫＤＣにチケットを要求することができる。この能力は、現在、先進のチケット委任を提供するのに使用されている。残念ながら、サーバへのそのような委任は、基本的にＴＧＴの存命期間にわたって制約を受けない。したがって、複雑なネットワーク構成において認証のクレデンシャルの委任をサポートするが、より制約された形でサポートする改良された方法およびシステムの必要性が存在する。
【０００８】
委任、およびその他の同様の技術は、サーバ／サービスのすべてとクライアントが、同一の認証プロセスを使用することに合意したとき、有用である。ただし、今日、ただ１つの認証プロセスだけが使用されているわけではない。米国特許出願第０９／８８６，１４６号は、委任を制御することに関する改良を提示している。
【０００９】
ユーザが、ネットワーク／システムに対して認証された場合、通常、ユーザがアクセスすることがそのユーザに許可されていないリソースにアクセスするのを防止する、１つまたは複数のさらなる許可アクセス制御チェックが存在する。ユーザは、認証され、該当するアクセス制御チェックにパスすると、「許可された」ものとされる。あるシステムでは、例えば、アクセス制御は、様々なサービスおよびリソース（例えば、オブジェクト）に関するアクセス制御リスト（ＡＣＬ）を有することに基づく。ＡＣＬは、通常、ゼロまたは１つ以上のセキュリティ識別子（ＳＩＤ）が含まれるアクセス制御エントリ（ＡＣＥ）を含む。ＳＩＤは、オブジェクトにアクセスすることが許可された１名のユーザ、またはグループのユーザに関連している。ＡＣＬの中にＳＩＤが存在しない場合は、そのオブジェクトにアクセスするユーザは存在しない。ＡＣＬの中にＳＩＤが存在する場合は、少なくとも１つの合致するＳＩＤを提示することができるユーザが、オブジェクトにアクセスすることが許される。
【００１０】
したがって、認証されたユーザがログオンしたとき、例えば、そのユーザに関連するトークン（例えば、アクセストークン）を生成することにより、そのユーザのための認証コンテキストが生成される。トークンは、通常、ユーザに関連するＳＩＤを含む。例えば、ユーザのトークンは、そのユーザに割り当てられた固有ＳＩＤに加え、そのユーザのビジネス部門に割り当てられたグループＳＩＤを含むことが可能である。ユーザが、あるオブジェクトにアクセスしようと試みるとき、そのオブジェクトのＡＣＬが、そのユーザのトークンと比較される。ユーザのトークンが、オブジェクトのＡＣＬ内のＳＩＤに合致する少なくとも１つのＳＩＤを含む場合、その認証されたユーザは、何らかの形でそのオブジェクトにアクセスすることが許可される。例えば、ユーザは、ユーザ自身のビジネス部門の他のメンバ（すなわち、別のグループメンバ）によって生成されたファイルに関して読取り許可および書込み許可を有することが可能である。
【００１１】
そのような認証スキームは、注意深く制御され、管理されているシステムに関してうまく機能する傾向がある。例えば、企業内の企業レベルのコンピュータネットワークは、通常、ユーザおよびＡＣＬが、集中型の認証−アクセス制御システムおよび／または分散型の認証−アクセス制御システムによって注意深く制御されることが可能な統一性のある（ｃｏｈｅｓｉｖｅ）環境を提供する。他方、非常に大型のネットワーク、例えば、インターネットの場合、および／またはそれ以外の形で相当に統一性の低いネットワークの場合、認証、およびアクセス制御は、特に、ローカルアクセス制御アカウントを有さないユーザも含め、ユーザのできる限り多くにサービスを提供することが所望されるとき、はるかに困難である可能性がある。ソフトウェアプログラムおよびリソースが、ネットワークベースのサービスの方に移行するにつれ、そのようなネットワークサービスに関連するユーザ活動を許可することができる必要性は、さらに高まる。
【００１２】
したがって、改良された認証の方法およびシステムに対する必要性が存在する。好ましくは、この方法およびシステムは、信頼される外部リソースによって認証されたユーザが、オブジェクトに関連する固有ユーザアカウントも有することを要さずに、あるオブジェクトに対して何らかの制御されたレベルのアクセスを得ることを可能にしたい。さらに、この方法およびシステムは、非常に多数のユーザにオブジェクトに対するアクセスを提供することができる構成の拡張容易性を大きく低下してはならない。
【００１３】
尚、出願人が知っている先行技術として、記載すべき先行技術文献情報は特に見あたらない。
【００１４】
【発明が解決しようとする課題】
従来のシステムには上述したような種々の問題があり、さらなる改善が望まれている。
【００１５】
本発明は、このような状況に鑑みてなされたもので、その目的とするところは、信頼される外部リソースによって認証されたユーザが、固有でローカルなユーザアカウントも有することを要せずに選択されたオブジェクトに制御されたレベルのアクセスを得ることを可能にし、認証のクレデンシャルの制約された委任を提供する、アクセス制御を提供する方法、記録媒体及びアクセスを制御するシステムを提供することにある。
【００１６】
【課題を解決するための手段】
本明細書では、信頼される外部リソースによって認証されたユーザが、固有でローカルなユーザアカウントも有することを要せずに選択されたオブジェクトに制御されたレベルのアクセスを得ることを可能にする改良された方法およびシステムが提供される。この方法およびシステムは、非常に多数のユーザに様々なリソースへのアクセスを提供するように構成されたコンピュータシステム構成および／またはネットワーク構成の拡張容易性を大きく低下させることなしに実施することが可能である。
【００１７】
前述した必要性およびその他の必要性は、例えば、少なくとも１つのコンピューティングリソースに対するアクセス制御を提供するための方法によって満たすことが可能である。本発明は、コンピュータリソースへのアクセスを求めるユーザに関連する固有識別子を受け取るステップを含む。好ましくは、固有識別子は、信頼に値すると考えられ、かつ／または何らかの形でユーザにサービスを提供し、しばしば、認証も行う別のコンピューティングリソースによって生成されている。この方法は、受け取られた固有識別子を、コンピューティングリソースを保護しているアクセス制御機構とともに使用するのに適したセキュリティ識別子（ＳＩＤ）に変換するステップを含む。この方法は、ＳＩＤが、アクセス制御機構により前に記憶され、コンピューティングリソースに関連している少なくとも１つの他のＳＩＤに一致するかどうかを判定するステップをさらに含む。ある例としての実施形態では、固有識別子は、例えば、マイクロソフトコーポレーションによって提供されるＰａｓｓｐｏｒｔ（商標）サービスによって使用されるようなペアワイズ固有識別子（ＰＵＩＤ；ｐａｉｒ　ｗｉｓｅ　ｕｎｉｑｕｅ　ｉｄｅｎｔｉｆｉｅｒ）を含み、またアクセス制御機構は、アクセス制御リスト（ＡＣＬ）を使用して、コンピューティングリソースにアクセスすることを許されたユーザまたはユーザのグループを確立する。
【００１８】
本発明のいくつかの他の実施形態によれば、少なくとも１つのコンピューティングリソースに対するアクセス制御許可を確立するための方法が提供される。この場合、その方法は、コンピューティングリソースに対して少なくとも限られたアクセスが許可される少なくとも１名のユーザの少なくとも１つの電子メール（ｅ−ｍａｉｌ）アドレスを受け取るステップを含む。例えば、アクセス制御機構によって許可されたユーザが、別のユーザの電子メールアドレスを入力することが可能であり、またアクセスされるコンピュータリソースを指定し、および／またはそのコンピュータリソースにアクセスする際にこの別のユーザが有する特権を指定することが可能である。この方法は、電子メールアドレスに基づいてユーザに関連する固有識別子を戻すことができる、信頼に値するサービスに電子メールアドレスを提供するステップをさらに含む。この方法は、固有識別子を受け取り、次に、その固有識別子に基づいて少なくとも１つのアクセス制御許可を設定するステップを含む。このステップは、例えば、固有識別子をＳＩＤに変換するステップ、およびＳＩＤをコンピューティングリソースに関する少なくとも１つのアクセス制御リストＡＣＬに関連付けるステップを含むことが可能である。
【００１９】
本発明のさらに別の態様によれば、ＰＵＩＤを対応するＳＩＤに変換するための方法が提供される。この方法は、ＰＵＩＤを受け取るステップ、ＰＵＩＤを少なくとも１つの下位権限識別子部分（ｓｕｂ　ａｕｔｈｏｒｉｔｙ　ｉｄｅｎｔｉｆｉｅｒ　ｐｏｒｔｉｏｎ）と少なくとも１つのメンバ識別子部分に細分するステップ、および下位権限識別子部分およびメンバ識別子部分を配列してＳＩＤを形成するステップを含む。
【００２０】
また、本発明のいくつかの実施形態によれば、少なくとも１つのコンピューティングリソースへのアクセスを制御するためのシステムも提供される。このシステムは、コンピューティングリソースへのアクセスの提供を受けるユーザに関連する固有識別子を受け取り、その固有識別子をセキュリティ識別子（ＳＩＤ）に変換し、そのＳＩＤが、メモリの中に記憶され、コンピューティングリソースに関連する少なくとも１つの別のＳＩＤに一致するかどうかを判定するように構成可能な論理およびメモリを含む。
【００２１】
コンピューティングリソースに関するアクセス制御許可を設定するため、いくつかの例としてのシステムが提供される。１つのシステムは、第１のデバイスと少なくとも１つの別のデバイスを接続する通信網を含む。第１のデバイスは、コンピューティングリソースに対する少なくとも限られたアクセスが許可される少なくとも１名のユーザの電子メールアドレスを受け付け、ネットワークを介して他方のデバイスにその電子メールアドレスを提供し、他方のデバイスから、ネットワークを介してその電子メールアドレスに関連する対応する固有識別子を受け取り、その固有識別子に基づいてコンピューティングリソースに関連する少なくとも１つのアクセス制御許可を設定するように構成される。他方のデバイスは、ネットワークを介して電子メールアドレスを受け取り、電子メールアドレスを固有識別子に変換し、ネットワークを介して固有識別子を第１のデバイスに出力するように構成される。
【００２２】
また本明細書では、認証のクレデンシャルの制約された委任を提供する改良された方法およびシステムを提供する。
【００２３】
前述した必要性およびその他の必要性が、例えば、クライアントに代行してアクセスが求められる目標サービスを特定するステップと、サーバ自らによって使用されるための、信頼される第三者からの新しいサービスのクレデンシャルをサーバに要求させるステップとを含む方法によって満たされる。これを実行するため、サーバは、そのサーバを認証するクレデンシャル、目標サービスに関する情報、およびクライアントによって、またはクライアントに代行してサーバによって以前に獲得されたサービスのクレデンシャルを信頼される第三者に提供する。この場合、新しいサービスのクレデンシャルは、サーバの識別においてではなく、クライアントの識別において交付されるが、目標サービスにアクセスを得るためサーバによって使用されることだけが可能である。
【００２４】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を詳細に説明する。本発明の様々な方法およびシステムのより完全な理解は、添付の図面と併せて考慮される以下の詳細な説明を参照することによって得ることができる。
【００２５】
概要
ユーザ／リソースを認証する際に、かつ／または、あるリソースにアクセスを得ようと試みているユーザに許可コンテキストを提供する際に実施することが可能ないくつかの例としての方法およびシステムを本明細書で説明する。
【００２６】
次のセクションは、例としてのコンピューティング環境を説明する。それに続くセクションは、米国特許出願第０９／８８６，１４６号の主題である例としてのＳ４Ｕ２ｐｒｏｘｙ技術およびＳ４Ｕ２ｓｅｌｆ技術を簡単に説明する。
【００２７】
その後、本発明のいくつかの態様による新しい許可スキームを提供する技術を説明し、添付の図面で示す。例えば、信頼される外部サービスによって認証されたクライアントサービス（例えば、ユーザ）が、ローカルアクセス制御能力も有することを要さずに、選択されたローカルサーバリソースに対して制御されたレベルのアクセスを得ることを可能にする改良された方法およびシステムが提供される。明らかとなるとおり、本明細書で説明する許可スキームを様々な仕方で使用して、コンピューティングリソースのセキュリティ、およびコンピューティングリソースによって提供されるサービスにユーザがアクセスを得る能力を向上させることが可能である。
【００２８】
例としてのコンピューティング環境
同様の符号が同様の要素を指している図面を参照すると、本発明は、適切なコンピューティング環境において実施されているものとして示されている。必須ではないが、本発明は、パーソナルコンピュータによって実行される、プログラムモジュールなどの、コンピュータ実行可能命令の一般的な状況で説明する。一般に、プログラムモジュールには、特定のタスクを行う、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、構成要素、およびデータ構造等が含まれる。さらに、本発明は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースの家庭用電化製品またはプログラマブル家庭用電化製品、ネットワークＰＣ（ｐｅｒｓｏｎａｌ　ｃｏｍｐｕｔｅｒ）、ミニコンピュータ、メインフレームコンピュータ等を含め、他のコンピュータシステムの構成で実施できることが、当業者には理解されよう。また、本発明は、通信網を介してリンクされたリモートの処理デバイスによってタスクが行われる分散コンピューティング環境において実施してもよい。分散コンピューティング環境では、プログラムモジュールは、ローカルのメモリ記憶デバイスとリモートのメモリ記憶デバイスの両方の中に配置されることが可能である。
【００２９】
図１は、以下に説明する方法およびシステムを実施することが可能な適切なコンピューティング環境１２０の例を示している。
【００３０】
例としてのコンピューティング環境１２０は、適切なコンピューティング環境の一例に過ぎず、本明細書で説明する改良された方法およびシステムの用法または機能の範囲に関して何らかの限定を示唆するものではない。また、コンピューティング環境１２０が、コンピューティング環境１２０に図示した構成要素のいずれか１つ、または組合せに関連する依存性または要件を有するものと解釈されるべきでもない。
【００３１】
本明細書の改良された方法およびシステムは、多数の他の汎用または特殊目的のコンピューティングシステム環境またはコンピューティングシステム構成で動作する。適切である周知のコンピューティングシステム、コンピューティングシステム環境、および／またはコンピューティングシステム構成の例には、パーソナルコンピュータ、サーバコンピュータ、シンクライアント（ｔｈｉｎ　ｃｌｉｅｎｔ）、シッククライアント（ｔｈｉｃｋ　ｃｌｉｅｎｔ）、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、以上のシステムまたはデバイスのいずれかを含む分散コンピューティング環境等が含まれるが、以上には限定されない。
【００３２】
図１に示すとおり、コンピューティング環境１２０は、コンピュータ１３０の形態で汎用コンピューティングデバイスを含む。コンピュータ１３０の構成要素には、１つまたは複数のプロセッサまたは処理ユニット１３２、システムメモリ１３４、およびシステムメモリ１３４からプロセッサ１３２までを含む様々なシステム構成要素を結合するバス１３６が含まれることが可能である。
【００３３】
バス１３６は、様々なバスアーキテクチャの任意のものを使用する、メモリバスまたはメモリコントローラ、周辺バス、アクセラレーテッドグラフィックスポート（ａｃｃｅｌｅｒａｔｅｄ　ｇｒａｐｈｉｃｓ　ｐｏｒｔ）、およびプロセッサバスまたはローカルバスを含むいくつかのタイプのバス構造の任意のものの１つまたは複数を表す。例として、限定としてではなく、そのようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ　Ｓｔａｎｄａｒｄ　Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ　Ｃｈａｎｎｅｌ　Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ　ＩＳＡ）バス、ＶＥＳＡ（ＶｉｄｅｏＥｌｅｃｔｒｏｎｉｃｓ　Ｓｔａｎｄａｒｄｓ　Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニン（Ｍｅｚｚａｎｉｎｅ）バスとしても知られるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ　Ｃｏｍｐｏｎｅｎｔ　Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスが含まれる。
【００３４】
コンピュータ１３０は、通常、様々なコンピュータ可読媒体を含む。そのような媒体は、コンピュータ１３０がアクセス可能な任意の利用可能な媒体であることが可能であり、揮発性の媒体と不揮発性の媒体、リムーバルな媒体とノンリムーバルな媒体がともに含まれる。
【００３５】
図１では、システムメモリ１３４が、ランダムアクセスメモリ（ＲＡＭ）１４０のような揮発性メモリ、および／または読取り専用メモリ（ＲＯＭ）１３８のような不揮発性メモリの形態でコンピュータ可読媒体を含む。スタートアップ中などに、コンピュータ１３０内部の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（Ｂａｓｉｃ　Ｉｎｐｕｔ／Ｏｕｔｐｕｔ　Ｓｙｓｔｅｍ）１４２が、ＲＯＭ１３８の中に記憶されている。ＲＡＭ１４０は、通常、プロセッサ１３２によって即時にアクセス可能であり、かつ／または現在、演算が行われているデータおよび／またはプログラムモジュールを含む。
【００３６】
コンピュータ１３０は、他のリムーバルな／ノンリムーバルな、揮発性／不揮発性のコンピュータ記憶媒体をさらに含む。例えば、図１は、ノンリムーバルな不揮発性の磁気媒体（図示せず、通常、「ハードドライブ」と呼ばれる）に対して読取りおよび書込みを行うためのハードディスクドライブ１４４、リムーバルな不揮発性の磁気ディスク１４８（例えば、「フロッピー（登録商標）ディスク」）に対して読取りおよび書込みを行うための磁気ディスクドライブ１４６、およびＣＤ（ｃｏｍｐａｃｔ　ｄｉｓｃ　［ｄｉｓｋ］）−ＲＯＭ／Ｒ（ｒｅｃｏｒｄａｂｌｅ）／ＲＷ（ＲｅＷｒｉｔａｂｌｅ）、ＤＶＤ（ｄｉｇｉｔａｌ　ｖｅｒｓａｔｉｌｅ　ｄｉｓｋ）−ＲＯＭ／Ｒ／ＲＷ／＋Ｒ／ＲＡＭ、またはその他の光媒体などのリムーバルな不揮発性の光ディスク１５２に対して読取りおよび書込みを行うための光ディスクドライブ１５０を示している。ハードディスクドライブ１４４、磁気ディスクドライブ１４６、および光ディスクドライブ１５０はそれぞれ、１つまたは複数のインタフェース１５４でバス１３６に接続される。
【００３７】
以上のドライブおよび関連するコンピュータ可読媒体により、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性ストーレッジがコンピュータ１３０に提供される。本明細書で説明する例としての環境は、ハードディスク、リムーバルな磁気ディスク１４８、およびリムーバルな光ディスク１５２を使用するが、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）などの、コンピュータがアクセス可能なデータを記憶することができる他のタイプのコンピュータ可読媒体も、例としての動作環境において使用できることが、当業者には理解されよう。
【００３８】
例えば、オペレーティングシステム１５８ａ、１５８ｂ、１つまたは複数のアプリケーションプログラム１６０ａ、１６０ｂ、その他のプログラムモジュール１６２ａ、１６２ｂ、およびプログラムデータ１６４ａ、１６４ｂを含め、いくつかのプログラムモジュールが、ハードディスク、磁気ディスク１４８、光ディスク１５２、ＲＯＭ１３８、またはＲＡＭ１４０に記憶されていることが可能である。
【００３９】
本明細書で説明する改良された方法およびシステムは、オペレーティングシステム１５８ａ、１５８ｂ、１つまたは複数のアプリケーションプログラム１６０ａ、１６０ｂ、その他のプログラムモジュール１６２ａ、１６２ｂ、および／またはプログラムデータ１６４ａ、１６４ｂの内部に実装することが可能である。
【００４０】
ユーザは、キーボード１６６やポインティングデバイス１６８（「マウス」などの）などの入力デバイスを介してコマンドおよび情報をコンピュータ１３０に提供することができる。他の入力デバイス（図示せず）には、マイクロホン、ジョイスティック、ゲームパッド、サテライトディッシュ、シリアルポート、スキャナ、カメラ等が含まれることが可能である。以上の入力デバイスおよびその他の入力デバイスは、バス１３６に結合されたユーザ入力インタフェース１７０を介してプロセッサ１３２に接続されるが、パラレルポート、ゲームポート、またはＵＳＢ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ）などの他のインタフェースおよびバス構造で接続してもよい。
【００４１】
モニタ１７２、またはその他のタイプの表示デバイスも、ビデオアダプタ１７４などのインタフェースを介してバス１３６に接続される。モニタ１７２に加えて、パーソナルコンピュータは、通常、出力周辺インタフェース１７５を介して接続することが可能なスピーカやプリンタなどの他の周辺出力デバイス（図示せず）も含む。
【００４２】
コンピュータ１３０は、リモートコンピュータ１８２のような１つまたは複数のリモートコンピュータに対する論理接続を使用するネットワーク化された環境において動作することが可能である。リモートコンピュータ１８２は、コンピュータ１３０に関連して本明細書で説明した要素および特徴の多く、またはすべてを含むことが可能である。
【００４３】
図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７７、および一般的なワイドエリアネットワーク（ＷＡＮ）１７９である。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータ網、イントラネット、およびインターネットで一般的である。
【００４４】
ＬＡＮネットワーキング環境で使用されるとき、コンピュータ１３０は、ネットワークインタフェースまたはネットワークアダプタ１８６を介してＬＡＮ１７７に接続される。ＷＡＮネットワーキング環境で使用されるとき、コンピュータは、通常、ＷＡＮ１７９を介して通信を確立するためのモデム１７８、またはその他の手段を含む。内部にあることも外部にあることも可能なモデム１７８は、ユーザ入力インタフェース１７０または他の適切な機構を介してシステムバス１３６に接続されることが可能である。
【００４５】
図１には、インターネットを介するＷＡＮの特定の実施形態を描いている。この場合、コンピュータ１３０は、モデム１７８を使用して、インターネット１８０を介して少なくとも１つのリモートコンピュータ１８２との通信を確立する。
【００４６】
ネットワーク化された環境では、コンピュータ１３０に関連して描いたプログラムモジュール、またはプログラムモジュールの部分が、リモートのメモリ記憶デバイスの中に記憶されることが可能である。したがって、例えば、図１に描いたとおり、リモートのアプリケーションプログラム１８９が、リモートコンピュータ１８２のメモリデバイス上に常駐することが可能である。図示して説明したネットワーク接続は、例としてのものであり、コンピュータ間で通信リンクを確立する他の手段も使用できることが十分理解されよう。
【００４７】
例としてのＳ４Ｕ２Ｐｒｏｘｙ委任技術およびＳ４Ｕ２Ｓｅｌｆ委任技術の概要
次に、以下の説明は、クライアント−サーバネットワーク環境において認証のクレデンシャルの委任の範囲を制御するためのある技術に簡単に焦点を当てる。この例では、ケルベロスベースのシステムを説明する。Ｓ４Ｕ２Ｐｒｏｘｙ技術およびＳ４Ｕ２Ｓｅｌｆ技術、および以下に説明する許可技術は、同一のシステムにおいて実施することも、しないことも可能であり、他の証明書ベースの認証システムにおいて実施することも可能である。
【００４８】
以下の説明は、クライアント−サーバネットワーク環境における認証のクレデンシャルの委任の範囲を制御するための本発明のいくつかの態様を中心に扱う。以下の説明は、例としてのケルベロスベースのシステムおよびその改良形態を中心に扱うが、本発明の様々な方法およびシステムは、その他の認証システムおよび認証技術にも明らかに適用可能である。例えば、証明書ベースの認証システムおよび認証技術が、本発明のいくつかの態様を適合させることができる。
【００４９】
前述したとおり、クライアントのＴＧＴ、および関連する認証符号（ａｕｔｈｅｎｔｉｃａｔｏｒ）を所有することにより、保持者は、信頼される第三者、例えば、ＫＤＣからクライアントに代行してチケットを要求することが可能になる。そのような制約なしの委任が、現在、先進のチケット委任スキームを有するケルベロスのある実施形態においてサポートされている。
【００５０】
このことを念頭に、米国特許出願第０９／８８６，１４６号は、委任プロセスを制約する、または別の形でよりよく制御する方法およびシステムを説明している。委任プロセスは、例えば、フロントエンドサーバ／サービスなどのサーバまたはサービスが、他のサーバ／サービスで使用するためにクライアントに代行してサービスチケットを要求すること可能にするＳ４Ｕ２ｐｒｏｘｙ（ｓｅｒｖｉｃｅ−ｆｏｒ−ｕｓｅｒ−ｔｏ−ｐｒｏｘｙ）技術を介して制御することが可能である。Ｓ４Ｕ２ｐｒｏｘｙプロトコルは、有利には、クライアントがＴＧＴをフロントエンドサーバに転送することを要しない制御可能な仕方で制約された委任を提供する。別の技術は、サーバが、そのサーバ自らに対するサービスチケットを要求するが、クライアントの識別が結果のサービスチケットにおいて提供されることを可能にするＳ４Ｕ２ｓｅｌｆ（（ｓｅｒｖｉｃｅ−ｆｏｒ−ｕｓｅｒ−ｔｏ−ｓｅｌｆ））プロトコルである。この技術により、例えば、他の認証プロトコルによって認証されたクライアントが、Ｓ４Ｕ２ｐｒｏｘｙプロトコルとともに使用して制約された委任を提供することができるサービスチケットを受け取ることが可能になる。Ｓ４Ｕ２ｓｅｌｆ技術には２つの例としての形態、すなわち、「無証拠（ｎｏ　ｅｖｉｄｅｎｃｅ）」形態、および「証拠」形態が存在する。無証拠形態では、サーバは、例えば、そのサーバに専用の別のセキュリティ／認証機構を使用してクライアントを認証するものと信頼されている。証拠形態では、ＫＤＣ（または信頼される第三者）が、クライアントがサーバに対して認証されたときに獲得されたクライアントに関して提供される情報（証拠）に基づいて認証を行う。
【００５１】
したがって、クライアントは、ケルベロスによって認証されたか、または何らかの他の認証プロトコルによって認証されたかに関わらず、ケルベロス環境内でサーバ／サービスにアクセスすることができる。したがって、バックエンドおよび／またはその他のサーバ／サービスは、基本的にケルベロスだけの環境において動作させることが可能である。
【００５２】
次に、クライアント−サーバ環境２００内のＳ４Ｕ２ｐｒｏｘｙプロトコル／プロセスを描いた図２のブロック図を参照する。図示するとおり、クライアント２０２は、認証サービス２０６、例えば、ＫＤＣ、証明書交付機関、ドメインコントローラ、および／または以上に類するものを有する信頼される第三者２０４に動作上、結合される。認証サービス２０６は、データベース２０８の中に保持される情報にアクセスするように構成される。クライアント２０２、および信頼される第三者２０４は、動作上、サーバ、すなわち、サーバＡ２１０にさらに結合される。本明細書で使用するサーバおよびサービスという用語は、区別なく使用されて同一または同様の機能を表すことに留意されたい。
【００５３】
この例では、サーバＡ２１０は、複数の他のサーバに対するフロントエンドサーバである。したがって、描いているように、サーバＡ２１０は、動作上、サーバＢ２１２およびサーバＣ２１４に結合される。図示するとおり、サーバＢ２１２は、複製されたサービスであることが可能である。また、サーバＣ２１４は、動作上、サーバＤ２１６にさらに結合される。
【００５４】
クライアント２０２でログオンするユーザに応答して、認証要求（ＡＳ＿ＲＥＱ）メッセージ２２０が、認証サービス２０６に送信され、認証サービス２０６は、認証応答（ＡＳ＿ＲＥＰ）メッセージ２２２で応答する。ＡＳ＿ＲＥＰメッセージ２２２内部には、ユーザ／クライアントに関連するＴＧＴがある。サーバＡ２１０を認証するのに同一または同様の手続き（図示せず）が行われる。
【００５５】
クライアント２０２は、サーバＡ２１０にアクセスすることを望むとき、チケット交付サービス要求（ＴＧＳ＿ＲＥＱ）メッセージ２２４を認証サービス２０６に送信し、認証サービス２０６は、チケット交付サービス応答（ＴＧＳ＿ＲＥＰ）メッセージ２２６を戻す。ＴＧＳ＿ＲＥＰメッセージ２２６は、クライアント２０２およびサーバＡ２１０に関連するサービスチケットを含む。続いて、通信セッションを開始するため、クライアント２０２が、アプリケーションプロトコル要求（ＡＰ＿ＲＥＱ）メッセージ２２８の中でサービスチケットをサーバＡ２１０に転送する。そのようなプロセス／手続きは周知であり、このため、本明細書でより詳細に開示することはしない。
【００５６】
あるシステムでは、委任をサポートするため、クライアントは、クライアントのＴＧＴをサーバＡ２１０に提供して、サーバＡ２１０が、クライアント２０２に代行してさらなるサービスチケットを要求することを可能にする必要がある。これは、Ｓ４Ｕ２ｐｒｏｘｙプロトコルでは必要ない。代わりに、サーバＡ２１０が、クライアント２０２に代行して別のサーバ、例えば、サーバＣ２１４にアクセスする必要があるとき、サーバＡ２１０および認証サービス２０６が、Ｓ４Ｕ２ｐｒｏｘｙプロトコルに従って動作する。
【００５７】
サーバＡ２１０は、ＴＧＳ＿ＲＥＱメッセージ２３０を認証サービス２０６に送信する。ＴＧＳ＿ＲＥＱメッセージ２３０は、サーバＡ２１０のためのＴＧＴ、およびクライアント２０２から受け取れたサービスチケットを含み、クライアント２０２がアクセスを求めている所望のサーバ／サービスまたは目標のサーバ／サービス、例えば、サーバＣ２１４を特定する。例えば、ケルベロスでは、通常、「追加チケット」フィールドと呼ばれる定義された拡張可能なデータフィールドが存在する。この追加のチケットフィールドをＳ４Ｕ２ｐｒｏｘｙプロトコルにおいて使用して、クライアント２０２から受け取れたサービスチケットを搬送することが可能であり、またＫＤＣオプションフィールドが、受信側ＫＤＣに、クライアントの識別を供給するのに使用されるチケットを追加チケットフィールドの中で探すように指示するフラグまたは他のインジケータを含むことが可能である。以上のフィールドおよびその他のフィールドおよび／またはデータ構造を使用して必要な情報を認証サービス２０６に搬送できることが、当業者には認識されよう。
【００５８】
ＴＧＳ＿ＲＥＱ２３０を処理する際、認証サービス２０６は、例えば、クライアント２０２によって確立された「転送可能フラグ」の値に基づき、クライアント２０２が委任を許可したかどうかを判定する。したがって、クライアントごとの委任が、クライアントのサービスチケットの中の転送可能フラグの存在によって実施される。クライアント２０２が、委任に参加することを望まない場合は、チケットには、転送可能なものとしてフラグが立てられない。認証サービス２０６は、このフラグをクライアントによって起こされた制限として遵守する。認証サービス２０６は、クライアント２０２に関してサーバＡ２１０が委任を受ける（または委任を受けない）ことが許可されている選択されたサービスを定義するデータベース２０８の中のさらなる情報にアクセスすることができる。
【００５９】
認証サービス２０６が、サーバＡ２１０が目標のサーバ／サービスに対する委任を受けることが許されていると判定した場合、ＴＧＳ＿ＲＥＰメッセージ２３２がサーバＡ２１０に送信される。ＴＧＳ＿ＲＥＰメッセージ２３２は、目標のサーバ／サービスに関するサービスチケットを含む。このサービスチケットは、あたかも、クライアント２０２が、例えば、クライアントのＴＧＴを使用してそのチケットを認証サービス２０６に直接に要求したかのように見える。しかし、直接の要求は行われていない。代わりに、認証されたサーバＡ２１０がクライアント２０２から受け取りＴＧＳ＿ＲＥＱメッセージ２３０に含まれるサービスチケットに基づき、認証されたクライアントが基本的にその要求に関わっていることの確信が得られた後、認証サービス２０６は、データベース２０８の中の同様の／必要なクライアント情報にアクセスする。ただし、クライアント情報は、クライアントのチケットの中で搬送されるので、サーバは、そのチケットからデータをコピーするだけでよい。
【００６０】
したがって、データベース２０８を使用することが可能であるが、チケットの中のデータをコピーすることの方が、より効率的である傾向がある。
【００６１】
ある実施形態では、ＴＧＳ＿ＲＥＰメッセージ２３２が、目標のサーバ／サービス、およびクライアント２０２を特定し、また、例えば、ＰＡＣ（ｐｒｉｖｉｌｅｇｅ　ａｔｔｒｉｂｕｔｅ　ｃｅｒｔｉｆｉｃａｔｅ）、セキュリティ識別子、Ｕｎｉｘ（登録商標）　ＩＤ、Ｐａｓｓｐｏｒｔ　ＩＤ、証明書等の形態で、実施形態特有の識別／ユーザ／クライアントアカウントのデータをさらに含む。ＰＡＣは、例えば、認証サービス２０６によって生成されること、または単に、ＴＧＳ＿ＲＥＱメッセージ２３０に含まれていたクライアントのサービスチケットからコピーされることが可能である。Ｐａｓｓｐｏｒｔ　ＩＤの用法は、以下に提示する例としての許可コンテキスト生成スキームにおいてさらに説明する。
【００６２】
ＰＡＣ、またはその他のユーザ／クライアントアカウントのデータは、委任の範囲に関連する情報を含むように構成することが可能である。したがって、例えば、図４は、ヘッダ４０２およびＰＡＣ４０４を有するケルベロスメッセージ４００の選択された部分を描いた図である。この場合、ＰＡＣ４０４は、委任情報４０６を含む。図示するとおり、委任情報４０６は、合成識別情報４０８、およびアクセス制限情報４１０を含む。
【００６３】
合成識別情報４０８は、例えば、サーバＡ２１０が、ユーザ／クライアント２０２に代行してサービスチケットを要求したことに関する指示などの、委任プロセスに関する記録された情報を含むことが可能である。この場合、複数の委任プロセスにわたる履歴を、つなぎ合わせる、または別の仕方で特定するのに使用することが可能な、複数のそのような記録された情報が提供されることが可能である。そのような情報は、監査目的および／またはアクセス制御目的で役立つ可能性がある。
【００６４】
例えば、アクセス制御機構と併せてアクセス制限情報４１０を使用して、クライアント２０２が、直接的に、または間接的にサーバＡ２１０を介して、サーバ／サービスにアクセスすることを求めたという条件付きで、そのサーバ／サービスに対するアクセスを選択的に許可するが、サーバ／サービスが、サーバＢ２１２を介して間接的に求められた場合には、許可しないことが可能である。この特徴は認証のクレデンシャルの委任に対する追加の制御を追加する。
【００６５】
前述した例では、クライアント２０２が、認証サービス２０６によって認証される。ただし、他のクライアントは、そのように認証されない可能性があることが認められる。そのような状況の例を図３Ａで環境３００ａにおいて描いている。この場合、クライアント３０２ａが、異なる認証プロトコル機構３０３を使用して認証されている。例えば、認証プロトコル機構３０３は、Ｐａｓｓｐｏｒｔ、ＳＳＬ（Ｓｅｃｕｒｅ　Ｓｏｃｋｅｔ　Ｌａｙｅｒ）、ＮＴＬＭ、Ｄｉｇｅｓｔ、またはその他の同様な認証プロトコル／手続きを含むことが可能である。この場合、この例では、クライアント３０２ａが、たまたま、サーバＣ２１４によって提供されている目標のサービスにアクセスすることを選択するものと想定されている。この選択は、前述したＳ４Ｕ２ｐｒｏｘｙプロトコルを使用して満たすことができるが、ただし、サーバＡ２１０が、Ｓ４Ｕ２ｓｅｌｆプロトコル／手続きを完了／実行して初めて満たすことができる。
【００６６】
Ｓ４Ｕ２ｓｅｌｆプロトコルの１つの基本的な前提は、サーバ、例えば、サーバＡ２１０が、そのサーバにアクセスしており、そのサーバが認証した任意のユーザ／クライアントのために、そのサーバ自体に対するサービスチケットを要求することができることである。本明細書で説明する例としてのＳ４Ｕ２ｓｅｌｆプロトコルは、認証する「証拠」を有するクライアント、およびそのような認証する証拠を有さないクライアントをサポートするように構成される。
【００６７】
認証サービス２０６によって評価されることが可能な認証証拠が存在しない場合、サーバＡ２１０が、クライアント３０２ａを「信頼」するようになる必要がある。したがって、例えば、クライアント３０２ａが、サーバＡ２１０が確認することができる認証証明書または同様の機構３０４を有する場合には、クライアント３０２ａは、「信頼される」ものと判定することが可能である。したがって、サーバＡ２１０が、基本的に、クライアント３０２ａを認証している。
【００６８】
次に、サーバＡ２１０が、ＴＧＳ＿ＲＥＱメッセージ３０６を認証サービス２０６に送信して、クライアント３０２ａのためにそのサーバ自らに対するサービスチケットを要求する。これに応答して、認証サービス２０６は、要求されたサービスチケットを含むＴＧＳ＿ＲＥＰメッセージ３０８を生成する。次に、受け取られたサービスチケットが、後続のＳ４Ｕ２ｐｒｏｘｙプロトコル／手続きにおいて、クライアント３０２ａのためにサーバＣ２１４に対するサービスチケットを要求するのに使用される。例えば、あるケルベロス実施形態では、このことは、ＴＧＳ＿ＲＥＰメッセージ３０８の中の転送可能フラグが、サービスチケットの転送を可能にするように設定されることを要する。また、信頼される第三者が、クライアント３０２ａのためにＰＡＣを作成することも可能であり、次に、このＰＡＣを結果のサービスチケットの中に含めることが可能である。
【００６９】
クライアント３０２ｂに関して認証の証拠が存在する場合、サーバＡ２１０は、そのような証拠を追加の認証前データとしてＴＧＳ＿ＲＥＱメッセージ３１２の中に含めることができる。このことを図３Ｂで環境３００ｂにおいて描いている。この場合、証拠情報３１０は、クライアント３０２ｂによってサーバＡ２１０に提供される。証拠情報３１０は、例えば、チャレンジ／応答ダイアログ、または別の「信頼される」エンティティによって生成された他の情報を含むことが可能である。証拠情報３１０の受領、およびその後の確認の後、認証サービス２０６は、要求されたサービスチケットをサーバＡ２１０自体に交付する。ある実施形態では、証拠を使用することで、サーバが、クライアントに関する制限されたＴＧＴを獲得することが可能になることに留意されたい。
【００７０】
あるケルベロスの実施形態では、ＴＧＳ＿ＲＥＰメッセージ３１４の中の転送可能フラグが、サービスチケットの転送を可能にするように設定される。ＰＡＣがＴＧＳ＿ＲＥＱメッセージ３１２の中で提供されている場合、ＰＡＣをサービスチケットの中で使用することができる。そうでない場合、ＰＡＣが、証拠情報３１０に基づいて認証サービス２０６（この場合、ＫＤＣ）によって生成されることが可能である。例えば、Ｓ４Ｕ２ｓｅｌｆでは、クライアントの識別は、認証前データの中に含まれる。この識別をそのクライアントに関するＰＡＣの構成の際に使用し、（クライアントのために）サーバに発行されるサービスチケットに追加することができる。
【００７１】
例としての許可コンテキスト生成技術
以下の説明は、本発明のある実施形態による例としての方法およびシステムを中心に扱う。この方法およびシステムは、Ｓ４Ｕ２ｐｒｏｘｙプロトコルおよび／またはＳ４Ｕ２ｓｅｌｆプロトコルを使用してもしなくても実施することができる。この方法およびシステムは、ケルベロスを使用してもしなくても実施することができる。この方法およびシステムは、（ワシントン州レッドモンドのマイクロソフトコーポレーションによって提供される）Ｐａｓｓｐｏｒｔサービスを使用してもしなくても実施することができる。この技術は、様々な他のプロトコルおよび／またはサービスを使用して実施できることが当業者には認識されよう。それでも、以下の例では、必要な場合、許可コンテキスト生成技術をサポートするのに以上のプロトコルおよびサービスが利用可能なものと想定する。
【００７２】
次に、あるリソースにアクセスする許可をさもなければ有さないユーザに許可コンテキストを提供することができる、クライアント−サーバネットワーク構成５００に関連するある特徴／機能／プロセスを描いた例としてのブロック図である図５を参照する。
【００７３】
図示するとおり、サーバＸ５０２が、サーバＹ５０４、ユーザ（Ｕ１）５９１に関連する第１のクライアント５０６、およびユーザ（Ｕ２）５９２に関連する第２のクライアント５０８に動作上、結合されている。この例では、破線のボックス５１０、５１２、および５１４で表すとおり、以上のデバイス間でいくつかの信頼関係が存在する。したがって、例えば、オブジェクト５１６などのサーバＸ５０２によって提供されるリソースにアクセスするため、Ｕ１がクライアント５０６およびサーバＸ５０２にログオンしたとき、信頼関係５１０を形成するようにクライアント５０６およびサーバＸ５０２が構成される。このログオン手続きは、認証およびアクセス制御を含むことが可能である。同様に、クライアント５０８およびサーバＹ５０４は、Ｕ２がクライアント５０８およびサーバＹ５０４にログオンしたとき、信頼関係５１２を形成するように構成される。さらに、この例では、サーバＸ５０２およびサーバＹ５０４は、信頼される第三者２０４を介して信頼関係５１４を形成することができる。ただし、この時点で、クライアント５０８とサーバＸ５０２の間には信頼関係が存在しないことに注目されたい。
【００７４】
次に、図５を使用し、その後に図６を使用して、Ｕ２がオブジェクト５１６にアクセスを得ることを可能にするサーバＸ５０２に対する許可コンテキストを、クライアント５０８が有することを可能にする、本発明のいくつかの態様を示すプロセスを説明する。図中符号５５０〜５５９矢印は、プロセス動作を例示する。動作の一部は、他の実施形態では異なる順序で行われることが可能である。
【００７５】
動作５５０は、前述したとおり、信頼関係５１０、５１２、および５１４の作成である。そのような信頼関係は、ある操作に関して必要になるのに応じて選択的に作成することができる。
【００７６】
この例では、Ｕ２がオブジェクト５１６にアクセスできるようにすることをＵ１が所望するものと想定する。Ｕ１は、信頼関係５１０を介してオブジェクト５１６にアクセスすることが許可されているが、Ｕ２は、この時点で、オブジェクト５１６にアクセスすることが許可されていない。その上、サーバＸ５０２のアクセス制御システムに別の許可されたユーザのようなＵ２を追加するのを回避することが、さらに所望されている。この状況は、例えば、Ｕ１の雇用者を介して、ホストされまたは別の形で提供されるＵ１のオンライン計画カレンダに、Ｕ２がアクセス可能とすることをＵ１が所望するとき、生じる可能性がある。この場合、雇用者は、システムに新しい許可されたユーザのアカウントを追加することを望まない。
【００７７】
次に、クライアント５０６を介してＵ１に提供されるグラフィカルユーザインタフェース（ＧＵＩ）に関連するある代表的な特徴を示すブロック図６００である図６を参照する。この例では、Ｗｅｂページ６０２またはそれに類するスクリーンが、サーバＸ５０２にログオンした後、Ｕ１に対して表示される。Ｗｅｂページ６０２内で、オブジェクト５１６が、Ｕ１に関する情報を表示するカレンダＧＵＩ６０４を提示する。Ｕ１は、識別子エントリフィールド６０８、および（オプションとして）１つまたは複数の選択可能な許可設定６１０を含むエントリフォーム６０６を開くことができる。最終的にＵ２がオブジェクト５１６に対するアクセスを得ることができるようにするプロセスをＵ１が開始するのは、このフォーム６０６においてである。
【００７８】
Ｕ１は、Ｕ２に関する識別子を入力する。この例では、識別子は、Ｕ２に関する固有のＷｏｒｌｄ　Ｗｉｄｅ　Ｗｅｂ電子メールアドレス、すなわち、ｕｓｅｒ２＠ｈｏｔｍａｉｌ．ｃｏｍを含む。ここで入力される識別子は、マイクロソフトコーポレーションによって提供されるｈｏｔｍａｉｌ．ｃｏｍサービスの登録済みユーザに関するものである。ｈｏｔｍａｉｌ．ｃｏｍの登録済みユーザとして、Ｕ２は、マイクロソフトコーポレーションに対して対応するＰａｓｓｐｏｒｔアカウントも有するものと想定される。また、Ｕ１は、オブジェクト５１６（この場合、例えば、オンライン計画カレンダアプリケーション）に対して許可されたアクセスに関して、Ｕ２に関する１つまたは複数の許可設定６１０を定義することもできる。現行では、Ｕ１は、Ｕ２が読み取り許可を有する許可を設定している。次に、図５を参照すると、このユーザ識別プロセスが、クライアント５０６とサーバＸ５０２の間の動作５５１によって表されている。
【００７９】
サーバＸ５０２は、Ｕ１がＵ２に関するｈｏｔｍａｉｌ．ｃｏｍ識別子を提供したことを認識し、動作５５２で、この場合、周知のＰａｓｓｐｏｒｔサーバであるものと想定されているサーバＹ５０４と通信する。この場合、識別子ｕｓｅｒ２＠ｈｏｔｍａｉｌ．ｃｏｍをサーバＹ５０４に提供し、サーバＹ５０４が対応する一般的に固有なＰａｓｓｐｏｒｔのユーザ識別（ＰＵＩＤ；しばしば、ペアワイズ固有ＩＤとも呼ばれる）を提供することを、サーバＸ５０２は要求する。動作５５３で、サーバＹ５０４が、Ｕ２に関するＰＵＩＤ５２４を戻す。信頼関係５１４がケルベロスベースの関係である場合、例えば、前述したとおり、ＰＡＣの中でＰＵＩＤを戻すことができる。
【００８０】
この時点で、サーバＸ５０２は、Ｕ２に関するＰＵＩＤを有する。動作５５４で、サーバＸ５０２が、サーバＸ５０２のネイティブな認証システムで使用するのに適した対応するＳＩＤ５２２にそのＰＵＩＤを変換する。図示するとおり、オブジェクト５１６は、ＳＩＤ５２２を含む少なくとも１つのＡＣＥ５２０を有している、ＡＣＬ５１８に関連している。
【００８１】
６４ビットのＰＵＩＤは、実際には、１６ビットのＰａｓｓｐｏｒｔドメイン権限識別子（ｄｏｍａｉｎ　ａｕｔｈｏｒｉｔｙ　ｉｄｅｎｔｉｆｉｅｒ）、および４８ビットのメンバ識別子から成る。ＳＩＤを形成するため、ドメイン権限を別個の値として保持することが望ましい。これを行うため、ＭｅｍｂｅｒＩＤＨｉｇｈを２つの部分に分離し、これらの部分を、例えば、以下に示すとおり、別個の下位権限として形成する。
Ｓ−１−１０−２１−（ＨＩＷＯＲＤ（ＭｅｍｂｅｒＩＤＨｉｇｈ））−（ＬＯＷＯＲＤ（ＭｅｍｂｅｒＩＤＨｉｇｈ））−ＭｅｍｂｅｒＩＤＬｏｗ−０
この例では、「Ｓ−１−１０−２１」は、ｎｔｓｅａｐｉ．ｈで定義される新しい識別子権限である。この例としての実施形態では、ｎｔｓｅａｐｉ．ｈは、ＰＵＩＤ−ＳＩＤを構成するのに使用されるこのＳＩＤ値に関する定義を含むＭｉｃｒｏｓｏｆｔ（登録商標）Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムを構築するのに使用されるヘッダファイルである。このヘッダは、通常は、開発者に直接に公開されないことに留意されたい。ただし、ｎｔｓｅａｐｉ．ｈの中の宣言は、ｗｉｎｎｔ．ｈの中のＰｌａｔｆｏｒｍ　ＳＤＫ（Ｓｏｆｔｗａｒｅ　Ｄｅｖｅｌｏｐｍｅｎｔ　Ｋｉｔ）において一般に公開されている。
【００８２】
したがって、「信頼される」ソースから戻された、ＰＵＩＤまたは他の同様な識別子から作成される、例としてのＳＩＤは、基本的に、固有の組合せでかつネイティブな許可システムに互換性のある形式で、周知の下位権限およびメンバユーザを識別する。
【００８３】
動作５５５で、Ｕ２が、サーバＹ５０４にログオンして（認証され）、そうする際にＰＵＩＤ５２４を受け取る。動作５５６で、Ｕ２が、デフォルトの（例えば、未知の、または匿名の）ユーザアカウントを使用してサーバＸ５０２に接続し、要求または他の同様なメッセージの中でＰＵＩＤ５２４を含む（例えば、ＰＡＣの中の）情報を提供する。動作５５７で、サーバＸ５０２が、ＰＵＩＤがこのデフォルトのユーザ（Ｕ２）によって提供されたことを認識し、これに応答して、対応するＳＩＤ５３２を構築し、次にＳＩＤ５３２が、オブジェクト５１６へのアクセスを求めているデフォルトのユーザ（Ｕ２）に関連するトークン５３０の中に入れられる。ある実施形態では、ＳＩＤは、ＰＵＩＤをＬｓａＬｏｇｏｎＵｓｅｒと呼ばれるＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）に送ることによって構築される。このＡＰＩが、ＳＩＤを戻す。
【００８４】
動作５５８で、サーバＸ５０２が、デフォルトのユーザのトークン５３０の中の１つまたは複数のＳＩＤをＡＣＬ５１８の中のＳＩＤと比較することにより、このデフォルトのユーザ（Ｕ２）が、オブジェクト５１６にアクセスする適切なアクセス許可を有するかどうかを判定する。この場合、トークン５３０からのＳＩＤ５３２は、ＡＣＥ５２０の中のＳＩＤ５２２に一致する。したがって、動作５５９で、Ｕ２に関する認証コンテキスト５２６が作成され、これにより、Ｕ２が、該当する許可設定に従ってオブジェクト５１６にアクセスすることが可能になる。したがって、例えば、Ｕ２は、Ｕ１の計画カレンダを閲覧し（読み取り）、Ｕ１とＵ２が、来週、一緒に昼食をとることができる可能性があるかどうかを判定することができる。Ｕ２は、サーバＸ５０２にログオンしなかった。実際、Ｕ２は、サーバＸ５０２にログオンすることができない。とうのは、Ｕ２は、Ｕ１のようにアカウントを有していないからである。この場合のＵ２の認証は、基本的に、信頼関係５１０、５１２、および５１４、ならびにクライアント５０８およびサーバＹ５０４を使用するＵ２の初期の認証に基づく。サーバＸ５０２に対するＵ２のアクセス制御は、基本的に、Ｕ１の信頼される許可（動作５５０におけるクライアント５０６およびサーバＸ５０２を介する）、および動作５５３においてＰＵＩＤを提供する際のサーバＹ５０４との信頼関係に基づいて許可される。
【００８５】
ＰＵＩＤを使用する利点の１つは、もたらされるＳＩＤが、ＰａｓｓｐｏｒｔによるＰＵＩＤの制御された割当てに基づいて、大域的に固有であり永続的であることである。
【００８６】
概要
本発明の様々な方法およびシステムの一部の好適実施形態を添付の図面に示し、以上の詳細な説明で説明してきたが、本発明は、開示した例としての実施形態に限定されず、特許請求の範囲によって提示され、定義される本発明の趣旨を逸脱することなく、多数の再構成、変更、および置換が可能であることが理解されよう。
【００８７】
【発明の効果】
以上説明したように本発明によれば、信頼される外部リソースによって認証されたユーザが、固有でローカルなユーザアカウントも有することを要せずに選択されたオブジェクトに制御されたレベルのアクセスを得ることを可能にし、認証のクレデンシャルの制約された委任を提供することができる。
【図面の簡単な説明】
【図１】本発明の実施形態の例としてのコンピュータシステムを一般的に示すブロック図である。
【図２】本発明の実施形態のクライアント−サーバ環境内のＳ４Ｕ２ｐｒｏｘｙプロセスを描いたブロック図である。
【図３Ａ】本発明の実施形態のクライアント−サーバ環境内のＳ４Ｕ２ｓｅｌｆプロセスを描いたブロック図である。
【図３Ｂ】本発明の実施形態のクライアント−サーバ環境内のＳ４Ｕ２ｓｅｌｆプロセスを描いたブロック図である。
【図４】本発明の実施形態のメッセージ形式の選択された部分を描いた図である。
【図５】本発明の実施形態の、信頼されるリソースによって認証されたユーザにローカルアクセス制御を提供するためのシステムおよびプロセスを描いたブロック図である。
【図６】本発明の実施形態の、例えば、図５と同様に、ローカルアクセス制御アカウントを有さないユーザがあるリソースにアクセスするのを適切な許可信頼のレベルで許可するための、システムおよびプロセスの例としての使用を描いたブロック図である。
【符号の説明】
１２０　コンピューティング環境
１３０　コンピュータ
１３２　プロセッサ
１３４　システムメモリ
１３６　バス
１３８　ＲＯＭ
１４０　ＲＡＭ
１４２　ＢＩＯＳ
１４４　ハードディスクドライブ
１４６　磁気ディスクドライブ
１４８　磁気ディスク
１５０　光ディスクドライブ
１５２　光ディスク
１５４　インタフェース
１５８ａ、１５８ｂ　オペレーティングシステム
１６０ａ、１６０ｂ　アプリケーションプログラム
１６２ａ、１６２ｂ　その他のプログラムモジュール
１６４ａ、１６４ｂ　プログラムデータ
１６６　キーボード
１６８　ポインティングデバイス
１７０　ユーザ入力インタフェース
１７２　モニタ
１７４　ビデオアダプタ
１７５　出力周辺インタフェース
１７７　ＬＡＮ
１７８　モデム
１７９　ＷＡＮ
１８０　インターネット
１８２　リモートコンピュータ
１８６　ネットワークアダプタ
１８９　リモートのアプリケーションプログラム
２００、３００ａ、３００ｂ　クライアント−サーバ環境
２０２、３０２ａ　クライアント
２０４　信頼される第三者
２０６　認証サービス
２０８　データベース
２１０、２１２、２１４、２１６　サーバ
２２０、２２２、２２４、２２６、２２８、２３０、２３２　メッセージ
３０３　認証機構
３０６、３０８、３１０、３１２、３１４　メッセージ
４００　ケルベロスメッセージ
４０２　ヘッダ
４０４　ＰＡＣ
５００　ネットワーク構成
５０２、５０４　サーバ
５０６、５０８　クライアント
５１０、５１２、５１４　信頼関係
５１６　オブジェクト
５１８　アクセス制御リスト
５２０　アクセス制御エントリ
５２２、５３２　セキュリティ識別子
５２４　ペアワイズ固有識別子
５２６　認証コンテキスト
５３０　トークン
５５０〜５５９　プロセス動作の矢印
５９１、５９２　ユーザ

Claims (62)

1. 少なくとも１つのコンピューティングリソースに関するアクセス制御を提供する方法であって、
   前記少なくとも１つのコンピューティングリソースに対するアクセスが与えられるべきユーザに関連した、前記ユーザを認証した別のコンピューティングリソースに関連する固有識別子を受け取るステップと、
   前記固有識別子をセキュリティ識別子（ＳＩＤ）に変換するステップと、
   前記ＳＩＤが、前記少なくとも１つのコンピューティングリソースに関連するアクセス制御機構によって提供される少なくとも１つの他のＳＩＤに一致するかどうかを判定するステップと
   を備えたことを特徴とするアクセス制御を提供する方法。
2. 前記固有識別子は、ペアワイズ固有識別子（ＰＵＩＤ）を含むことを特徴とする請求項１に記載のアクセス制御を提供する方法。
3. 前記ＰＵＩＤは、Ｐａｓｓｐｏｒｔサービスに関連することを特徴とする請求項２に記載のアクセス制御を提供する方法。
4. 前記固有識別子を前記ＳＩＤに変換するステップは、
   前記ＰＵＩＤを少なくとも１つの下位権限識別子部分と少なくとも１つのメンバ識別子部分とに分離するステップ
   をさらに含むことを特徴とする請求項３に記載のアクセス制御を提供する方法。
5. 前記固有識別子を前記ＳＩＤに変換するステップは、
   前記ＰＵＩＤをＡＰＩに提供するステップと、
   引換えに前記ＳＩＤを前記ＡＰＩから受け取るステップと
   をさらに含むことを特徴とする請求項３に記載のアクセス制御を提供する方法。
6. 前記固有識別子を受け取るステップは、
   前記固有識別子をケルベロスベースのメッセージ内部で受け取るステップ
   をさらに含むことを特徴とする請求項１に記載のアクセス制御を提供する方法。
7. 前記固有識別子は、前記ケルベロスベースのメッセージ内部のＰＡＣの中で提供されることを特徴とする請求項６に記載のアクセス制御を提供する方法。
8. 前記ケルベロスベースのメッセージは、Ｓ４Ｕ２ｓｅｌｆプロセスに関連することを特徴とする請求項６に記載のアクセス制御を提供する方法。
9. 前記ケルベロスベースのメッセージは、Ｓ４Ｕ２ｐｒｏｘｙプロセスに関連することを特徴とする請求項６に記載のアクセス制御を提供する方法。
10. 前記ＳＩＤが、前記アクセス制御機構によって提供される前記少なくとも１つの他のＳＩＤに一致するかどうかを判定するステップは、
    前記ＳＩＤを、前記少なくとも１つのコンピューティングリソースに関連するアクセス制御リスト（ＡＣＬ）の中の前記少なくとも１つの他のＳＩＤと比較するステップ
    をさらに含むことを特徴とする請求項１に記載のアクセス制御を提供する方法。
11. 前記少なくとも１つのコンピューティングリソースに対するアクセスが与えられるべき前記ユーザに関連した、前記固有識別子を受け取るステップは、
    前記少なくとも１つのコンピューティングリソースに対するアクセスが与えられるべき前記ユーザにデフォルトのアカウントを提供するステップ
    をさらに含むことを特徴とする請求項１に記載のアクセス制御を提供する方法。
12. 少なくとも１つのコンピューティングリソースに関するアクセス制御許可を確立する方法であって、
    前記少なくとも１つのコンピューティングリソースに対する少なくとも限られたアクセスが許可されるべき少なくとも１つのユーザに関する少なくとも１つの電子メール（ｅ−ｍａｉｌ）アドレスを受け取るステップと、
    前記電子メールアドレスを、前記電子メールアドレスに基づいて前記ユーザに関連する固有識別子を出力することができる少なくとも１つの信頼されるサービスに提供するステップと、
    前記信頼されるサービスによって出力された前記固有識別子を受け取るステップと、
    前記固有識別子に基づき、前記少なくとも１つのコンピューティングリソースに関連する少なくとも１つのユーザアクセス制御許可を設定するステップと
    を備えたことを特徴とするアクセス制御許可を確立する方法。
13. 前記少なくとも１つのユーザアクセス制御許可を設定するステップは、
    前記固有識別子をセキュリティ識別子（ＳＩＤ）に変換するステップと、
    前記ＳＩＤを前記少なくとも１つのコンピューティングリソースに関する少なくとも１つのアクセス制御リスト（ＡＣＬ）に関連付けるステップと
    をさらに含むことを特徴とする請求項１２に記載のアクセス制御許可を確立する方法。
14. 前記固有識別子は、ペアワイズ固有識別子（ＰＵＩＤ）を含むことを特徴とする請求項１２に記載のアクセス制御許可を確立する方法。
15. 前記ＰＵＩＤは、Ｐａｓｓｐｏｒｔサービスに関連することを特徴とする請求項１４に記載のアクセス制御許可を確立する方法。
16. 前記固有識別子は、ＰＵＩＤを含み、かつ前記固有識別子を前記ＳＩＤに変換するステップは、
    前記ＰＵＩＤを少なくとも１つの下位権限識別子部分と少なくとも１つのメンバ識別子部分とに分離するステップ
    をさらに含むことを特徴とする請求項１３に記載のアクセス制御許可を確立する方法。
17. 前記固有識別子は、ＰＵＩＤを含み、前記固有識別子を前記ＳＩＤに変換するステップは、
    前記ＰＵＩＤをＡＰＩに提供するステップと、
    その後、引換えに前記ＳＩＤを前記ＡＰＩから受け取るステップと
    をさらに含むことを特徴とする請求項１４に記載のアクセス制御許可を確立する方法。
18. 前記固有識別子を受け取るステップは、
    ケルベロスベースのメッセージ内部で前記固有識別子を受け取るステップ
    をさらに含むことを特徴とする請求項１２に記載のアクセス制御許可を確立する方法。
19. 前記固有識別子は、前記ケルベロスベースのメッセージ内部のＰＡＣの中で提供されることを特徴とする請求項１８に記載のアクセス制御許可を確立する方法。
20. 少なくとも１つのコンピューティングリソースに対する制御されたアクセスを与えられるべきユーザに関連した、前記ユーザを認証した別のコンピューティングリソースに関連する固有識別子を受け取るステップと、
    前記固有識別子をセキュリティ識別子（ＳＩＤ）に変換するステップと、
    前記ＳＩＤが、前記少なくとも１つのコンピューティングリソースに関連するアクセス制御機構によって提供される少なくとも１つの他のＳＩＤに一致するかどうかを確認するステップと
    を備えた動作を行うためのコンピュータ実行可能命令を有することを特徴とするコンピュータ読み取り可能な記録媒体。
21. 前記固有識別子は、ペアワイズ固有識別子（ＰＵＩＤ）を含むことを特徴とする請求項２０に記載のコンピュータ読み取り可能な記録媒体。
22. 前記ＰＵＩＤは、Ｐａｓｓｐｏｒｔサービスに関連することを特徴とする請求項２１に記載のコンピュータ読み取り可能な記録媒体。
23. 前記固有識別子を前記ＳＩＤに変換するステップは、
    前記ＰＵＩＤを少なくとも１つの下位権限識別子部分と少なくとも１つのメンバ識別子部分とに細分するステップ
    をさらに含むことを特徴とする請求項２２に記載のコンピュータ読み取り可能な記録媒体。
24. 前記固有識別子を前記ＳＩＤに変換するステップは、
    前記ＰＵＩＤをＡＰＩに出力するステップと、
    引換えに、前記ＳＩＤを前記ＡＰＩから受け取るステップと
    をさらに含むことを特徴とする請求項２２に記載のコンピュータ読み取り可能な記録媒体。
25. 前記固有識別子を受け取るステップは、
    前記固有識別子をケルベロスベースのメッセージ内部で受け取るステップ
    をさらに含むことを特徴とする請求項２０に記載のコンピュータ読み取り可能な記録媒体。
26. 前記固有識別子は、前記ケルベロスベースのメッセージ内部のＰＡＣの中で提供されることを特徴とする請求項２５に記載のコンピュータ読み取り可能な記録媒体。
27. 前記ケルベロスベースのメッセージは、Ｓ４Ｕ２ｓｅｌｆプロセスに関連することを特徴とする請求項２５に記載のコンピュータ読み取り可能な記録媒体。
28. 前記ケルベロスベースのメッセージは、Ｓ４Ｕ２ｐｒｏｘｙプロセスに関連することを特徴とする請求項２５に記載のコンピュータ読み取り可能な記録媒体。
29. 前記ＳＩＤが、前記アクセス制御機構によって提供される前記少なくとも１つの他のＳＩＤに一致するかどうかを確認するステップは、
    前記ＳＩＤを、前記少なくとも１つのコンピューティングリソースに関連するアクセス制御リスト（ＡＣＬ）の中の前記少なくとも１つの他のＳＩＤと比較するステップ
    をさらに含むことを特徴とする請求項２０に記載のコンピュータ読み取り可能な記録媒体。
30. 前記少なくとも１つのコンピューティングリソースに対する制御されたアクセスが与えられるべき前記ユーザに関連する前記固有識別子を受け取るステップは、
    前記少なくとも１つのコンピューティングリソースに対するアクセスが与えられるべき前記ユーザに関するデフォルトのアカウントを提供するステップ
    をさらに含むことを特徴とする請求項２０に記載のコンピュータ読み取り可能な記録媒体。
31. 少なくとも１つのコンピューティングリソースに対する少なくとも限られたアクセスが許可されるべき少なくとも１つのユーザに関する少なくとも１つの電子メール（ｅ−ｍａｉｌ）アドレスを受け取るステップと、
    前記電子メールアドレスを、前記電子メールアドレスに基づいて前記ユーザに関連する対応する固有識別子を出力することができる少なくとも１つの信頼されるサービスに出力するステップと、
    前記信頼されるサービスによって出力された前記固有識別子を受け取るステップと、
    前記固有識別子に基づき、前記少なくとも１つのコンピューティングリソースに関連する少なくとも１つのユーザアクセス制御許可を確立するステップと
    を備えた動作を行うためのコンピュータ実行可能命令を有することを特徴とするコンピュータ読み取り可能な記録媒体。
32. 前記固有識別子に基づいて前記ユーザに関する少なくとも１つのユーザアクセス制御許可を設定するステップは、
    前記固有識別子をセキュリティ識別子（ＳＩＤ）に変換するステップと、
    前記ＳＩＤを前記コンピューティングリソースに関する少なくとも１つのアクセス制御リスト（ＡＣＬ）に割り当てるステップと
    をさらに含むことを特徴とする請求項３１に記載のコンピュータ読み取り可能な記録媒体。
33. 前記固有識別子は、ペアワイズ固有識別子（ＰＵＩＤ）を含むことを特徴とする請求項３１に記載のコンピュータ読み取り可能な記録媒体。
34. 前記ＰＵＩＤは、Ｐａｓｓｐｏｒｔサービスに関連することを特徴とする請求項３３に記載のコンピュータ読み取り可能な記録媒体。
35. 前記固有識別子は、ＰＵＩＤを含み、かつ前記固有識別子を前記ＳＩＤに変換するステップは、
    前記ＰＵＩＤを少なくとも１つの下位権限識別子部分と少なくとも１つのメンバ識別子部分とに細分するステップ
    をさらに含むことを特徴とする請求項３４に記載のコンピュータ読み取り可能な記録媒体。
36. 前記固有識別子は、ＰＵＩＤを含み、かつ前記固有識別子を前記ＳＩＤに変換するステップは、
    前記Ｐａｓｓｐｏｒｔの固有識別子をＡＰＩに提供するステップと、
    その後、前記ＳＩＤを前記ＡＰＩから受け取るステップと
    をさらに含むことを特徴とする請求項３４に記載のコンピュータ読み取り可能な記録媒体。
37. 前記固有識別子を受け取るステップは、
    前記固有識別子をケルベロスベースのメッセージ内部で受け取るステップ
    をさらに含むことを特徴とする請求項３１に記載のコンピュータ読み取り可能な記録媒体。
38. 前記固有識別子は、前記ケルベロスベースのメッセージ内部のＰＡＣの中で提供されることを特徴とする請求項３７に記載のコンピュータ読み取り可能な記録媒体。
39. ペアワイズ固有識別子（ＰＵＩＤ）を対応するセキュリティ識別子（ＳＩＤ）に変換する方法であって、
    前記ＰＵＩＤを受け取るステップと、
    前記ＰＵＩＤを少なくとも１つの下位権限識別子部分と少なくとも１つのメンバ識別子部分とに細分するステップと、
    前記少なくとも１つの下位権限識別子部分および前記少なくとも１つのメンバ識別子部分を前記ＳＩＤとして構成するステップと
    を備えたことを特徴とするＰＵＩＤを対応するＳＩＤに変換する方法。
40. 前記少なくとも１つの下位権限識別子部分および前記少なくとも１つのメンバ識別子部分を前記ＳＩＤとして構成するステップは、
    前記下位権限識別子、ＨＩＷＯＲＤ（ＭｅｍｂｅｒＩＤＨｉｇｈ）、ＬＯＷＯＲＤ（ＭｅｍｂｅｒＩＤＨｉｇｈ）、およびＭｅｍｂｅｒＩＤＬｏｗを有するように前記ＳＩＤを構成するステップ
    をさらに含むことを特徴とする請求項３９に記載のＰＵＩＤを対応するＳＩＤに変換する方法。
41. 前記ＳＩＤを出力するステップをさらに備えたことを特徴とする請求項３９に記載のＰＵＩＤを対応するＳＩＤに変換する方法。
42. ペアワイズ固有識別子（ＰＵＩＤ）を受け取るステップと、
    前記ＰＵＩＤを少なくとも１つの下位権限識別子部分と少なくとも１つのメンバ識別子部分とに細分することによって前記ＰＵＩＤを対応するセキュリティ識別子（ＳＩＤ）に変換し、かつ前記少なくとも１つの下位権限識別子部分および前記少なくとも１つのメンバ識別子部分を前記ＳＩＤとして構成するステップとを備えた動作を行うためのコンピュータ実行可能命令を有することを特徴とするコンピュータ読み取り可能な記録媒体。
43. 前記少なくとも１つの下位権限識別子部分および前記少なくとも１つのメンバ識別子部分を前記ＳＩＤとして構成するステップは、
    前記下位権限識別子、ＨＩＷＯＲＤ（ＭｅｍｂｅｒＩＤＨｉｇｈ）、ＬＯＷＯＲＤ（ＭｅｍｂｅｒＩＤＨｉｇｈ）、およびＭｅｍｂｅｒＩＤＬｏｗを有するように前記ＳＩＤを構成するステップ
    をさらに含むことを特徴とする請求項４２に記載のコンピュータ読み取り可能な記録媒体。
44. 前記ＳＩＤを出力するステップをさらに備えたことを特徴とする請求項４２に記載のコンピュータ読み取り可能な記録媒体。
45. 少なくとも１つのコンピューティングリソースに対するアクセスを制御するシステムであって、
    メモリと、
    動作上、前記メモリに結合され、かつ前記少なくとも１つのコンピューティングリソースに対する制御されたアクセスが与えられるべきユーザに関連した、前記ユーザを認証した別のコンピューティングリソースに関連する固有識別子を受け取るように構成可能なロジックであって、動作上、前記固有識別子をセキュリティ識別子（ＳＩＤ）に変換するように構成され、かつ前記ＳＩＤが、前記メモリの中に記憶され前記少なくとも１つのコンピューティングリソースに関連する少なくとも１つの他のＳＩＤに一致する場合、前記ユーザが前記少なくとも１つのコンピューティングリソースにアクセスすることを可能にするロジックと
    を備えたことを特徴とするアクセスを制御するシステム。
46. 前記固有識別子は、ペアワイズ固有識別子（ＰＵＩＤ）を含むことを特徴とする請求項４５に記載のアクセスを制御するシステム。
47. 前記ＰＵＩＤは、Ｐａｓｓｐｏｒｔサービスに関連することを特徴とする請求項４６に記載のアクセスを制御するシステム。
48. 前記論理は、前記Ｐａｓｓｐｏｒｔの固有識別子を少なくとも１つの下位権限識別子部分と少なくとも１つのメンバ識別子部分とに分離するようにさらに構成されることを特徴とする請求項４７に記載のアクセスを制御するシステム。
49. 前記ロジックは、ケルベロスベースのメッセージ内部で前記固有識別子を受け取るように構成可能であることを特徴とする請求項４５に記載のアクセスを制御するシステム。
50. 前記固有識別子は、前記ケルベロスベースのメッセージ内部のＰＡＣの中で提供されることを特徴とする請求項４９に記載のアクセスを制御するシステム。
51. 前記ケルベロスベースのメッセージは、Ｓ４Ｕ２ｓｅｌｆプロセスに関連することを特徴とする請求項４９に記載のアクセスを制御するシステム。
52. 前記ケルベロスベースのメッセージは、Ｓ４Ｕ２ｐｒｏｘｙプロセスに関連することを特徴とする請求項５０に記載のアクセスを制御するシステム。
53. 前記メモリの中に記憶された前記少なくとも１つの他のＳＩＤは、前記少なくとも１つのコンピューティングリソースに関連するアクセス制御リスト（ＡＣＬ）の一部であることを特徴とする請求項４５に記載のアクセスを制御するシステム。
54. 前記ロジックは、前記少なくとも１つのコンピューティングリソースに対するアクセス制御が与えられるべき前記ユーザに匿名アカウント機能を提供するようにさらに構成可能であることを特徴とする請求項４５に記載のアクセスを制御するシステム。
55. 少なくとも１つのコンピューティングリソースに関するアクセス制御許可を設定するシステムであって、
    通信ネットワークと、
    動作上、前記ネットワークに結合され、かつ前記少なくとも１つのコンピューティングリソースに対する少なくとも限られたアクセスが許可されるべき少なくとも１つのユーザに関する少なくとも１つの電子メール（ｅ−ｍａｉｌ）アドレスを受け入れ、前記電子メールアドレスを前記ネットワークに提供し、その後、前記ネットワークを介して前記電子メールアドレスに関連する対応する固有識別子を受け取り、前記受け取られた固有識別子に基づき、前記ユーザに関して前記少なくとも１つのコンピューティングリソースに関連する少なくとも１つのアクセス制御許可を設定するように構成可能な第１のデバイスと
    を備えたことを特徴とするアクセス制御許可を設定するシステム。
56. 動作上、前記ネットワークに結合され、かつ前記ネットワークから前記少なくとも１つの電子メールアドレスを受け取ることができる少なくとも１つの信頼に値するサービスを提供し、前記電子メールアドレスを前記固有識別子に変換し、前記固有識別子を前記ネットワークに出力するように構成された少なくとも１つの他のデバイス
    をさらに備えたことを特徴とする請求項５５に記載のアクセス制御許可を設定するシステム。
57. 前記第１のデバイスは、前記固有識別子をセキュリティ識別子（ＳＩＤ）に変換し、前記ＳＩＤを前記少なくとも１つのコンピューティングリソースに関する少なくとも１つのアクセス制御リスト（ＡＣＬ）に関連付けるようにさらに構成されることを特徴とする請求項５６に記載のアクセス制御許可を設定するシステム。
58. 前記固有識別子は、ペアワイズ固有識別子（ＰＵＩＤ）を含むことを特徴とする請求項５７に記載のアクセス制御許可を設定するシステム。
59. 前記ＰＵＩＤは、Ｐａｓｓｐｏｒｔの固有識別子であることを特徴とする請求項５８に記載のアクセス制御許可を設定するシステム。
60. 前記第１のデバイスは、対応するＳＩＤへの変換の最中に、前記Ｐａｓｓｏｒｔの固有識別子を少なくとも１つの下位権限識別子部分と少なくとも１つのメンバ識別子部分とに分離するようにさらに構成されることを特徴とする請求項５９に記載のアクセス制御許可を設定するシステム。
61. 前記第１のデバイスは、ケルベロスベースのメッセージ内部で前記固有識別子を受け取るように構成されることを特徴とする請求項５５に記載のアクセス制御許可を設定するシステム。
62. 前記固有識別子は、前記ケルベロスベースのメッセージ内部のＰＡＣの中で提供されることを特徴とする請求項６１に記載のアクセス制御許可を設定するシステム。

Images