JP4298969B2 - 認証信用証明書の委任の有効範囲を制御するための方法とシステム - Google Patents
認証信用証明書の委任の有効範囲を制御するための方法とシステム Download PDFInfo
- Publication number
- JP4298969B2 JP4298969B2 JP2002180423A JP2002180423A JP4298969B2 JP 4298969 B2 JP4298969 B2 JP 4298969B2 JP 2002180423 A JP2002180423 A JP 2002180423A JP 2002180423 A JP2002180423 A JP 2002180423A JP 4298969 B2 JP4298969 B2 JP 4298969B2
- Authority
- JP
- Japan
- Prior art keywords
- server
- service
- client
- credential
- trusted
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/33—User authentication using certificates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2115—Third party
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computing Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Storage Device Security (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Collating Specific Patterns (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、一般的には、コンピュータアクセス制御に関し、さらに具体的には、認証信用証明書の委任の有効範囲を制御するための方法とシステムに関する。
【０００２】
【従来の技術】
アクセス制御は、コンピュータセキュリティにとって非常に重要である。コンピュータシステムの完全性 (integrity) と重要データの機密性を保護するために、無許可ユーザや悪意の攻撃者がコンピュータリソースへのアクセス権を取得するのを防止するための種々のアクセス制御方式が実現されている。
【０００３】
コンピュータセキュリティの包括性を保証するために、アクセス制御は、種々のレベルで実現されていることが多い。例えば、あるコンピュータのレベルでは、ユーザは、ログオンプロシージャ (logon procedure) に入ることを要求され、そこで、コンピュータは、ユーザがコンピュータを使用する権限をもっているかどうかを判断しているのが代表的である。さらに、コンピュータネットワークのレベルでは、ユーザによる種々のネットワークサービスへのアクセスを制御する目的で、ユーザは、ユーザ認証プロセスに入ることを要求されているのが普通である。ネットワークアクセス制御サーバがユーザを認証したあとでも、ユーザは、そのサービスにアクセするためには、特定サーバの許可を要求する必要がある。ユーザ認証 (user authentication) によってネットワークアクセス制御を制御するために、ケルベロス５ (Kerberos 5) プロトコルのような、異種のプロトコルをベースとする種々の方式が提案され、実現されている。
【０００４】
一般的に、コンピュータに対するユーザログオンとネットワークアクセス制御のためのユーザ認証は、別々のプロシージャになっている。それにもかかわらず、異種のアクセス制御方式を扱うときのユーザの負担を最小限にするために、ユーザログオンとネットワークアクセスのためのユーザ認証は、一緒に実行されることが時々ある。例えば、ユーザ認証がケルベロスプロトコルに基づいて実現されている場合には、ユーザがコンピュータにログオンしたとき、コンピュータは、ケルベロス認証プロセスを開始することも可能になっている。この認証プロセスでは、コンピュータはケルベロス鍵配信センタ (Key Distribution Center - KDC) に連絡し、最初に、ユーザのためのチケット認可チケット (ticket granting ticket - TGT) を取得している。そのあと、コンピュータはそのTGT を使用して、自身のためのセッションチケットを鍵配信センタ (KDC)から取得することが可能になっている。
【０００５】
ネットワークが発達するのに伴い、サーバ/サービスコンピュータは、クライアントコンピュータからの要求を処理するために複数の層に構成される傾向がある。単純な例として、World Wide Web（ワールドワイドウェブ）のWebサイトに対する要求をインターネット (the Internet) を通して行うクライアントコンピュータがある。この例では、要求のフォーマッティングおよび関連ビジネスルールを処理するフロントエンドWebサーバと、Webサイトのためのデータベースを管理するバックエンドサーバが存在している。セキュリティを強化するために、Webサイトは、認証プロトコル (authentication protocol) が、例えば、ユーザのTGTなどの信用証明書 (credential) および/または、可能ならば、他の情報をフロントエンドサーバからバックエンドサーバに転送（または委任 (delegate)）するような構成になっている場合がある。このようなやり方は、多くのWebサイトおよび/または他の多層 (multiple-tiered) ネットワークでは、ますます普及化されている。
【０００６】
従って、ユーザのTGTと関連認証符号を保持するサーバ/コンピュータ(authenticator) は、ユーザ/クライアントに代わって鍵配信センタ (KDC)にチケットを要求することが可能になっている。この機能は、現在では、転送されるチケット委任を行うために使用されている。残念ながら、このようなサーバへの委任は、基本的には、TGTが存続する間、無拘束 (unconstrained) になっている。その結果として、複合ネットワーク構成で、しかし、もっと拘束された形で、認証信用証明書 (authentication credential) の委任をサポートする改良方法とシステムが要望されている。
【０００７】
【発明が解決しようとする課題】
本発明は、上述の点に鑑みて、認証信用証明書 (authentication credential)の委任を拘束された形で行う改良方法とシステムを提供することを解決すべき課題にしている。
【０００８】
【課題を解決するための手段】
上述した要望および他の要望は、例えば、クライアントに代わってアクセスしようとしているターゲットサービスを特定し、サーバによって使用される新たなサービス信用証明書を、サーバから信頼できる第三者機関 (trusted third party) に要求させる本発明による方法によって達成される。この要求を行うために、サーバは、サーバを認証する信用証明書、ターゲットサービスに関する情報、およびクライアントによって、あるいはクライアントに代わってサーバによって以前に取得されたサービス信用証明書を信頼できる第三者機関に提供する。この方法によれば、新たなサービス信用証明書は、サーバのIDではなく、クライアントのIDで発行されるが、これは、サーバだけによって使用されて、ターゲットサービスへのアクセス権が得られるようにしている。
【０００９】
本発明の種々の方法とシステムの理解を容易にするために、以下では、添付図面を参照して詳しく説明されている。
【００１０】
【発明の実施の形態】
図面を参照して説明すると、本発明は、適当なコンピューティング環境で実現されるものとして示されている。なお、図面において、同様のエレメントは同様の参照符号を付けて示されている。必ずしもその必要はないが、本発明は、プログラムモジュールのように、パーソナルコンピュータによって実行されるコンピュータ実行可能命令の広い意味で説明されている。一般的に、プログラムモジュールとしては、特定のタスクを実行し、あるいは特定の抽象データ型を実装しているルーチン、プログラム、オブジェクト、コンポーネント、データ構造などがある。さらに、この分野の精通者ならば理解されるように、本発明は、他のコンピュータシステム構成で実施することも可能であり、その中には、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルコンシューマエレクトロニクス、ネットワークPC、ミニコンピュータ、メインフレームコンピュータなどが含まれている。また、本発明は、分散型コンピューティング環境で実施することも可能であり、そこでは、タスクは、通信ネットワークを通してリンクされたリモート処理デバイスによって実行されている。分散型コンピューティング環境では、プログラムモジュールは、ローカルとリモートの両方のメモリストレージデバイスに置いておくことができる。
【００１１】
図１は、以下に説明されている方法とシステムを実現することが可能である、適当なコンピューティング環境１２０の例を示す図である。
【００１２】
例示のコンピューティング環境１２０は、適当なコンピューティング環境の一例にすぎず、本明細書で説明している改良方法とシステムの使用または機能の有効範囲に関して、なんらの制限を意味するものではない。また、コンピューティング環境１２０は、このコンピューティング環境１２０に図示されているコンポーネントのどれとも、あるいはどの組み合わせとも、なんらかの依存関係または要件があるものと解釈してはならない。
【００１３】
ここに説明されている改良方法とシステムは、多数の、他の汎用または特殊目的コンピューティングシステム環境または構成で動作可能である。適当と考えられる、周知のコンピューティングシステム、環境、および/または構成の例としては、パーソナルコンピュータ、サーバコンピュータ、小型軽量 (thin) クライアント、大型重量 (thick) クライアント、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス (set top box)、プログラマブルコンシューマエレクトロニクス、ネットワークPC、ミニコンピュータ、メインフレームコンピュータ、上述したシステムまたはデバイスのいずれかを含んでいる分散型コンピューティング環境などがあるが、これらに限定されるものではない。
【００１４】
図１に示すように、コンピューティング環境１２０は、パーソナルコンピュータ１３０の形体をした汎用コンピューティングデバイスを含んでいる。コンピュータ１３０のコンポーネントとしては、１つまたは２つ以上のプロセッサまたは処理ユニット１３２、システムメモリ１３４、およびシステムメモリ１３４を含む種々のシステムコンポーネントをプロセッサ１３２に結合しているバス１２３がある。
【００１５】
バス１３６は、数種タイプのバス構造の１つまたは２つ以上を表しており、その中には、種々のバスアーキテクチャのいずれかを採用したメモリバスまたはメモリコントローラ、ペリフェラル（周辺）バス、高速グラフィックスポート、およびプロセッサまたはローカルバスが含まれている。このようなアーキテクチャの例としては、Industry Standard Architecture（ISA−業界標準アーキテクチャ）バス、Micro Channel Architecture（MCA −マイクロチャネルアーキテクチャ）バス、Enhanced ISA（EISA−拡張ISA）バス、Video Electronics Standards Association（VESA−ビデオエレクトロニクス標準協会）ローカルバス、およびMezzanine（メザニン：中二階）バスとも呼ばれているPeripheral Component Interconnects（PCI−ペリフェラルコンポーネント相互接続）バスがあるが、これらに限定されない。
【００１６】
コンピュータ１３０は、種々のコンピュータ読取可能媒体を装備しているのが代表的である。そのような媒体としては、コンピュータ１３０によってアクセス可能な媒体であれば、どのような媒体も利用可能であり、その中には、揮発性媒体と不揮発性媒体、取り外し可能媒体と取り外し不能媒体が含まれている。
【００１７】
図１に示すように、システムメモリ１３４には、ランダムアクセスメモリ (random access memory - RAM) １４０のような揮発性メモリ、および/またはリードオンリメモリ (read only memory - ROM) １３８のような不揮発性メモリの形体をしたコンピュータ読取可能媒体が含まれている。スタートアップ時のときのように、コンピュータ１３０内のエレメント間で情報を転送するのを支援する基本ルーチンで構成された基本入出力システム (basic input/output system - BIOS) １４２は、ROM １３８に格納されている。RAM １４０には、プロセッサ１３２が即時にアクセス可能である、および/またはプロセッサ１３２によって現在操作の対象になっているデータおよび/またはプログラムモジュールが置かれているのが代表的である。
【００１８】
コンピュータ１３０は、さらに、他の取り外し可能/取り外し不能の揮発性/不揮発性コンピュータストレージ媒体を装備している場合もある。例えば、図１は、取り外し不能の不揮発性磁気媒体（図示していないが、「ハードディスク」と呼ばれているのが代表的）との間で読み書きを行うハードディスクドライブ１４４、取り外し可能の、不揮発性磁気ディスク１４８との間で読み書きを行う磁気ディスクドライブ１４６（例えば、「フロッピー（登録商標）ディスク」）、およびCD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAMまたは他の光媒体などの、取り外し可能の不揮発性光ディスク１５２との間で読み書きを行う光ディスクドライブ１５０を示している。ハードディスクドライブ１４４、磁気ディスクドライブ１４６および光ディスクドライブ１５０は、それぞれ、１つまたは２つ以上のインタフェース１５４によってバス１３６に接続されている。
【００１９】
これらのドライブとそれぞれに関連するコンピュータ読取可能媒体は、不揮発性ストレージとしてコンピュータ読取可能命令、データ構造、プログラムモジュールおよび他のデータをコンピュータ１３０のために格納している。ここで説明している例示環境では、ハードディスク、取り外し可能磁気ディスク１４８、および取り外し可能光ディスク１５２が採用されているが、この分野の精通者ならば当然に理解されるように、コンピュータによってアクセス可能であるデータを格納して置くことができる、他のタイプのコンピュータ読取可能媒体を例示動作環境で採用することも可能である。そのような他のタイプの媒体としては、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ランダムアクセスメモリ (RAM)、リードオンリメモリ (ROM) などがある。
【００２０】
いくつかのプログラムモジュールは、ハードディスク、磁気ディスク１４８、光ディスク１５２、ROM １３８またはRAM １４０に格納しておくことが可能であり、そのようなものとして、オペレーティングシステム１５８、１つまたは２つ以上のアプリケーションプログラム１６０、他のプログラムモジュール１６２、およびプログラムデータ１６４がある。
【００２１】
ここで説明している改良方法とシステムは、オペレーティングシステム１５８、１つまたは２つ以上のアプリケーションプログラム１６０、他のプログラムモジュール１６２、および/またはプログラムデータ１６４内で実現することが可能である。
【００２２】
ユーザは、キーボード１６６やポインティングデバイス１６８（「マウス」など）などの、入力デバイスを通してコマンドと情報をコンピュータ１２０に与えることができる。他の入力デバイス（図示せず）としては、マイクロホン、ジョイスティック、ゲームパッド、サテライトディッシュ、シリアルポート、スキャナ、カメラなどがある。上記および他の入力デバイスは、バス１３６に結合されたユーザ入力インタフェース１７０を通して処理ユニット１３２に接続されているが、パラレルポートやゲームポート、ユニバーサルシリアルバス (universal serial bus - USB) などの、他のインタフェースで接続することも可能である。
【００２３】
モニタ１７２や他のタイプのディスプレイデバイスも、ビデオアダプタ１７４などのインタフェースを介してバス１３６に接続されている。モニタ１７２のほかに、パーソナルコンピュータは、スピーカやプリンタなどの他のペリフェラル（周辺）出力デバイス（図示せず）を装備しているのが代表的であり、これらのデバイスは、出力周辺インタフェース１７５を通して接続可能になっている。
【００２４】
コンピュータ１３０は、リモートコンピュータ１８２などの、１つまたは２つ以上のリモートコンピュータとの論理コネクションを使用するネットワーキング環境で動作することができる。リモートコンピュータ１８２は、パーソナルコンピュータ１３０に関して上述したエレメントの多くまたは全部を装備していることがある。
【００２５】
図１に示す論理コネクションとしては、ローカルエリアネットワーク (local area network - LAN) １７７と広域ネットワーク (wide area network - WAN) １７９がある。このようなネットワーキング環境は、オフィス、企業内 (enterprise-wide) コンピュータネットワーク、イントラネット (intranet)、およびインターネット (the Internet) で普及している。
【００２６】
LANネットワーキング環境で使用されるときは、コンピュータ１３０は、ネットワークインタフェースまたはアダプタ１８６を通してLAN １７７に接続されている。WANネットワーキング環境で使用されるときは、コンピュータは、WAN １７９上のコミュニケーションを確立するためのモデム１７８や他の手段を装備しているのが代表的である。モデム１７８は内蔵型と外付け型があるが、どちらも、ユーザ入力インタフェース１４６や他の該当メカニズムを介してシステムバス１３６に接続することが可能になっている。
【００２７】
図１に示されているのは、インターネットを通したWANの具体的構築例である。そこでは、コンピュータ１３０は、インターネット１８０を経由して少なくとも１つのリモートコンピュータ１８２とのコミュニケーションを確立するためにモデム１７８を採用している。
【００２８】
ネットワーキング環境では、コンピュータ１３０に関して上述したプログラムモジュールまたはその一部は、リモートメモリストレージデバイスに置いておくことが可能である。従って、例えば、図１に示すように、リモートアプリケーションプログラム１８９は、リモートコンピュータ１８２のメモリデバイスに置いておくことができる。当然に理解されるように、図示し、説明してきたネットワークコネクションは例示であり、コンピュータ間の通信リンクを確立する他の手段を使用することも可能である。
【００２９】
以下では、クライアント−サーバのネットワーク環境において認証信用証明書(authentication credential) の委任の有効範囲 (scope of delegation) を制御するための、本発明のいくつかの態様を中心に説明することにする。以下では、例示のケルベロスベース (Kerberos-based) のシステムとその改良を中心に説明されているが、本発明の種々の方法とシステムは、明らかであるように、他の認証システムと手法にも適用可能である。例えば、証明書ベース (certificate-based) の認証システムと手法を、本発明のいくつかの側面に適応させることが可能である。
【００３０】
上述したように、クライアントのチケット認可チケット (ticket granting ticket - TGT) と関連認証符号 (authenticator) を保持すると、保持者は、クライアントに代わってチケットを信頼できる第三者機関 (trusted third-party)、例えば、鍵配信センタ (key distribution center - KDC) に要求することができる。この無拘束委任 (unconstrained delegation) は、現在、転送チケット委任方式 (forwarded ticket delegation schemes) を採用している、ある種のケルベロス実装でサポートされている。
【００３１】
本発明によれば、以上のことを念頭に置いて、委任プロセスを拘束し、あるいはその制御を改善する方法とシステムが提供されている。これらの方法とシステムは、異種の認証プロトコルで使用すること可能になっている。いくつかの例示実施形態では、この委任プロセスは、サービス・フォー・ユーザ・トゥ・プロキシー（service-for-user-to-proxy ）(S4U2proxy) 手法を通して制御されている。このS4U2proxy（委任）手法は、好ましくは、例えば、フロントエンドサーバ/サービスのような、サーバまたはサービスがクライアントに代わってサービスチケットを要求し、他のサーバ/サービスで使用されるようにするプロトコルとして実現されている。以下で詳しく説明するように、S4U2proxyプロトコルによると、拘束された委任 (constrained delegation) が制御された形で行われるので、クライアントはTGTをフロントエンドサーバに転送しないで済むという利点が得られる。
【００３２】
ここに開示されているもう１つの手法は、サービス・フォー・ユーザ・トゥ・セルフ（service-for-user-to-self） (S4U2self) 手法である。このS4U2self（自身）手法またはプロトコルによると、ユーザは自身のためにサービスチケットを要求することができるが、クライアントのIDは、その結果として得られたサービスチケットの中に入っている。このようにすると、例えば、クライアントは、他の認証プロトコルによって認証されているので、基本的にサービスチケットを得ることができ、そのサービスチケットをS4U2proxyプロトコルで使用すると、拘束委任が得られることになる。S4U2proxy手法には、２つの例示形式がある。すなわち、「無証拠(no evidence)」形式と「証拠(evidence)」形式である。無証拠形式では、サーバは、例えば、そのサーバに専用されている別のセキュリティ/認証メカニズムを使用して、例えば、クライアントを認証するものと信用されている。証拠形式では、鍵配信センタ (KDC)（または信頼できる第三者機関）は、クライアントに関して用意されていて、クライアントがサーバに対して認証をしたとき得られる情報（証拠）に基づいて認証を行っている。
【００３３】
本明細書に開示されている方法とシステムによると、クライアントは、そのクライアントがケルベロス認証プロトコルによって認証されたか、他のなんらかの認証プロトコルによって認証されたかに関係なく、ケルベロス環境内でサーバ/サービスにアクセスすることができる。その結果、バックエンドおよび/または他のサーバ/サービスは、基本的にケルベロスのみの環境で動作させることが可能になっている。
【００３４】
次に、図２のブロック図を参照して説明すると、図２は、本発明のいくつかの例示実施形態によるクライアント−サーバ環境２００内のS4U2proxyプロトコル/プロセスを示している。
【００３５】
図示のように、クライアント２０２は、信頼できる第三者機関２０４に動作状態で結合され、信頼できる第三者機関は、認証サービス２０６、例えば、鍵配信センタ (KDC)、認証交付機関 (certificate granting authority −証明書発行局とも呼ばれる)、ドメインコントローラなどが動作状態で置かれている構成になっている。認証サービス２０６は、データベース２０８に保存されている情報にアクセスするように構成されている。クライアント２０２と信頼できる第三者機関２０４は、さらに、サーバ、つまり、サーバA ２１０に動作状態で結合されている。なお、本明細書で用いられている「サーバ」と「サービス」という用語は、同一または類似機能を表すために同じ意味で用いられている。
【００３６】
この例では、サーバA ２１０は、複数の他のサーバに対してフロントエンドサーバになっている。従って、図示のように、サーバA ２１０は、サーバB ２１２とサーバC ２１４に動作状態で結合されている。図示のように、サーバB ２１２は、複製サービス (replicated service) にすることができる。また、サーバC ２１４は、さらに、サーバD ２１６に動作状態で結合されている。
【００３７】
ユーザがクライアント２０２でログオンすると、認証要求 (AS_REQ) メッセージ２２０が認証サービス２０６に送信され、これに対する応答として、認証サービス２０６は、認証応答 (AS_REP) メッセージ２２２を返送する。AS_REPメッセージ２２２には、ユーザ/クライアントに関連するTGTが入っている。サーバA ２１０も、同じまたは類似プロシージャ（図示せず）に従って認証される。
【００３８】
クライアント２０２がサーバA ２１０にアクセスしたいときは、クライアントは、チケット認可サービス要求 (TGS_REQ) メッセージ２２４を認証サービス２０６に送信し、認証サービス２０６からは、チケット認可サービス応答 (TGS_REP) メッセージ２２６が返送される。このTGS_REPメッセージ２２６には、クライアント２０２とサーバA ２１０に関連するサービスチケットが入っている。そのあと、通信セッションを開始するために、クライアント２０２は、アプリケーションプロトコル要求 (AP_REQ) メッセージ２２８の中で、そのサービスチケットをサーバA ２１０に転送する。これらのプロセス/プロシージャは周知であるので、ここで詳しく説明することは省略する。
【００３９】
従来では、委任をサポートするために、クライアントはサーバA ２１０にクライアントのTGTを提供して、サーバA ２１０がクライアント２０２に代わって追加のサービスチケットを要求できるようにする必要があった。いまでは、その必要がなくなった。その代わりに、サーバA ２１０がクライアント２０２に代わって別のサーバ、例えば、サーバC ２１４にアクセスする必要があるときは、サーバA ２１０と認証サービス２０６は、S4U2proxyプロトコルに従って動作している。
【００４０】
従って、例えば、S4U2proxyプロトコルを実装している、いくつかの例示実施形態によれば、サーバA ２１０は、TGS_REQメッセージ２３０を認証サービス２０６に送信している。このTGS_REQメッセージ２３０は、サーバA ２１０のためのTGTとクライアント２０２から受信したサービスチケットを含んでおり、クライアント２０２がアクセスしようとしている望みの、またはターゲットとしているサーバ/サービス、例えば、サーバC ２１４を示している。例えば、ケルベロスでは、拡張可能データフィールドが定義されており、これは、「追加チケット」フィールドと呼ばれているのが代表的である。この追加チケットフィールドは、クライアント２０２から受信したサービスチケットを伝達するためにS4U2proxyプロトコルで使用することができ、また、クライアントIDを与えるために使用されるチケットを得るために、受信側鍵配信センタ (KDC)にこの追加チケットフィールドを調べるように指示するフラグまたは他のインジケータは、鍵配信センタ (KDC)オプションフィールドで指定することが可能になっている。この分野の精通者ならば理解されるように、これらのフィールドまたは他のフィールドおよび/またはデータ構造は、必要な情報を認証サーバ２０６に伝達するために使用することが可能である。
【００４１】
TGS_REQ ２３０を処理するとき、認証サービス２０６は、クライアント２０２が委任を許可していたかどうかを、例えば、クライアント２０２によって設定された「転送可能(forwardable)フラグ」の値に基づいて判断する。従って、クライアントによる委任は、この転送可能フラグがクライアントのサービスチケットの中に存在すると強制される。クライアント２０２が委任に関与することを望んでいなければ、チケットには、転送可能フラグが付けられない。認証サービス２０６は、このフラグをクライアントによる制限として尊重する。
【００４２】
他の実施形態では、認証サービス２０６は、サーバA ２１０がクライアント２０２に対して、どのサービスに委任することが許されているか（または委任することが許されていないか）を定義している追加情報を、データベース２０８からアクセスすることが可能になっている。
【００４３】
サーバA ２１０がターゲットとしているサーバ/サービスに委任することを許されていないと認証サービス２０６が判断したときは、TGS_REPメッセージ２３２がサーバA ２１０に送信される。このTGS_REPメッセージ２３２には、ターゲットとするサーバ/サービスのためのサービスチケットが含まれている。このサービスチケットは、クライアント２０２が、例えば、クライアントのTGTを使用して認証サービス２０６から直接にサービスチケットを要求したかのようになっている。しかし、実際はそうではない。その代わりに、認証サービス２０６は、認証されたサーバA ２１０がクライアント２０２から受信し、TGS_REQメッセージ２３０に入っているサービスチケットに基づく要求に、認証されたクライアントが基本的に関与していると納得したあとで、類似の/必要なクライアント情報をデータベース２０８からアクセスしている。しかし、クライアント情報はクライアントチケットに入って伝達されるので、サーバは、そのチケットからデータをコピーするだけで済むことになる。従って、データベース２０８を使用することができるが、チケットに入っているデータをコピーした方が効率的である。
【００４４】
いくつかの実施形態では、例えば、TGS_REPメッセージ２３２は、ターゲットとしているサーバ/サービスとクライアント２０２を示しているが、さらに、実装時固有ID/ユーザ/クライアントアカウントデータを、例えば、特権属性証明書 (privilege attribute certificate - PAC)、セキュリティID、Unix（登録商標）ID、Passport ID、証明書などの形で含んでいる。例えば、PACは、認証サービス２０６によって生成することができるが、TGS_REQメッセージ２３０に入っていたクライアントのサービスチケットからコピーするだけで済むこともある。
【００４５】
PACまたは他のユーザ/クライアントアカウントデータは、委任の有効範囲 (scope of delegation) に関する情報を含むように構成することも可能である。従って、例えば、図５に示すように、ケルベロスメッセージ４００には、ヘッダ４０２とPAC ４０４を収めている部分がある。そこでは、PAC ４０４は、委任情報４０６を含んでいる。図示のように、委任情報４０６は、複合ID情報 (compound identity information) ４０８とアクセス制限情報 (access restriction information) ４１０を含んでいる。
【００４６】
複合ID情報４０８の例としては、例えば、サーバA ２１０がユーザ/クライアント２０２に代わってサービスチケットを要求したことを示す表示（indication）のように、委任プロセスに関する記録情報がある。そこでは、複数の記録情報を得ることができるので、１つのストリングにしたり、あるいは複数の委任プロセスにわたるヒストリ（活動記録）を示したりするために使用することができる。この情報は、監査 (audit) 目的および/またはアクセス制御目的に使用すると便利である。
【００４７】
アクセス制限情報４１０は、例えば、アクセス制御メカニズムと関連付けて使用すると、クライアント２０２が直接的に、またはサーバA ２１０を通して間接的にサーバ/サービスにアクセスしようとした場合は、ある種のサーバ/サービスへのアクセスを許可し、サーバ/サービスがサーバB ２１２を通して間接的に求められる場合は、アクセスを許可しない、といったようにアクセスを選択的に制御することができる。この機能によると、認証信用証明書の委任に対する制御が強化されることになる。
【００４８】
上記の例では、クライアント２０２は、認証サーバ２０６によって認証されていた。しかし、当然に理解されるように、他のクライアントはそのように認証されない場合がある。そのような場合の例を示したのが、図３である。そこでは、クライアント３０２は、異なる認証プロトコルメカニズム３０３を使用して認証されている。認証プロトコルメカニズム３０３の例としては、Passport、セキュアソケットレイヤ (secure sockets layer - SSL)、NTLM、Digest、またはその他の類似認証プロトコル/プロシージャがある。なお、この例では、クライアント３０２は、ターゲットとするサービスにアクセスすることを選択したが、そのサービスがサーバC ２１４によって提供されるのは、偶然にすぎないものと想定されている。この選択は、上述したS4U2proxyプロトコルを使用すると満たすことができるが、それができるのは、サーバA ２１０がS4U2proxyプロトコル/プロシージャを完了/に従った後だけである。
【００４９】
S4U2selfプロトコルには、１つの基本的前提がある。つまり、サーバ、例えば、サーバA ２１０が、サーバにアクセスしようとしていて、サーバが自身で認証したユーザ/クライアントのために、自身に対するサービスチケットを要求できることを前提としている。ここで説明している例示のS4U2selfプロトコルは、認証「証拠」をもっているクライアントおよびそのような認証証拠をもたないクライアントをサポートするように構成されている。
【００５０】
認証サービス２０６によって評価できる認証証拠がないときは、サーバA ２１０は、クライアント３０２を「信用」する必要がある。従って、例えば、サーバA ２１０が有効性検査できる認証証明書または類似のメカニズム３０４をクライアント３０２がもっていれば、そのクライアント３０２は、「信用」されているものと判断することができる。ここでは、クライアント３０２は、基本的には、サーバA ２１０によって認証されている。次に、サーバA ２１０は、TGS_REQメッセージ３０６を認証サービス２０６に送信し、クライアント３０２のために自身に対するサービスチケットを要求する。その応答として、認証サービス２０６は、要求されたサービスチケットを含んでいるTGS_REPメッセージ３０８を生成する。そのサービスチケットが受信されると、これは、クライアント３０２のためにサーバC ２１４に対するサービスチケットを要求するために、後続のS4U2proxyプロトコル/プロシージャで使用される。いくつかのケルベロス実装例では、そのためには、TGS_REPメッセージ３０８の中の転送可能フラグは、サービスチケットの転送を可能にするようにセットされている必要がある。信頼できる第三者機関は、クライアント３０２のためにPACを作成することもできるので、これは、結果として得られたサービスチケットに組み入れておくことができる。
【００５１】
認証の証拠がクライアント３０２’に対して存在しないときは、サーバA ２１０は、その証拠を追加の事前認証データとしてTGS_REQメッセージ３１２に組み入れることができる。このことは、図４の環境３００'に示されている。そこでは、証拠情報３１０は、クライアント３０２’からサーバA ２１０に与えられている。証拠情報３１０の例としては、チャレンジ/応答ダイアログのほかに、別の「信用」エンティティによって生成される情報がある。証拠情報３１０を受信し、そのあとに続いて有効性検査が行われると、認証サービス２０６は、要求されたサービスチケットをサーバA ２１０自身に発行する。なお、いくつかの実施形態では、証拠を使用すると、サーバはクライアントのために、制限されたTGTを取得することが可能になる。
【００５２】
いくつかのケルベロス実装では、TGS_REPメッセージ３１４の中の転送可能フラグは、サービスチケットの転送を可能にするようにセットされる。PACがTGS_REQメッセージ３１２に入っていれば、これは、サービスチケットの中で使用することが可能であり、そうでなければ、PACは、証拠情報３１０に基づいて認証サービス２０６（この例では、鍵配信センタ (KDC)）によって生成することができる。例えば、S4U2selfでは、クライアントのIDは、事前認証データに組み込まれている。このIDは、クライアントのためにPACを構築するときに使用して、（クライアントのために）サーバに対する発行サービスチケットに追加することができる。
【００５３】
以上、本発明の種々の方法とシステムの、いくつかの好ましい実施形態を添付図面に図示し、詳細な説明の中で説明してきたが、当然に理解されるように、本発明は上述してきた例示実施形態に限定されるものではなく、各請求項に記載され、明確化されている本発明の精神から逸脱しない限り、数多くの再構成、変更、および置換を行うことが可能である。
【図面の簡単な説明】
【図１】本発明を実現することができる例示コンピュータシステムを示すブロック図である。
【図２】本発明のいくつかの例示実施形態に従って、クライアント−サーバ環境内で実行されるservice-for-user-to-proxy (S4U2proxy) プロセスを示すブロック図である。
【図３】本発明のいくつかの例示実施形態に従って、クライアント−サーバ環境内で実行されるservice-for-user-to-self (S4U2self) プロセスを示すブロック図である。
【図４】本発明のいくつかの、別の例示実施形態に従って、クライアント−サーバ環境内で実行されるservice-for-user-to-self (S4U2self) プロセスを示すブロック図である。
【図５】本発明のいくつかの実施形態で使用するのに適したメッセージフォーマットの一部を選択して示す概略図である。
【符号の説明】
２００ クライアント−サーバ環境
２０２ クライアント
２０４ 信頼できる第三者機関
２０６ 認証サービス
２０８ データベース
２１０ サーバＡ
２１２ サーバＢ
２１４ サーバＣ
２１６ サーバＤ
２２０ 認証要求 (AS_REQ) メッセージ
２２２ 認証応答 (AS_REP) メッセージ
２２４ チケット認可サービス要求 (TGS_REQ) メッセージ
２２６ チケット認可サービス応答 (TGS_REP) メッセージ
２２８ アプリケーションプロトコル要求 (AP_REQ) メッセージ
２３０ TGS_REQメッセージ
２３２ TGS_REPメッセージ
【発明の属する技術分野】
本発明は、一般的には、コンピュータアクセス制御に関し、さらに具体的には、認証信用証明書の委任の有効範囲を制御するための方法とシステムに関する。
【０００２】
【従来の技術】
アクセス制御は、コンピュータセキュリティにとって非常に重要である。コンピュータシステムの完全性 (integrity) と重要データの機密性を保護するために、無許可ユーザや悪意の攻撃者がコンピュータリソースへのアクセス権を取得するのを防止するための種々のアクセス制御方式が実現されている。
【０００３】
コンピュータセキュリティの包括性を保証するために、アクセス制御は、種々のレベルで実現されていることが多い。例えば、あるコンピュータのレベルでは、ユーザは、ログオンプロシージャ (logon procedure) に入ることを要求され、そこで、コンピュータは、ユーザがコンピュータを使用する権限をもっているかどうかを判断しているのが代表的である。さらに、コンピュータネットワークのレベルでは、ユーザによる種々のネットワークサービスへのアクセスを制御する目的で、ユーザは、ユーザ認証プロセスに入ることを要求されているのが普通である。ネットワークアクセス制御サーバがユーザを認証したあとでも、ユーザは、そのサービスにアクセするためには、特定サーバの許可を要求する必要がある。ユーザ認証 (user authentication) によってネットワークアクセス制御を制御するために、ケルベロス５ (Kerberos 5) プロトコルのような、異種のプロトコルをベースとする種々の方式が提案され、実現されている。
【０００４】
一般的に、コンピュータに対するユーザログオンとネットワークアクセス制御のためのユーザ認証は、別々のプロシージャになっている。それにもかかわらず、異種のアクセス制御方式を扱うときのユーザの負担を最小限にするために、ユーザログオンとネットワークアクセスのためのユーザ認証は、一緒に実行されることが時々ある。例えば、ユーザ認証がケルベロスプロトコルに基づいて実現されている場合には、ユーザがコンピュータにログオンしたとき、コンピュータは、ケルベロス認証プロセスを開始することも可能になっている。この認証プロセスでは、コンピュータはケルベロス鍵配信センタ (Key Distribution Center - KDC) に連絡し、最初に、ユーザのためのチケット認可チケット (ticket granting ticket - TGT) を取得している。そのあと、コンピュータはそのTGT を使用して、自身のためのセッションチケットを鍵配信センタ (KDC)から取得することが可能になっている。
【０００５】
ネットワークが発達するのに伴い、サーバ/サービスコンピュータは、クライアントコンピュータからの要求を処理するために複数の層に構成される傾向がある。単純な例として、World Wide Web（ワールドワイドウェブ）のWebサイトに対する要求をインターネット (the Internet) を通して行うクライアントコンピュータがある。この例では、要求のフォーマッティングおよび関連ビジネスルールを処理するフロントエンドWebサーバと、Webサイトのためのデータベースを管理するバックエンドサーバが存在している。セキュリティを強化するために、Webサイトは、認証プロトコル (authentication protocol) が、例えば、ユーザのTGTなどの信用証明書 (credential) および/または、可能ならば、他の情報をフロントエンドサーバからバックエンドサーバに転送（または委任 (delegate)）するような構成になっている場合がある。このようなやり方は、多くのWebサイトおよび/または他の多層 (multiple-tiered) ネットワークでは、ますます普及化されている。
【０００６】
従って、ユーザのTGTと関連認証符号を保持するサーバ/コンピュータ(authenticator) は、ユーザ/クライアントに代わって鍵配信センタ (KDC)にチケットを要求することが可能になっている。この機能は、現在では、転送されるチケット委任を行うために使用されている。残念ながら、このようなサーバへの委任は、基本的には、TGTが存続する間、無拘束 (unconstrained) になっている。その結果として、複合ネットワーク構成で、しかし、もっと拘束された形で、認証信用証明書 (authentication credential) の委任をサポートする改良方法とシステムが要望されている。
【０００７】
【発明が解決しようとする課題】
本発明は、上述の点に鑑みて、認証信用証明書 (authentication credential)の委任を拘束された形で行う改良方法とシステムを提供することを解決すべき課題にしている。
【０００８】
【課題を解決するための手段】
上述した要望および他の要望は、例えば、クライアントに代わってアクセスしようとしているターゲットサービスを特定し、サーバによって使用される新たなサービス信用証明書を、サーバから信頼できる第三者機関 (trusted third party) に要求させる本発明による方法によって達成される。この要求を行うために、サーバは、サーバを認証する信用証明書、ターゲットサービスに関する情報、およびクライアントによって、あるいはクライアントに代わってサーバによって以前に取得されたサービス信用証明書を信頼できる第三者機関に提供する。この方法によれば、新たなサービス信用証明書は、サーバのIDではなく、クライアントのIDで発行されるが、これは、サーバだけによって使用されて、ターゲットサービスへのアクセス権が得られるようにしている。
【０００９】
本発明の種々の方法とシステムの理解を容易にするために、以下では、添付図面を参照して詳しく説明されている。
【００１０】
【発明の実施の形態】
図面を参照して説明すると、本発明は、適当なコンピューティング環境で実現されるものとして示されている。なお、図面において、同様のエレメントは同様の参照符号を付けて示されている。必ずしもその必要はないが、本発明は、プログラムモジュールのように、パーソナルコンピュータによって実行されるコンピュータ実行可能命令の広い意味で説明されている。一般的に、プログラムモジュールとしては、特定のタスクを実行し、あるいは特定の抽象データ型を実装しているルーチン、プログラム、オブジェクト、コンポーネント、データ構造などがある。さらに、この分野の精通者ならば理解されるように、本発明は、他のコンピュータシステム構成で実施することも可能であり、その中には、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルコンシューマエレクトロニクス、ネットワークPC、ミニコンピュータ、メインフレームコンピュータなどが含まれている。また、本発明は、分散型コンピューティング環境で実施することも可能であり、そこでは、タスクは、通信ネットワークを通してリンクされたリモート処理デバイスによって実行されている。分散型コンピューティング環境では、プログラムモジュールは、ローカルとリモートの両方のメモリストレージデバイスに置いておくことができる。
【００１１】
図１は、以下に説明されている方法とシステムを実現することが可能である、適当なコンピューティング環境１２０の例を示す図である。
【００１２】
例示のコンピューティング環境１２０は、適当なコンピューティング環境の一例にすぎず、本明細書で説明している改良方法とシステムの使用または機能の有効範囲に関して、なんらの制限を意味するものではない。また、コンピューティング環境１２０は、このコンピューティング環境１２０に図示されているコンポーネントのどれとも、あるいはどの組み合わせとも、なんらかの依存関係または要件があるものと解釈してはならない。
【００１３】
ここに説明されている改良方法とシステムは、多数の、他の汎用または特殊目的コンピューティングシステム環境または構成で動作可能である。適当と考えられる、周知のコンピューティングシステム、環境、および/または構成の例としては、パーソナルコンピュータ、サーバコンピュータ、小型軽量 (thin) クライアント、大型重量 (thick) クライアント、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス (set top box)、プログラマブルコンシューマエレクトロニクス、ネットワークPC、ミニコンピュータ、メインフレームコンピュータ、上述したシステムまたはデバイスのいずれかを含んでいる分散型コンピューティング環境などがあるが、これらに限定されるものではない。
【００１４】
図１に示すように、コンピューティング環境１２０は、パーソナルコンピュータ１３０の形体をした汎用コンピューティングデバイスを含んでいる。コンピュータ１３０のコンポーネントとしては、１つまたは２つ以上のプロセッサまたは処理ユニット１３２、システムメモリ１３４、およびシステムメモリ１３４を含む種々のシステムコンポーネントをプロセッサ１３２に結合しているバス１２３がある。
【００１５】
バス１３６は、数種タイプのバス構造の１つまたは２つ以上を表しており、その中には、種々のバスアーキテクチャのいずれかを採用したメモリバスまたはメモリコントローラ、ペリフェラル（周辺）バス、高速グラフィックスポート、およびプロセッサまたはローカルバスが含まれている。このようなアーキテクチャの例としては、Industry Standard Architecture（ISA−業界標準アーキテクチャ）バス、Micro Channel Architecture（MCA −マイクロチャネルアーキテクチャ）バス、Enhanced ISA（EISA−拡張ISA）バス、Video Electronics Standards Association（VESA−ビデオエレクトロニクス標準協会）ローカルバス、およびMezzanine（メザニン：中二階）バスとも呼ばれているPeripheral Component Interconnects（PCI−ペリフェラルコンポーネント相互接続）バスがあるが、これらに限定されない。
【００１６】
コンピュータ１３０は、種々のコンピュータ読取可能媒体を装備しているのが代表的である。そのような媒体としては、コンピュータ１３０によってアクセス可能な媒体であれば、どのような媒体も利用可能であり、その中には、揮発性媒体と不揮発性媒体、取り外し可能媒体と取り外し不能媒体が含まれている。
【００１７】
図１に示すように、システムメモリ１３４には、ランダムアクセスメモリ (random access memory - RAM) １４０のような揮発性メモリ、および/またはリードオンリメモリ (read only memory - ROM) １３８のような不揮発性メモリの形体をしたコンピュータ読取可能媒体が含まれている。スタートアップ時のときのように、コンピュータ１３０内のエレメント間で情報を転送するのを支援する基本ルーチンで構成された基本入出力システム (basic input/output system - BIOS) １４２は、ROM １３８に格納されている。RAM １４０には、プロセッサ１３２が即時にアクセス可能である、および/またはプロセッサ１３２によって現在操作の対象になっているデータおよび/またはプログラムモジュールが置かれているのが代表的である。
【００１８】
コンピュータ１３０は、さらに、他の取り外し可能/取り外し不能の揮発性/不揮発性コンピュータストレージ媒体を装備している場合もある。例えば、図１は、取り外し不能の不揮発性磁気媒体（図示していないが、「ハードディスク」と呼ばれているのが代表的）との間で読み書きを行うハードディスクドライブ１４４、取り外し可能の、不揮発性磁気ディスク１４８との間で読み書きを行う磁気ディスクドライブ１４６（例えば、「フロッピー（登録商標）ディスク」）、およびCD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAMまたは他の光媒体などの、取り外し可能の不揮発性光ディスク１５２との間で読み書きを行う光ディスクドライブ１５０を示している。ハードディスクドライブ１４４、磁気ディスクドライブ１４６および光ディスクドライブ１５０は、それぞれ、１つまたは２つ以上のインタフェース１５４によってバス１３６に接続されている。
【００１９】
これらのドライブとそれぞれに関連するコンピュータ読取可能媒体は、不揮発性ストレージとしてコンピュータ読取可能命令、データ構造、プログラムモジュールおよび他のデータをコンピュータ１３０のために格納している。ここで説明している例示環境では、ハードディスク、取り外し可能磁気ディスク１４８、および取り外し可能光ディスク１５２が採用されているが、この分野の精通者ならば当然に理解されるように、コンピュータによってアクセス可能であるデータを格納して置くことができる、他のタイプのコンピュータ読取可能媒体を例示動作環境で採用することも可能である。そのような他のタイプの媒体としては、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ランダムアクセスメモリ (RAM)、リードオンリメモリ (ROM) などがある。
【００２０】
いくつかのプログラムモジュールは、ハードディスク、磁気ディスク１４８、光ディスク１５２、ROM １３８またはRAM １４０に格納しておくことが可能であり、そのようなものとして、オペレーティングシステム１５８、１つまたは２つ以上のアプリケーションプログラム１６０、他のプログラムモジュール１６２、およびプログラムデータ１６４がある。
【００２１】
ここで説明している改良方法とシステムは、オペレーティングシステム１５８、１つまたは２つ以上のアプリケーションプログラム１６０、他のプログラムモジュール１６２、および/またはプログラムデータ１６４内で実現することが可能である。
【００２２】
ユーザは、キーボード１６６やポインティングデバイス１６８（「マウス」など）などの、入力デバイスを通してコマンドと情報をコンピュータ１２０に与えることができる。他の入力デバイス（図示せず）としては、マイクロホン、ジョイスティック、ゲームパッド、サテライトディッシュ、シリアルポート、スキャナ、カメラなどがある。上記および他の入力デバイスは、バス１３６に結合されたユーザ入力インタフェース１７０を通して処理ユニット１３２に接続されているが、パラレルポートやゲームポート、ユニバーサルシリアルバス (universal serial bus - USB) などの、他のインタフェースで接続することも可能である。
【００２３】
モニタ１７２や他のタイプのディスプレイデバイスも、ビデオアダプタ１７４などのインタフェースを介してバス１３６に接続されている。モニタ１７２のほかに、パーソナルコンピュータは、スピーカやプリンタなどの他のペリフェラル（周辺）出力デバイス（図示せず）を装備しているのが代表的であり、これらのデバイスは、出力周辺インタフェース１７５を通して接続可能になっている。
【００２４】
コンピュータ１３０は、リモートコンピュータ１８２などの、１つまたは２つ以上のリモートコンピュータとの論理コネクションを使用するネットワーキング環境で動作することができる。リモートコンピュータ１８２は、パーソナルコンピュータ１３０に関して上述したエレメントの多くまたは全部を装備していることがある。
【００２５】
図１に示す論理コネクションとしては、ローカルエリアネットワーク (local area network - LAN) １７７と広域ネットワーク (wide area network - WAN) １７９がある。このようなネットワーキング環境は、オフィス、企業内 (enterprise-wide) コンピュータネットワーク、イントラネット (intranet)、およびインターネット (the Internet) で普及している。
【００２６】
LANネットワーキング環境で使用されるときは、コンピュータ１３０は、ネットワークインタフェースまたはアダプタ１８６を通してLAN １７７に接続されている。WANネットワーキング環境で使用されるときは、コンピュータは、WAN １７９上のコミュニケーションを確立するためのモデム１７８や他の手段を装備しているのが代表的である。モデム１７８は内蔵型と外付け型があるが、どちらも、ユーザ入力インタフェース１４６や他の該当メカニズムを介してシステムバス１３６に接続することが可能になっている。
【００２７】
図１に示されているのは、インターネットを通したWANの具体的構築例である。そこでは、コンピュータ１３０は、インターネット１８０を経由して少なくとも１つのリモートコンピュータ１８２とのコミュニケーションを確立するためにモデム１７８を採用している。
【００２８】
ネットワーキング環境では、コンピュータ１３０に関して上述したプログラムモジュールまたはその一部は、リモートメモリストレージデバイスに置いておくことが可能である。従って、例えば、図１に示すように、リモートアプリケーションプログラム１８９は、リモートコンピュータ１８２のメモリデバイスに置いておくことができる。当然に理解されるように、図示し、説明してきたネットワークコネクションは例示であり、コンピュータ間の通信リンクを確立する他の手段を使用することも可能である。
【００２９】
以下では、クライアント−サーバのネットワーク環境において認証信用証明書(authentication credential) の委任の有効範囲 (scope of delegation) を制御するための、本発明のいくつかの態様を中心に説明することにする。以下では、例示のケルベロスベース (Kerberos-based) のシステムとその改良を中心に説明されているが、本発明の種々の方法とシステムは、明らかであるように、他の認証システムと手法にも適用可能である。例えば、証明書ベース (certificate-based) の認証システムと手法を、本発明のいくつかの側面に適応させることが可能である。
【００３０】
上述したように、クライアントのチケット認可チケット (ticket granting ticket - TGT) と関連認証符号 (authenticator) を保持すると、保持者は、クライアントに代わってチケットを信頼できる第三者機関 (trusted third-party)、例えば、鍵配信センタ (key distribution center - KDC) に要求することができる。この無拘束委任 (unconstrained delegation) は、現在、転送チケット委任方式 (forwarded ticket delegation schemes) を採用している、ある種のケルベロス実装でサポートされている。
【００３１】
本発明によれば、以上のことを念頭に置いて、委任プロセスを拘束し、あるいはその制御を改善する方法とシステムが提供されている。これらの方法とシステムは、異種の認証プロトコルで使用すること可能になっている。いくつかの例示実施形態では、この委任プロセスは、サービス・フォー・ユーザ・トゥ・プロキシー（service-for-user-to-proxy ）(S4U2proxy) 手法を通して制御されている。このS4U2proxy（委任）手法は、好ましくは、例えば、フロントエンドサーバ/サービスのような、サーバまたはサービスがクライアントに代わってサービスチケットを要求し、他のサーバ/サービスで使用されるようにするプロトコルとして実現されている。以下で詳しく説明するように、S4U2proxyプロトコルによると、拘束された委任 (constrained delegation) が制御された形で行われるので、クライアントはTGTをフロントエンドサーバに転送しないで済むという利点が得られる。
【００３２】
ここに開示されているもう１つの手法は、サービス・フォー・ユーザ・トゥ・セルフ（service-for-user-to-self） (S4U2self) 手法である。このS4U2self（自身）手法またはプロトコルによると、ユーザは自身のためにサービスチケットを要求することができるが、クライアントのIDは、その結果として得られたサービスチケットの中に入っている。このようにすると、例えば、クライアントは、他の認証プロトコルによって認証されているので、基本的にサービスチケットを得ることができ、そのサービスチケットをS4U2proxyプロトコルで使用すると、拘束委任が得られることになる。S4U2proxy手法には、２つの例示形式がある。すなわち、「無証拠(no evidence)」形式と「証拠(evidence)」形式である。無証拠形式では、サーバは、例えば、そのサーバに専用されている別のセキュリティ/認証メカニズムを使用して、例えば、クライアントを認証するものと信用されている。証拠形式では、鍵配信センタ (KDC)（または信頼できる第三者機関）は、クライアントに関して用意されていて、クライアントがサーバに対して認証をしたとき得られる情報（証拠）に基づいて認証を行っている。
【００３３】
本明細書に開示されている方法とシステムによると、クライアントは、そのクライアントがケルベロス認証プロトコルによって認証されたか、他のなんらかの認証プロトコルによって認証されたかに関係なく、ケルベロス環境内でサーバ/サービスにアクセスすることができる。その結果、バックエンドおよび/または他のサーバ/サービスは、基本的にケルベロスのみの環境で動作させることが可能になっている。
【００３４】
次に、図２のブロック図を参照して説明すると、図２は、本発明のいくつかの例示実施形態によるクライアント−サーバ環境２００内のS4U2proxyプロトコル/プロセスを示している。
【００３５】
図示のように、クライアント２０２は、信頼できる第三者機関２０４に動作状態で結合され、信頼できる第三者機関は、認証サービス２０６、例えば、鍵配信センタ (KDC)、認証交付機関 (certificate granting authority −証明書発行局とも呼ばれる)、ドメインコントローラなどが動作状態で置かれている構成になっている。認証サービス２０６は、データベース２０８に保存されている情報にアクセスするように構成されている。クライアント２０２と信頼できる第三者機関２０４は、さらに、サーバ、つまり、サーバA ２１０に動作状態で結合されている。なお、本明細書で用いられている「サーバ」と「サービス」という用語は、同一または類似機能を表すために同じ意味で用いられている。
【００３６】
この例では、サーバA ２１０は、複数の他のサーバに対してフロントエンドサーバになっている。従って、図示のように、サーバA ２１０は、サーバB ２１２とサーバC ２１４に動作状態で結合されている。図示のように、サーバB ２１２は、複製サービス (replicated service) にすることができる。また、サーバC ２１４は、さらに、サーバD ２１６に動作状態で結合されている。
【００３７】
ユーザがクライアント２０２でログオンすると、認証要求 (AS_REQ) メッセージ２２０が認証サービス２０６に送信され、これに対する応答として、認証サービス２０６は、認証応答 (AS_REP) メッセージ２２２を返送する。AS_REPメッセージ２２２には、ユーザ/クライアントに関連するTGTが入っている。サーバA ２１０も、同じまたは類似プロシージャ（図示せず）に従って認証される。
【００３８】
クライアント２０２がサーバA ２１０にアクセスしたいときは、クライアントは、チケット認可サービス要求 (TGS_REQ) メッセージ２２４を認証サービス２０６に送信し、認証サービス２０６からは、チケット認可サービス応答 (TGS_REP) メッセージ２２６が返送される。このTGS_REPメッセージ２２６には、クライアント２０２とサーバA ２１０に関連するサービスチケットが入っている。そのあと、通信セッションを開始するために、クライアント２０２は、アプリケーションプロトコル要求 (AP_REQ) メッセージ２２８の中で、そのサービスチケットをサーバA ２１０に転送する。これらのプロセス/プロシージャは周知であるので、ここで詳しく説明することは省略する。
【００３９】
従来では、委任をサポートするために、クライアントはサーバA ２１０にクライアントのTGTを提供して、サーバA ２１０がクライアント２０２に代わって追加のサービスチケットを要求できるようにする必要があった。いまでは、その必要がなくなった。その代わりに、サーバA ２１０がクライアント２０２に代わって別のサーバ、例えば、サーバC ２１４にアクセスする必要があるときは、サーバA ２１０と認証サービス２０６は、S4U2proxyプロトコルに従って動作している。
【００４０】
従って、例えば、S4U2proxyプロトコルを実装している、いくつかの例示実施形態によれば、サーバA ２１０は、TGS_REQメッセージ２３０を認証サービス２０６に送信している。このTGS_REQメッセージ２３０は、サーバA ２１０のためのTGTとクライアント２０２から受信したサービスチケットを含んでおり、クライアント２０２がアクセスしようとしている望みの、またはターゲットとしているサーバ/サービス、例えば、サーバC ２１４を示している。例えば、ケルベロスでは、拡張可能データフィールドが定義されており、これは、「追加チケット」フィールドと呼ばれているのが代表的である。この追加チケットフィールドは、クライアント２０２から受信したサービスチケットを伝達するためにS4U2proxyプロトコルで使用することができ、また、クライアントIDを与えるために使用されるチケットを得るために、受信側鍵配信センタ (KDC)にこの追加チケットフィールドを調べるように指示するフラグまたは他のインジケータは、鍵配信センタ (KDC)オプションフィールドで指定することが可能になっている。この分野の精通者ならば理解されるように、これらのフィールドまたは他のフィールドおよび/またはデータ構造は、必要な情報を認証サーバ２０６に伝達するために使用することが可能である。
【００４１】
TGS_REQ ２３０を処理するとき、認証サービス２０６は、クライアント２０２が委任を許可していたかどうかを、例えば、クライアント２０２によって設定された「転送可能(forwardable)フラグ」の値に基づいて判断する。従って、クライアントによる委任は、この転送可能フラグがクライアントのサービスチケットの中に存在すると強制される。クライアント２０２が委任に関与することを望んでいなければ、チケットには、転送可能フラグが付けられない。認証サービス２０６は、このフラグをクライアントによる制限として尊重する。
【００４２】
他の実施形態では、認証サービス２０６は、サーバA ２１０がクライアント２０２に対して、どのサービスに委任することが許されているか（または委任することが許されていないか）を定義している追加情報を、データベース２０８からアクセスすることが可能になっている。
【００４３】
サーバA ２１０がターゲットとしているサーバ/サービスに委任することを許されていないと認証サービス２０６が判断したときは、TGS_REPメッセージ２３２がサーバA ２１０に送信される。このTGS_REPメッセージ２３２には、ターゲットとするサーバ/サービスのためのサービスチケットが含まれている。このサービスチケットは、クライアント２０２が、例えば、クライアントのTGTを使用して認証サービス２０６から直接にサービスチケットを要求したかのようになっている。しかし、実際はそうではない。その代わりに、認証サービス２０６は、認証されたサーバA ２１０がクライアント２０２から受信し、TGS_REQメッセージ２３０に入っているサービスチケットに基づく要求に、認証されたクライアントが基本的に関与していると納得したあとで、類似の/必要なクライアント情報をデータベース２０８からアクセスしている。しかし、クライアント情報はクライアントチケットに入って伝達されるので、サーバは、そのチケットからデータをコピーするだけで済むことになる。従って、データベース２０８を使用することができるが、チケットに入っているデータをコピーした方が効率的である。
【００４４】
いくつかの実施形態では、例えば、TGS_REPメッセージ２３２は、ターゲットとしているサーバ/サービスとクライアント２０２を示しているが、さらに、実装時固有ID/ユーザ/クライアントアカウントデータを、例えば、特権属性証明書 (privilege attribute certificate - PAC)、セキュリティID、Unix（登録商標）ID、Passport ID、証明書などの形で含んでいる。例えば、PACは、認証サービス２０６によって生成することができるが、TGS_REQメッセージ２３０に入っていたクライアントのサービスチケットからコピーするだけで済むこともある。
【００４５】
PACまたは他のユーザ/クライアントアカウントデータは、委任の有効範囲 (scope of delegation) に関する情報を含むように構成することも可能である。従って、例えば、図５に示すように、ケルベロスメッセージ４００には、ヘッダ４０２とPAC ４０４を収めている部分がある。そこでは、PAC ４０４は、委任情報４０６を含んでいる。図示のように、委任情報４０６は、複合ID情報 (compound identity information) ４０８とアクセス制限情報 (access restriction information) ４１０を含んでいる。
【００４６】
複合ID情報４０８の例としては、例えば、サーバA ２１０がユーザ/クライアント２０２に代わってサービスチケットを要求したことを示す表示（indication）のように、委任プロセスに関する記録情報がある。そこでは、複数の記録情報を得ることができるので、１つのストリングにしたり、あるいは複数の委任プロセスにわたるヒストリ（活動記録）を示したりするために使用することができる。この情報は、監査 (audit) 目的および/またはアクセス制御目的に使用すると便利である。
【００４７】
アクセス制限情報４１０は、例えば、アクセス制御メカニズムと関連付けて使用すると、クライアント２０２が直接的に、またはサーバA ２１０を通して間接的にサーバ/サービスにアクセスしようとした場合は、ある種のサーバ/サービスへのアクセスを許可し、サーバ/サービスがサーバB ２１２を通して間接的に求められる場合は、アクセスを許可しない、といったようにアクセスを選択的に制御することができる。この機能によると、認証信用証明書の委任に対する制御が強化されることになる。
【００４８】
上記の例では、クライアント２０２は、認証サーバ２０６によって認証されていた。しかし、当然に理解されるように、他のクライアントはそのように認証されない場合がある。そのような場合の例を示したのが、図３である。そこでは、クライアント３０２は、異なる認証プロトコルメカニズム３０３を使用して認証されている。認証プロトコルメカニズム３０３の例としては、Passport、セキュアソケットレイヤ (secure sockets layer - SSL)、NTLM、Digest、またはその他の類似認証プロトコル/プロシージャがある。なお、この例では、クライアント３０２は、ターゲットとするサービスにアクセスすることを選択したが、そのサービスがサーバC ２１４によって提供されるのは、偶然にすぎないものと想定されている。この選択は、上述したS4U2proxyプロトコルを使用すると満たすことができるが、それができるのは、サーバA ２１０がS4U2proxyプロトコル/プロシージャを完了/に従った後だけである。
【００４９】
S4U2selfプロトコルには、１つの基本的前提がある。つまり、サーバ、例えば、サーバA ２１０が、サーバにアクセスしようとしていて、サーバが自身で認証したユーザ/クライアントのために、自身に対するサービスチケットを要求できることを前提としている。ここで説明している例示のS4U2selfプロトコルは、認証「証拠」をもっているクライアントおよびそのような認証証拠をもたないクライアントをサポートするように構成されている。
【００５０】
認証サービス２０６によって評価できる認証証拠がないときは、サーバA ２１０は、クライアント３０２を「信用」する必要がある。従って、例えば、サーバA ２１０が有効性検査できる認証証明書または類似のメカニズム３０４をクライアント３０２がもっていれば、そのクライアント３０２は、「信用」されているものと判断することができる。ここでは、クライアント３０２は、基本的には、サーバA ２１０によって認証されている。次に、サーバA ２１０は、TGS_REQメッセージ３０６を認証サービス２０６に送信し、クライアント３０２のために自身に対するサービスチケットを要求する。その応答として、認証サービス２０６は、要求されたサービスチケットを含んでいるTGS_REPメッセージ３０８を生成する。そのサービスチケットが受信されると、これは、クライアント３０２のためにサーバC ２１４に対するサービスチケットを要求するために、後続のS4U2proxyプロトコル/プロシージャで使用される。いくつかのケルベロス実装例では、そのためには、TGS_REPメッセージ３０８の中の転送可能フラグは、サービスチケットの転送を可能にするようにセットされている必要がある。信頼できる第三者機関は、クライアント３０２のためにPACを作成することもできるので、これは、結果として得られたサービスチケットに組み入れておくことができる。
【００５１】
認証の証拠がクライアント３０２’に対して存在しないときは、サーバA ２１０は、その証拠を追加の事前認証データとしてTGS_REQメッセージ３１２に組み入れることができる。このことは、図４の環境３００'に示されている。そこでは、証拠情報３１０は、クライアント３０２’からサーバA ２１０に与えられている。証拠情報３１０の例としては、チャレンジ/応答ダイアログのほかに、別の「信用」エンティティによって生成される情報がある。証拠情報３１０を受信し、そのあとに続いて有効性検査が行われると、認証サービス２０６は、要求されたサービスチケットをサーバA ２１０自身に発行する。なお、いくつかの実施形態では、証拠を使用すると、サーバはクライアントのために、制限されたTGTを取得することが可能になる。
【００５２】
いくつかのケルベロス実装では、TGS_REPメッセージ３１４の中の転送可能フラグは、サービスチケットの転送を可能にするようにセットされる。PACがTGS_REQメッセージ３１２に入っていれば、これは、サービスチケットの中で使用することが可能であり、そうでなければ、PACは、証拠情報３１０に基づいて認証サービス２０６（この例では、鍵配信センタ (KDC)）によって生成することができる。例えば、S4U2selfでは、クライアントのIDは、事前認証データに組み込まれている。このIDは、クライアントのためにPACを構築するときに使用して、（クライアントのために）サーバに対する発行サービスチケットに追加することができる。
【００５３】
以上、本発明の種々の方法とシステムの、いくつかの好ましい実施形態を添付図面に図示し、詳細な説明の中で説明してきたが、当然に理解されるように、本発明は上述してきた例示実施形態に限定されるものではなく、各請求項に記載され、明確化されている本発明の精神から逸脱しない限り、数多くの再構成、変更、および置換を行うことが可能である。
【図面の簡単な説明】
【図１】本発明を実現することができる例示コンピュータシステムを示すブロック図である。
【図２】本発明のいくつかの例示実施形態に従って、クライアント−サーバ環境内で実行されるservice-for-user-to-proxy (S4U2proxy) プロセスを示すブロック図である。
【図３】本発明のいくつかの例示実施形態に従って、クライアント−サーバ環境内で実行されるservice-for-user-to-self (S4U2self) プロセスを示すブロック図である。
【図４】本発明のいくつかの、別の例示実施形態に従って、クライアント−サーバ環境内で実行されるservice-for-user-to-self (S4U2self) プロセスを示すブロック図である。
【図５】本発明のいくつかの実施形態で使用するのに適したメッセージフォーマットの一部を選択して示す概略図である。
【符号の説明】
２００ クライアント−サーバ環境
２０２ クライアント
２０４ 信頼できる第三者機関
２０６ 認証サービス
２０８ データベース
２１０ サーバＡ
２１２ サーバＢ
２１４ サーバＣ
２１６ サーバＤ
２２０ 認証要求 (AS_REQ) メッセージ
２２２ 認証応答 (AS_REP) メッセージ
２２４ チケット認可サービス要求 (TGS_REQ) メッセージ
２２６ チケット認可サービス応答 (TGS_REP) メッセージ
２２８ アプリケーションプロトコル要求 (AP_REQ) メッセージ
２３０ TGS_REQメッセージ
２３２ TGS_REPメッセージ
Claims (33)
- サーバへのクライアントによる委任を制限する方法であって、
クライアントがサーバにアクセスするためのサービス信用証明書を信頼できる第三者機関から得るステップと、
前記クライアントから前記サーバに対して前記サービス信用証明書の委任が許可されていることを前記サービス信用証明書に明記させること、あるいは
前記クライアントから前記サーバに対して前記サービス信用証明書の委任が許可されていることの表示（indication）を保持することを前記信頼できる第三者機関にさせること
の１つによって、前記クライアントに代わって１または複数のサービスにアクセスすることを前記サーバに許可するステップと、
前記クライアントが前記信頼できる第三者機関から前記サービス信用証明書を受け取るステップと、
前記クライアントが前記サーバに前記サービス信用証明書を提供するステップと、
前記クライアントが前記サーバを介してリソースにアクセスすることを要求するステップと、
前記リソースが前記サーバには備わっていないターゲットサービスによって提供されるものであることを前記サーバが前記クライアントのために特定するステップと、
前記信頼できる第三者機関から提供される、前記クライアントに代わって前記ターゲットサービスにアクセスするための新たなサービス信用証明書をサーバ自身が要求するステップと、
前記クライアントがクライアント認証信用証明書と該クライアント認証信用証明書の使用の能力を前記サーバに与えないでおくステップと、
前記サーバを認証する信用証明書、および
前記ターゲットサービスについての情報
を前記信頼できる第三者機関に前記サーバが提供するステップと、
前記サービス信用証明書が前記ターゲットサービスをアクセスするための前記サービス信用証明書の委任が許可されていることを明記している、あるいは
前記信頼できる第三者機関が前記ターゲットサービスをアクセスするための前記サービス信用証明書の委任が許可されていることの表示を保持している
のいずれかの場合に、前記クライアントによる関与なしに前記クライアントに代わって前記ターゲットサービスにアクセスすることを前記サーバに許可する前記新たなサービス信用証明書を提供することを前記信頼できる第三者機関にさせるステップと
を含むことを特徴とする方法。 - 請求項１に記載の方法において、前記信頼できる第三者機関は、鍵配信センタ (KDC) サービス、認証交付機関サービス、およびドメインコントローラサービスを含むサービスグループから選択された、少なくとも１つのサービスを含んでいることを特徴とする方法。
- 請求項１に記載の方法において、前記新たなサービス信用証明書は、前記サーバおよびアクセスしようとしている前記ターゲットサービスによって使用されるように構成されていることを特徴とする方法。
- 請求項１に記載の方法において、前記サーバを認証する前記信用証明書は、前記サーバに関連するチケット認可チケットを含むチケットであることを特徴とする方法。
- 請求項１に記載の方法において、さらに、
前記クライアントが委任を許可していることを前記信頼できる第三者機関に検証させることを含むことを特徴とする方法。 - 請求項５に記載の方法において、
前記信頼できる第三者機関は鍵配信センタ (KDC) を含み、
前記クライアントが委任を許可していたことを前記信頼できる第三者機関に検証させることは、前記クライアントから出されたチケットに載せられている制限のステータスを検証することを含むことを特徴とする方法。 - 請求項１に記載の方法において、前記サーバは、フロントエンドサーバと結合しているバックエンドサーバに対するフロントエンドサーバであり、該バックエンドサーバはアクセスしようとする前記ターゲットサービスを提供するように構成されていることを特徴とする方法。
- 請求項１に記載の方法において、
前記信頼できる第三者機関は鍵配信センタ (KDC) を含み、
該鍵配信センタ (KDC)は、前記クライアントに関連するチケット認可チケットを該クライアントに提供し、
前記クライアントは、前記チケット認可チケットを前記サーバに提供しないことを特徴とする方法。 - 請求項１に記載の方法において、
前記信頼できる第三者機関は鍵配信センタ (KDC) を含み、
前記サーバは、前記クライアントによって前記サーバに提供されたサービスチケットを含んでいるチケット認可サービス要求メッセージで前記新たなサービス信用証明書を要求することを特徴とする方法。 - サーバへのクライアントによる委任を制限する方法であって、
サービス信用証明書を１または複数のサービスに転送可能であると印をつけること、
あるいは
前記クライアントの代わりに前記１または複数のサービスにアクセスすることを前記サーバが許可されているとの表示を保持すること
のいずれか１つによって表明される前記１または複数のサービスにアクセスすることの前記クライアントによる前記サーバに対する委任許可にともなって、信頼できる第三者が前記サーバにアクセスする前記クライアントへサービス信用証明書を提供するステップと、
前記クライアントが前記サービス信用証明書を前記サーバに提供するステップと、
前記クライアントが前記サーバを介してリソースにアクセスすることを要求するステップと、
リソースを得るためクライアントの代わりにアクセスしようとしている前記サーバに備わっていないターゲットサービスを前記サーバが特定するステップと、
新たなサービス信用証明書の要求に前記クライアントを関与させることなしに、前記クライアントの代わりに前記ターゲットサービスにアクセスするための該新たなサービス信用証明書を前記サーバが前記信頼できる第三者機関に要求するステップと
前記サーバを認証する認証信用証明書と、前記ターゲットサービスについての情報と、
前記クライアントから前記サーバに以前に提供された前記サービス信用証明書とを前記信頼できる第三者機関に前記サーバが提供するステップであって、前記クライアントにより以前に提供された該サービス信用証明書は、前記サーバに対して委任されたアクセスの範囲を制限する実装時固有ID情報（implementation-specific identity information）を含んでいる、ステップと、
前記サーバに対して前記クライアントにより許可された前記委任が、前記１または複数のサービスに対して前記ターゲットサービスを含んでいる場合に、前記実装時固有ID情報に規定されたアクセスの範囲内で前記ターゲットサービスにアクセスすることを前記クライアントの関与なしに前記サーバに許可する前記新たなサービス信用証明書を前記信頼できる第三者機関から前記サーバへ提供させるステップと
を含むことを特徴とする方法。 - 請求項１０に記載の方法において、前記実装時固有ID情報は、特権属性証明 ( PAC：privilege attribute certificate) 情報、セキュリティID情報、Unix（登録商標）ID情報、Passport ID情報、および証明書情報を含むグループから選択された情報を含んでいることを特徴とする方法。
- 請求項１１に記載の方法において、前記特権属性証明 ( PAC)は、複合ID情報を含んでいることを特徴とする方法。
- 請求項１１に記載の方法において、前記特権属性証明 ( PAC)は、
委任範囲についての制約情報として使用されるアクセス制御情報を含んでいることを特徴とする方法。 - サーバへのクライアントによる委任を制限ためのタスクを実行するためのコンピュータ実行可能命令を格納しているコンピュータ読取可能記録媒体であって、前記コンピュータ実行可能命令は、
サーバ側において、該サーバに結合されたクライアントに代わってアクセスしようとしているターゲットサービスを特定すること、
前記サーバ側において、前記ターゲットサービスにアクセスするために信頼できる第三者機関から提供される新たなサービス信用証明書を要求すること
を含み、
前記新たなサービス信用証明書の処理において前記クライアントの関与がなく、また前記サーバを認証する信用証明書、前記ターゲットサービスについての情報、および前記クライアントによって以前に提供されたサービス信用証明書を前記信頼できる第三機関から提供することでクライアント認証信用証明書を提供せず、かつ前記新たなサービス信用証明書の発行のような前記サーバによる要求に対しては、
前記サービス信用証明書が代理人に委任できることを明示しているか、あるいは
前記サービス信用証明書が代理人に委任できることの表示を前記信頼できる第三者機関が保持しているか
のいずれかである場合に、前記クライアントの代わりに前記サービスにアクセスすることを許可することを特徴とするコンピュータ読取可能記録媒体。 - 請求項１４に記載のコンピュータ読取可能記録媒体において、
前記信頼できる第三者機関は、鍵配信センタ ( KDC) サービス、認証交付機関サービス、およびドメインコントローラサービスを含むサービスグループから選択された、少なくとも１つのサービスを含んでいることを特徴とするコンピュータ読取可能記録媒体。 - 請求項１４に記載のコンピュータ読取可能記録媒体において、
前記信用証明書は、前記サーバと前記ターゲットサービスによって使用されるように構成されていることを特徴とするコンピュータ読取可能記録媒体。 - 請求項１４に記載のコンピュータ読取可能記録媒体において、
前記サーバを認証する前記信用証明書は、前記サーバに関連するチケット認可チケットを含んでいることを特徴とするコンピュータ読取可能記録媒体。 - 請求項１４に記載のコンピュータ読取可能記録媒体において、
前記信頼できる第三者機関は鍵配信センタ (KDC) を含み、
前記クライアントが委任を許可していることを前記信頼できる第三者機関によって検証させることをさらに含み、該検証は前記クライアントによってセットされた転送可能フラグ値のステータスを検証することを含むことを特徴とするコンピュータ読取可能記録媒体。 - 請求項１４に記載のコンピュータ読取可能記録媒体において、
前記サーバは、フロントエンドサーバに結合するバックエンドサーバに対するフロントエンドサーバであり、該バックエンドサーバは前記ターゲットサービスを提供するように構成されていることを特徴とするコンピュータ読取可能記録媒体。 - 請求項１４に記載のコンピュータ読取可能記録媒体において、
前記信頼できる第三者機関は鍵配信センタ (KDC) を含み、
前記鍵配信センタ (KDC)は、前記クライアントの前記クライアント認証信用証明書を前記クライアントに関連するチケット認可チケットとして前記クライアントに提供し、
前記クライアントは、前記チケット認可チケットを前記サーバには提供しないことを特徴とするコンピュータ読取可能記録媒体。 - 請求項１４に記載のコンピュータ読取可能記録媒体において、
前記信頼できる第三者機関は鍵配信センタ (KDC) を含み、
前記要求しているサーバは、前記クライアントによって前記サーバに提供されたサービスチケットを含んでいるチケット認可サービス要求メッセージで前記新たなサービス信用証明書を要求することを特徴とするコンピュータ読取可能記録媒体。 - 新たなサービス信用証明書についての要求をサーバから受信すると、それに応答して、クライアント認証信用証明書と該認証信用証明書の使用能力を提供することなしに、委任が許可可能であるならば、前記サーバよりもクライアントの名において付与された前記新たなサービス信用証明書を生成するように構成された信用証明書発行メカニズムを備えているシステムであって、
前記要求は、
前記要求しているサーバを認証する信用証明書と、
前記サーバに結合されている前記クライアントに代わってアクセスしようとしているターゲットサービスについての識別情報と、
前記サーバで使用するために前記クライアントに事前に付与されたサービス信用証明書とを含み、
前記信用証明書発行メカニズムは、
前記クライアントによって委任された範囲内であるとして前記ターゲットサービスに対して前記委任を前記クライアントが許可していることを示している転送可能な委任フラグを前記サービス信用証明書が提示しているか、あるいは
前記ターゲットサービスにアクセスすることの前記サーバに対する委任は前記ターゲットサービスが前記クライアントによって委任された範囲内であるということの表示を前記信用証明発行メカニズムが保持している
のいずれかによって前記委任が許可されるべきであると決定される場合に、
前記要求を許可し、かつ前記クライアントの関与なしに前記ターゲットサービスにアクセスすることを前記サーバに対して許可することを示している前記新たなサービス信用証明書を前記サーバに提供することを特徴とするシステム。 - 請求項２２に記載のシステムにおいて、前記信用証明書発行メカニズムは信頼できる第三者機関によって提供され、鍵配信センタ ( KDC) サービス、認証交付機関サービス、およびドメインコントローラサービスを含むサービスグループから選択された、少なくとも１つのサービスを含んでいることを特徴とするシステム。
- 請求項２２に記載のシステムにおいて、前記新たなサービス信用証明書は、前記サーバおよび前記ターゲットサービスによって使用されるように構成されていることを特徴とするシステム。
- 請求項２２に記載のシステムにおいて、前記サーバを認証する前記信用証明書は、前記サーバに関連していて、信用証明書発行メカニズムによって以前に発行されたチケット認可チケットを含んでいることを特徴とするシステム。
- サーバへのクライアントによる委任の制限を行うためのシステムであって、
クライアントの代わりに、該クライアントの関与なしに、サーバよりむしろクライアントの名による、クライアントとターゲットサービスに関連する、信頼できる第三者機関に対する新たなサービス信用証明書の要求を発生するように構成されたサーバを備え、
該サーバは、
前記クライアントからの要求がターゲットサービスによって提供されるリソースにアクセスしようとしているものであるということを判断し、
前記クライアントの認証信用証明書を提供することなく、前記クライアントの関与もなく、前記ターゲットサービスにアクセスすることを前記サーバに許可することを前記サーバに対して発行すべき前記新たなサービス信用証明書の要求を生成するように構成されているおり、
前記要求は、
前記要求しているサーバを認証する信用証明書と、
前記ターゲットサービスについての情報と、
前記クライアントと前記サーバに関連するサービス信用証明書と
を含み、
前記サーバは、
前記サービス信用証明書自体が代理人に委任できることを示しているか、あるいは
前記サービス信用証明書が代理人に委任できるものであるとの表示を前記信頼できる第三者機関が保持しているか
のいずれかの場合において、前記ターゲットサービスにアクセスすることが許されることを特徴とするシステム。 - 請求項２６に記載のシステムにおいて、前記信頼できる第三者機関は、鍵配信センタ ( KDC) サービス、認証交付機関サービス、およびドメインコントローラサービスを含むサービスグループから選択された、少なくとも１つのサービスを含んでいることを特徴とするシステム。
- 請求項２６に記載のシステムにおいて、前記サーバを認証する信用証明書は、前記サーバに関連するチケット認可チケットを含んでいることを特徴とするシステム。
- 請求項２６に記載のシステムにおいて、前記サーバは、前記サービスに関してフロントエンドサーバであることを特徴とするシステム。
- 請求項２６に記載のシステムにおいて、前記サーバは、前記クライアントと前記サーバに関連するサービスチケットを含んでいるチケット認可サービス要求メッセージで新たなサービス信用証明書を要求することを特徴とするシステム。
- サーバとクライアントを信頼できる第三者機関によって別々に認証するステップと、
サーバチケット認可チケットを前記サーバに前記信頼できる第三者機関から提供するステップと、
前記サーバで使用するためのクライアントチケット認可チケットとサービスチケットを前記信頼できる第三者機関から前記クライアントに提供するステップと、
前記サービスチケットを前記サーバに前記クライアントから提供するステップと、
前記サーバからの要求に応答して、前記サービス信用証明書が代理人に委任できることを前記サービスチケットが示しているか、あるいは前記サービス信用証明書が代理人に委任できるものであるとの表示を前記信頼できる第三者機関が保持しているかのいずれかの場合において、前記クライアントチケット許可チケットのコンテンツにアクセスすることを前記サーバに要求することなしに、また新たなサービスチケットの要求に際して前記クライアントが関与することなしに、新たなサービスを使用するために該新たなサービスにアクセスするときに前記サーバによって使用される新たなサービスチケットを前記信頼できる第三者機関から前記サーバに提供するステップと
を含むことを特徴とする方法。 - 請求項３１に記載の方法において、さらに、
前記サーバチケット認可チケット、前記新サービスを特定する情報、および前記サービスチケットを前記信頼できる第三者機関に転送することによって、前記クライアントに代わって新サービスチケットを前記サーバに要求させることを含むことを特徴とする方法。 - 通信網を介してサーバと信頼できる第三者機関との通信によりクライアントによる委任を制限するシステムであって、
サーバにアクセスするためのサービス信用証明書を信頼できる第三者機関から取得し、ここで該サービス信用証明書を取得することは、前記サービス信用証明書の委任が前記クライアントからサーバに許可されていることを前記サービス証明書に明記させること、あるいは前記サービス信用証明書の委任が前記クライアントからサーバに許可されていることの表示を前記信頼できる第三者機関に保持させること、のいずれか一つによって、前記クライアントに代わって１つまたは複数のアクセスすることを前記サーバに許可することを含み、
前記信頼できる第三者機関から前記サービス信用証明書を受信し、
前記サーバに前記サービス信用証明書を提供し、
前記サーバを介してリソースにアクセスすることを要求する、
ように適合されたクライアントと、
前記サーバには備わっていないターゲットサービスによって前記リソースが提供されることを前記クライアントのために特定し、
前記クライアントに代わって前記ターゲットサービスにアクセスするための新たなサービス信用証明書を前記信頼できる第三者機関に要求し、ここで前記クライアントから該クライアントの認証信用証明書と該クライアントの認証信用証明書を使用する能力を前記サーバに与えないでおかれ、
前記サーバを認証する信用証明書と前記ターゲットサービスに関する情報とを前記信頼できる第三者機関へ提供する、
ように適合されたサーバと、
前記ターゲットサービスにアクセスするための前記サービス信用証明書の委任が許可されていることを該サービス信用証明書が明記しているか、あるいは、前記ターゲットサービスにアクセスするための前記サービス信用証明書の委任が許可されていることの表示を前記信頼できる第三者機関が保持しているかのいずれかの場合に、前記クライアントの関与なしに前記クライアントに代わって前記ターゲットサービスにアクセスするために前記サーバに許可する前記新たなサービス信用証明書を前記サーバに与える信頼できる第三者機関と
を備えることを特徴とするシステム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/886,146 US7698381B2 (en) | 2001-06-20 | 2001-06-20 | Methods and systems for controlling the scope of delegation of authentication credentials |
| US09/886,146 | 2001-06-20 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003099401A JP2003099401A (ja) | 2003-04-04 |
| JP2003099401A5 JP2003099401A5 (ja) | 2005-10-13 |
| JP4298969B2 true JP4298969B2 (ja) | 2009-07-22 |
Family
ID=25388472
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002180423A Expired - Fee Related JP4298969B2 (ja) | 2001-06-20 | 2002-06-20 | 認証信用証明書の委任の有効範囲を制御するための方法とシステム |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US7698381B2 (ja) |
| EP (2) | EP1619856B1 (ja) |
| JP (1) | JP4298969B2 (ja) |
| AT (2) | ATE400130T1 (ja) |
| AU (2) | AU785166B2 (ja) |
| DE (2) | DE60225378T2 (ja) |
Families Citing this family (61)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7444368B1 (en) * | 2000-02-29 | 2008-10-28 | Microsoft Corporation | Methods and systems for selecting methodology for authenticating computer systems on a per computer system or per user basis |
| US7237257B1 (en) * | 2001-04-11 | 2007-06-26 | Aol Llc | Leveraging a persistent connection to access a secured service |
| US20030236977A1 (en) * | 2001-04-25 | 2003-12-25 | Levas Robert George | Method and system for providing secure access to applications |
| US7562146B2 (en) * | 2003-10-10 | 2009-07-14 | Citrix Systems, Inc. | Encapsulating protocol for session persistence and reliability |
| US20050198379A1 (en) * | 2001-06-13 | 2005-09-08 | Citrix Systems, Inc. | Automatically reconnecting a client across reliable and persistent communication sessions |
| US7698381B2 (en) | 2001-06-20 | 2010-04-13 | Microsoft Corporation | Methods and systems for controlling the scope of delegation of authentication credentials |
| US7428749B2 (en) * | 2001-08-03 | 2008-09-23 | International Business Machines Corporation | Secure delegation using public key authorization |
| US7818792B2 (en) * | 2002-02-04 | 2010-10-19 | General Instrument Corporation | Method and system for providing third party authentication of authorization |
| US7661129B2 (en) * | 2002-02-26 | 2010-02-09 | Citrix Systems, Inc. | Secure traversal of network components |
| US7984157B2 (en) * | 2002-02-26 | 2011-07-19 | Citrix Systems, Inc. | Persistent and reliable session securely traversing network components using an encapsulating protocol |
| GB2392590B (en) * | 2002-08-30 | 2005-02-23 | Toshiba Res Europ Ltd | Methods and apparatus for secure data communication links |
| US7546633B2 (en) | 2002-10-25 | 2009-06-09 | Microsoft Corporation | Role-based authorization management framework |
| JP2005064770A (ja) * | 2003-08-11 | 2005-03-10 | Ricoh Co Ltd | 情報処理装置、認証装置、外部装置、証明情報取得方法、認証方法、機能提供方法、証明情報取得プログラム、認証プログラム、機能提供プログラム及び記録媒体 |
| US7827595B2 (en) * | 2003-08-28 | 2010-11-02 | Microsoft Corporation | Delegated administration of a hosted resource |
| US8255422B2 (en) | 2004-05-28 | 2012-08-28 | Microsoft Corporation | Highly reliable and scalable architecture for data centers |
| US7617501B2 (en) | 2004-07-09 | 2009-11-10 | Quest Software, Inc. | Apparatus, system, and method for managing policies on a computer having a foreign operating system |
| GB0419479D0 (en) * | 2004-09-02 | 2004-10-06 | Cryptomathic Ltd | Data certification methods and apparatus |
| US20060236385A1 (en) * | 2005-01-14 | 2006-10-19 | Citrix Systems, Inc. | A method and system for authenticating servers in a server farm |
| US8042165B2 (en) * | 2005-01-14 | 2011-10-18 | Citrix Systems, Inc. | Method and system for requesting and granting membership in a server farm |
| JP4602099B2 (ja) * | 2005-01-25 | 2010-12-22 | 日本電信電話株式会社 | アクセスコード発行システム、アクセスコード発行方法およびアクセスコード発行プログラム |
| WO2007047183A2 (en) * | 2005-10-11 | 2007-04-26 | Citrix Systems, Inc. | Systems and methods for facilitating distributed authentication |
| US7904949B2 (en) * | 2005-12-19 | 2011-03-08 | Quest Software, Inc. | Apparatus, systems and methods to provide authentication services to a legacy application |
| US8087075B2 (en) | 2006-02-13 | 2011-12-27 | Quest Software, Inc. | Disconnected credential validation using pre-fetched service tickets |
| US8429712B2 (en) * | 2006-06-08 | 2013-04-23 | Quest Software, Inc. | Centralized user authentication system apparatus and method |
| WO2008018055A2 (en) * | 2006-08-09 | 2008-02-14 | Neocleus Ltd | Extranet security |
| JP4948119B2 (ja) * | 2006-10-26 | 2012-06-06 | 株式会社リコー | なりすまし防止方法、画像処理装置、なりすまし防止プログラム及び記録媒体 |
| US7895332B2 (en) * | 2006-10-30 | 2011-02-22 | Quest Software, Inc. | Identity migration system apparatus and method |
| US8086710B2 (en) * | 2006-10-30 | 2011-12-27 | Quest Software, Inc. | Identity migration apparatus and method |
| US10068421B2 (en) * | 2006-11-16 | 2018-09-04 | Cfph, Llc | Using a first device to verify whether a second device is communicating with a server |
| US8012015B2 (en) * | 2006-11-15 | 2011-09-06 | Cfph, Llc | Verifying whether a gaming device is communicating with a gaming server |
| US7942740B2 (en) * | 2006-11-15 | 2011-05-17 | Cfph, Llc | Verifying a first device is in communications with a server by storing a value from the first device and accessing the value from a second device |
| US7942742B2 (en) | 2006-11-15 | 2011-05-17 | Cfph, Llc | Accessing identification information to verify a gaming device is in communications with a server |
| US7942741B2 (en) | 2006-11-15 | 2011-05-17 | Cfph, Llc | Verifying whether a device is communicating with a server |
| US7942738B2 (en) | 2006-11-15 | 2011-05-17 | Cfph, Llc | Verifying a gaming device is in communications with a gaming server |
| US7942739B2 (en) | 2006-11-15 | 2011-05-17 | Cfph, Llc | Storing information from a verification device and accessing the information from a gaming device to verify that the gaming device is communicating with a server |
| US9055107B2 (en) * | 2006-12-01 | 2015-06-09 | Microsoft Technology Licensing, Llc | Authentication delegation based on re-verification of cryptographic evidence |
| WO2008114256A2 (en) * | 2007-03-22 | 2008-09-25 | Neocleus Ltd. | Trusted local single sign-on |
| EP2043016A1 (en) * | 2007-09-27 | 2009-04-01 | Nxp B.V. | Method, system, trusted service manager, service provider and memory element for managing access rights for trusted applications |
| US8474037B2 (en) * | 2008-01-07 | 2013-06-25 | Intel Corporation | Stateless attestation system |
| US9973491B2 (en) * | 2008-05-16 | 2018-05-15 | Oracle International Corporation | Determining an identity of a third-party user in an SAML implementation of a web-service |
| US8910257B2 (en) * | 2008-07-07 | 2014-12-09 | Microsoft Corporation | Representing security identities using claims |
| US8863234B2 (en) * | 2008-08-06 | 2014-10-14 | The Boeing Company | Collaborative security and decision making in a service-oriented environment |
| US20100175113A1 (en) * | 2009-01-05 | 2010-07-08 | International Business Machine Corporation | Secure System Access Without Password Sharing |
| US8255984B1 (en) | 2009-07-01 | 2012-08-28 | Quest Software, Inc. | Single sign-on system for shared resource environments |
| US9231758B2 (en) | 2009-11-16 | 2016-01-05 | Arm Technologies Israel Ltd. | System, device, and method of provisioning cryptographic data to electronic devices |
| US10454674B1 (en) * | 2009-11-16 | 2019-10-22 | Arm Limited | System, method, and device of authenticated encryption of messages |
| JP5024404B2 (ja) * | 2010-03-03 | 2012-09-12 | コニカミノルタビジネステクノロジーズ株式会社 | 画像処理システム、情報処理装置、プログラムおよびジョブ実行方法 |
| US20120072972A1 (en) * | 2010-09-20 | 2012-03-22 | Microsoft Corporation | Secondary credentials for batch system |
| AU2010246354B1 (en) * | 2010-11-22 | 2011-11-03 | Microsoft Technology Licensing, Llc | Back-end constrained delegation model |
| US8839357B2 (en) * | 2010-12-22 | 2014-09-16 | Canon U.S.A., Inc. | Method, system, and computer-readable storage medium for authenticating a computing device |
| US8701169B2 (en) | 2011-02-11 | 2014-04-15 | Certicom Corp. | Using a single certificate request to generate credentials with multiple ECQV certificates |
| US8973108B1 (en) * | 2011-05-31 | 2015-03-03 | Amazon Technologies, Inc. | Use of metadata for computing resource access |
| US9058467B2 (en) | 2011-09-01 | 2015-06-16 | Microsoft Corporation | Distributed computer systems with time-dependent credentials |
| US8640210B2 (en) | 2011-09-01 | 2014-01-28 | Microsoft Corporation | Distributed computer systems with time-dependent credentials |
| US9032492B2 (en) | 2011-09-01 | 2015-05-12 | Microsoft Corporation | Distributed computer systems with time-dependent credentials |
| US9047456B2 (en) * | 2012-03-20 | 2015-06-02 | Canon Information And Imaging Solutions, Inc. | System and method for controlling access to a resource |
| GB2512062A (en) * | 2013-03-18 | 2014-09-24 | Ibm | A method for secure user authentication in a dynamic network |
| US9762563B2 (en) | 2015-10-14 | 2017-09-12 | FullArmor Corporation | Resource access system and method |
| US9450944B1 (en) | 2015-10-14 | 2016-09-20 | FullArmor Corporation | System and method for pass-through authentication |
| US9509684B1 (en) * | 2015-10-14 | 2016-11-29 | FullArmor Corporation | System and method for resource access with identity impersonation |
| CN108737093B (zh) * | 2017-04-13 | 2022-07-12 | 山东量子科学技术研究院有限公司 | 一种加密的方法、装置及系统 |
Family Cites Families (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5586260A (en) | 1993-02-12 | 1996-12-17 | Digital Equipment Corporation | Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms |
| US5590199A (en) | 1993-10-12 | 1996-12-31 | The Mitre Corporation | Electronic information network user authentication and authorization system |
| US5764890A (en) | 1994-12-13 | 1998-06-09 | Microsoft Corporation | Method and system for adding a secure network server to an existing computer network |
| US5864665A (en) | 1996-08-20 | 1999-01-26 | International Business Machines Corporation | Auditing login activity in a distributed computing environment |
| US5684950A (en) * | 1996-09-23 | 1997-11-04 | Lockheed Martin Corporation | Method and system for authenticating users to multiple computer servers via a single sign-on |
| US5875296A (en) | 1997-01-28 | 1999-02-23 | International Business Machines Corporation | Distributed file system web server user authentication with cookies |
| US5923756A (en) * | 1997-02-12 | 1999-07-13 | Gte Laboratories Incorporated | Method for providing secure remote command execution over an insecure computer network |
| US6453419B1 (en) | 1998-03-18 | 2002-09-17 | Secure Computing Corporation | System and method for implementing a security policy |
| US6199113B1 (en) * | 1998-04-15 | 2001-03-06 | Sun Microsystems, Inc. | Apparatus and method for providing trusted network security |
| US6405312B1 (en) | 1998-09-04 | 2002-06-11 | Unisys Corporation | Kerberos command structure and method for enabling specialized Kerbero service requests |
| US6298383B1 (en) * | 1999-01-04 | 2001-10-02 | Cisco Technology, Inc. | Integration of authentication authorization and accounting service and proxy service |
| US6601171B1 (en) | 1999-02-18 | 2003-07-29 | Novell, Inc. | Deputization in a distributed computing system |
| US6643774B1 (en) * | 1999-04-08 | 2003-11-04 | International Business Machines Corporation | Authentication method to enable servers using public key authentication to obtain user-delegated tickets |
| US6653419B1 (en) | 1999-05-04 | 2003-11-25 | E. .I Du Pont De Nemours And Company | Polyfluorinated epoxides and associated polymers and processes |
| US6769068B1 (en) * | 1999-09-02 | 2004-07-27 | International Business Machines Corporation | Dynamic credential refresh in a distributed system |
| US6401211B1 (en) * | 1999-10-19 | 2002-06-04 | Microsoft Corporation | System and method of user logon in combination with user authentication for network access |
| US6678733B1 (en) | 1999-10-26 | 2004-01-13 | At Home Corporation | Method and system for authorizing and authenticating users |
| US7113994B1 (en) * | 2000-01-24 | 2006-09-26 | Microsoft Corporation | System and method of proxy authentication in a secured network |
| DE60124458D1 (de) | 2000-06-30 | 2006-12-28 | Microsoft Corp | Vorrichtungen und Verfahren für delegierte Zugangsberechtigung von Zusammenfassungsinformation |
| US20020150253A1 (en) | 2001-04-12 | 2002-10-17 | Brezak John E. | Methods and arrangements for protecting information in forwarded authentication messages |
| US7698381B2 (en) | 2001-06-20 | 2010-04-13 | Microsoft Corporation | Methods and systems for controlling the scope of delegation of authentication credentials |
| US7246230B2 (en) | 2002-01-29 | 2007-07-17 | Bea Systems, Inc. | Single sign-on over the internet using public-key cryptography |
| US20030188193A1 (en) | 2002-03-28 | 2003-10-02 | International Business Machines Corporation | Single sign on for kerberos authentication |
| US7401235B2 (en) | 2002-05-10 | 2008-07-15 | Microsoft Corporation | Persistent authorization context based on external authentication |
-
2001
- 2001-06-20 US US09/886,146 patent/US7698381B2/en not_active Expired - Fee Related
-
2002
- 2002-05-14 DE DE60225378T patent/DE60225378T2/de not_active Expired - Lifetime
- 2002-05-14 AT AT05020603T patent/ATE400130T1/de not_active IP Right Cessation
- 2002-05-14 EP EP05020603A patent/EP1619856B1/en not_active Expired - Lifetime
- 2002-05-14 AT AT02010767T patent/ATE388564T1/de not_active IP Right Cessation
- 2002-05-14 DE DE60227427T patent/DE60227427D1/de not_active Expired - Lifetime
- 2002-05-14 EP EP02010767A patent/EP1271882B1/en not_active Expired - Lifetime
- 2002-05-21 AU AU42425/02A patent/AU785166B2/en not_active Ceased
- 2002-06-20 JP JP2002180423A patent/JP4298969B2/ja not_active Expired - Fee Related
-
2007
- 2007-01-11 AU AU2007200114A patent/AU2007200114B2/en not_active Ceased
Also Published As
| Publication number | Publication date |
|---|---|
| DE60225378T2 (de) | 2009-03-26 |
| EP1619856B1 (en) | 2008-07-02 |
| AU2007200114B2 (en) | 2009-08-27 |
| ATE400130T1 (de) | 2008-07-15 |
| ATE388564T1 (de) | 2008-03-15 |
| US20030018913A1 (en) | 2003-01-23 |
| DE60227427D1 (de) | 2008-08-14 |
| DE60225378D1 (de) | 2008-04-17 |
| AU785166B2 (en) | 2006-10-12 |
| EP1619856A1 (en) | 2006-01-25 |
| EP1271882A3 (en) | 2004-09-29 |
| JP2003099401A (ja) | 2003-04-04 |
| US7698381B2 (en) | 2010-04-13 |
| AU2007200114A1 (en) | 2007-02-01 |
| EP1271882A2 (en) | 2003-01-02 |
| EP1271882B1 (en) | 2008-03-05 |
| AU4242502A (en) | 2003-01-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4298969B2 (ja) | 認証信用証明書の委任の有効範囲を制御するための方法とシステム | |
| JP4756817B2 (ja) | アクセス制御を提供する方法、記録媒体及びアクセスを制御するシステム | |
| US7716722B2 (en) | System and method of proxy authentication in a secured network | |
| JP5243593B2 (ja) | 動的ネットワークにおけるセキュリティリンク管理 | |
| KR101150108B1 (ko) | 피어-투-피어 인증 및 허가 | |
| KR101534890B1 (ko) | 신뢰된 장치별 인증 | |
| US6401211B1 (en) | System and method of user logon in combination with user authentication for network access | |
| US7774611B2 (en) | Enforcing file authorization access | |
| US8209394B2 (en) | Device-specific identity | |
| EP2321760B1 (en) | Representing security identities using claims | |
| GB2440425A (en) | Single sign-on system which translates authentication tokens | |
| AU2753402A (en) | Methods and arrangements for protecting information in forwarded authentication messages | |
| EP2077019A1 (en) | Secure access | |
| Namlı et al. | Implementation experiences on ihe xua and bppc |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050607 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050607 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20050607 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080527 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20080826 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20080829 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20080929 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20081002 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081027 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081202 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090302 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090324 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090416 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4298969 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120424 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120424 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130424 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130424 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140424 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |