JP2004537090A - 連合認証サービス - Google Patents
連合認証サービス Download PDFInfo
- Publication number
- JP2004537090A JP2004537090A JP2002580193A JP2002580193A JP2004537090A JP 2004537090 A JP2004537090 A JP 2004537090A JP 2002580193 A JP2002580193 A JP 2002580193A JP 2002580193 A JP2002580193 A JP 2002580193A JP 2004537090 A JP2004537090 A JP 2004537090A
- Authority
- JP
- Japan
- Prior art keywords
- authentication
- client
- subject
- agent
- protocol proxy
- 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.)
- Pending
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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0281—Proxies
-
- 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/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
-
- 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/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
-
- 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
- H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Storage Device Security (AREA)
Abstract
ネットワークのサブジェクトドメイン（１２）にあるサブジェクト（２０）を、サーバドメイン（１８）にあるサーバアプリケーション（３８）に対して認証するために連合認証サービス技術である。認証ドメイン（１６）にある認証メカニズム（３２）はサーバアプリケーション（３８）が提供するサービスに影響を与える。クライアント（２２）はサブジェクト（２０）を認証し、プロトコルプロキシ（３４）は認証メカニズムとの媒介を行って、クライアントがサーバアプリケーション（３８）にアクセスするために用いることのできるネームアサーションを取得する。なお、サブジェクトが人間でない場合には、クライアントはサブジェクトに組み込まれていてもよい。複数の認証メカニズムがある場合には、任意選択でエージェント（２４）とメカニズム決定プロセス（２６）とメカニズムレポジトリ（２８）とを用いて、一つの適切な認証メカニズム（３２）を決定してもよい。なおこれらエージェント（２４）とメカニズム決定プロセス（２６）とメカニズムレポジトリ（２８）とはすべてエージェントドメイン（１４）にある。
【選択図】図１
【選択図】図１
Description
【技術分野】
【０００１】
本発明は広くはコンピュータネットワークの安全な使用に関わるものであり、詳しくは、認証のタイプや認証ソース(authentication source)が複数ある場合に情報システム内のセキュリティを効率よく保つことに関わる。
【背景技術】
【０００２】
今日のデジタル社会においては、情報システムとそのコンテンツは組織の最も貴重な資産の一つである。各組織は自身のデータを権限のないアクセスから守ることに少なからぬ出費をしている。同時に組織は、総括的なビジネス上の要請から、ビジネスパートナーや顧客、納入業者、そして時には競争相手や対抗者とも情報を共有する。このためには認証手続きが必要である。
【０００３】
認証が最も重要となるのは、それがアクセス制御規則を行使するための基盤となる局面である。すなわち、システムがあるサブジェクトにどういう行為を許可するかを決定するためには、システムはまずそのサブジェクトが何者であるかを確かめなければならないということである。
【０００４】
従来の認証システムはたいていの場合、単一の認証ソースおよび認証タイプを想定している。例えばKerberos（ケルベロス）においては、認証ソースは信頼されたキーディストリビューションセンター（key distribution center: KDC）であり、認証タイプはユーザーIDとパスワードである。（Kerberosのバージョン５はパブリックキー（公開鍵）に基づく初期認証をサポートしているが、Kerberosが商業的に利用されているケースの多くのものがユーザーIDとパスワードに基づいて認証を行っている。）別の例としてパブリックキーインフラストラクチュア（PKI）システムがある。そこでの認証ソースは証明機関（certificate authority: CA）であり、認証タイプは問いかけ／応答(challenge/response)である。KerberosとPKIは共に複数の認証ソースを許容しはするが、それらの認証ソースは緊密に結合されたものでなければならない。このことは多くの場合、認証ソース間に複雑な信頼関係があることを意味し、これは実際上実行不可能であり、かつ経済的にコストの非常に高いソリューション（解決方法）となる
【０００５】
新たな認証システムであって、ここでの議論において後に特別の重要性を持つものとして、セキュアリモートパスワード（secure remote pass word: SRP）プロトコルがある。SRPの唱道者である発明者のTom Wuとスタンフォード大学は「クライアントが（パスワードの如き）小さなシークレット（secret:秘密）を記憶しなければならず、かつその他の秘密情報を持たず、サーバは、サーバがクライアントを認証できるが、危険な状況になった時にも何者かがクライアントを偽装することを許さないような証明手段を有するようなケースにおいて、クライアント対サーバの問題を安全に解決する」と述べている。しかし、SRPは従来の認証システムと同様に、単一の認証ソースとタイプを前提としている。
【０００６】
組織内および組織間通信の実情を見れば、単一の認証タイプということはあり得ないことがわかる。実際、Giga Groupが２００１年に出版したレポートによれば、企業はパスワード、トークン、証明書(certificate)、スマートカードなどの複数の認証タイプをサポートするであろうとされている。従って、セキュリティ体系は、各々の認証タイプにたいして別々のインフラストラクチュアを有するのではなく、すべての認証タイプを処理する単一のインフラストラクチュアを有するべきである。いつの日にかは単一の認証タイプ（例えばバイオメトリックス）となるとしても、各々が一群のサブジェクトの管理制御をおこなう複数の認証ソースは常に存在し続けるであろう。
【０００７】
従って、アクセス制御を実行しようとする情報システムは、いかなる数のソースからも認証情報を受け入れられるように構成されていなければならない。実際アクセス制御の実行に当たって鍵となる基準は、認証の正確なソースとタイプを含む。実際のモデルにおいては、多くの認証ソースが連合体(federation)を形成する必要があり、その連合の各成員は一群のサブジェクトの信頼性を確認できる必要がある。
【０００８】
必要となるのは、組織が、組織自身、またはその顧客、パートナー、納入業者、その他の第三者に所属する認証ソースを利用することを可能とする技術である。我々はこのような技術を連合認証サービス技術（Federated Authentication Service Technology: FAST）と名付け、その目的を組織が高度に安全な情報システムを介してビジネス関係を形成することを可能にすることとする。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
従って本発明の一つの目的は、連合認証サービス技術(FAST)を提供し、組織が高度に安全な情報システムを介してビジネス関係を形成することを可能にすることである。
【００１０】
本発明の別の目的は複数の認証タイプおよび異なる制御ドメインからの複数の認証ソースを利用できる認証システムを提供することである。
【００１１】
本発明の別の目的は、組織がユーザーやサーバへの影響なしにその認証機構を改変できるようにする認証システムを提供することである。
【００１２】
本発明の別の目的は、組織の既存のセキュリティ・インフラストラクチュアを利用してビジネス関係を迅速に形成しながら、厳格なセキュリティ条件を提供する認証システムを提供することである。
【００１３】
本発明の別の目的はユーザーおよびサービスプロバイダが認証場所を選択できる認証システムを提供することである。
【課題を解決するための手段】
【００１４】
略述すると、本発明の好適な実施形態は、ネットワークの認証ドメインにある認証メカニズムがサーバアプリケーションの提供するサービスに作用する(affect:なんらかの影響を与える)場合において、ネットワークのサブジェクトドメインにあるサブジェクトをネットワークのサーバドメインにあるサーバアプリケーションに対して認証するためのシステムである。このシステムは他の構成要素と通信しかつサブジェクトを代理してクライアントのネームアサーションを与えることによってサブジェクトを認証するクライアントを含む。このクライアントもまたサブジェクトドメインにある。このシステムは、クライアントと認証メカニズムとの間で通信を行い、クライアントのクリデンシャルに基づいてクライアントを認証し、クライアントのサーバアプリケーションへのアクセスを許可するための認証ネームアサーションをクライアントのクリデンシャルに基づいて作成するプロトコルプロキシを更に含む。
【発明の効果】
【００１５】
本発明の一つの利点は、複数の認証タイプおよびソースを抽象化する(abstract)ことにより複数の認証タイプおよび認証ソースの使用が可能となることである。既存の認証技術は複数の認証タイプ（たとえばユーザID／パスワード、バイオメトリックス、デジタル証明書など）を許容する。しかし、これら既存の技術は複数の認証ソース（例えば雇い主、金融機関、医療サービス提供者など）を抽象化することはない。
【００１６】
本発明の別の利点はサーバの選択するどのメカニズムに対しても認証を行うことができる点である。サーバの認証メカニズムはクライアントの認証メカニズムとは全く独立している。
【００１７】
本発明の別の利点はクライアント、サーバアプリケーション、認証メカニズムによって要求されるクリデンシャルの期限切れに関して融通性があることである。
【００１８】
本発明の別の利点は異なるドメインからの認証をサポートし、全世界的な単一サインオンを可能とすることである。
【００１９】
本発明の別の利点はクリデンシャルの管理場所を単一として、管理を容易とし、かつ安全性の高い配備を可能とする点である。
【００２０】
本発明の別の利点は安全性の高い構成要素間プロトコルを用いていることである。これにより、多くの異なる配備計画が可能となり、管理されたセキュリティサービスを提供する。
【００２１】
本発明の別の利点は認証メカニズムを選ばないことである。これにより、既存の認証メカニズムへの組織の投資を保護しながら、将来の認証メカニズムをシームレスに取り込むことができる。
【００２２】
本発明の別の利点は信用の階層(hierarchy)を可能とすることである。本発明は、それら自身を認証するための認証メカニズムを必要とする。かくしてユーザは秘密事項に係るクリデンシャルを認証メカニズムに対してのみ開示すればよい。またサーバアプリケーションは認証メカニズムのアサーションのみを信頼すればよい。
【００２３】
本発明の別の利点はネームアサーションを用いた署名の作成および検証を可能とすることである。これにより、これにより署名の作成および検証にデジタル証明書を用いる必要がなくなり、署名作成および検証のスピードと効率が向上する。
【００２４】
本発明の別の利点はネームアサーションを用いて既存のネームアサーションを更新することを可能とすることである。これにより認証が必要となる度毎にデジタル証明書を用いる必要がなくなり、認証プロセスのスピードと効率が向上する。
【００２５】
本発明の別の利点はスタンダードに準拠していることである。これによりアプリケーションと現存および将来のセキュリティシステムと間の相互運用性を助成する。
【００２６】
本発明の別の利点はパブリックキーインフラストラクチュア(PKI)方式を用いかつ改善することができることである。本発明は長命のデジタル証明書を束の間の証明書（ネームアサーション）に変える。従って全体的な管理を最小のものとする。より詳しくは、本発明によって、PKIの普及の妨げとなっていたサーバによる失効証明書リスト(CRLs)の確認プロセスは不要なものとなる。
【００２７】
本発明の別の利点はKerberosを用いかつ改善することができることである。Kerberosにおいてはクライアントはあるサーバに最初に接触する度毎にKerberos認証メカニズムと通信しなければならなかった。本発明で用いられるネームアサーションは普遍的なものであり、それらネームアサーションを用いてどのサーバに対しても身元を証明することができる。従って一つのネームアサーションをどのサーバにも提示することができる。これによりクライアントが異なるサーバと通信しようとする度毎に認証メカニズムに接触する必要がなくなる。
【００２８】
本発明の別の利点はセキュアリモートパスワード(SRP)のユーティリティを用いかつ改善することができることである。SRPはサーバに対するクライアントの認証を可能にするがサーバをクライアントに対して強力に認証することはない。本発明は強力な相互認証プロトコルを導入することにより、この点を改善する。
【００２９】
本発明の別の利点は既存の認証技術とは異なって、なめらかな移行が可能であることである。既存の認証技術ではすべてのユーザおよびサーバにおいて当該技術を有効化することが必要であるため、企業全体で当該技術を完全導入するか導入しないかの二者択一となってしまう。本発明を用いれば、ある組織はそのユーザやサーバに影響を与えることなく認証メカニズムを変更することができる。
【００３０】
本発明の別の利点は構成が簡単で、そのアーキテクチュアを非常に簡単に導入することができ、バラエティに富んだ導入計画が可能であることである。
【００３１】
本発明を実施する現在知られている最適な態様およびその好適な実施態様の産業上の利用可能性についての以下における説明および図面における図示を参照することにより、当業者は本発明の上記およびその他の目的や利点を理解するであろう。
【発明を実施するための最良の形態】
【００３２】
本発明の諸目的および諸利点は添付の図面に関連してなされる以下の詳細な説明から明らかになるであろう。
【００３３】
本発明の好適な実施形態は連合認証サービス技術(FAST)である。様々な図面、特に図１に示すように、本発明の好適な実施形態は参照符号１０によって示されている。以下の議論の理解を助けるために「産業上の利用可能性」の項目の後に用語解説が付加されている。
【００３４】
図１はFAST１０が、ネットワークの異なる管理ドメインを横断して実行する一群の協働する要素をどのように含んでいるかを描いており、境界を破線で示している。ここで、サブジェクトドメイン１２はエージェントドメイン１４、認証ドメイン１６およびサーバードメイン１８に接するものとして描かれている。サブジェクトドメイン１２はサブジェクト２０（必ずしも人間ではない）およびクライアントアプリケーションおよびアプレット（クライアント２２）を含んでいる。エージェントドメイン１４は認証エージェント２４，メカニズム決定プロセス２６、メカニズムレポジトリ（メカニズム格納所）２８、メカニズム登録プロセス３０を含んでいる。認証ドメイン１６は認証メカニズム３２およびプロトコルプロキシ３４（これは認証ドメイン１６内に設けてもよい）を含んでいる。サーバードメイン１８はサーバーアプリケーション３８を含んでいる。
【００３５】
サブジェクトドメイン１２からサーバドメイン１８へのアクセスの取得が所望される。このようなアクセスは認証ドメイン１６において承認が成立し、エージェントドメイン１４が承認を補助することに基づいて行われる。要点を提示するために図１およびその説明はある程度簡略化しているが、これから説明するように、FAST１０の典型的な実施形態は多くのサブジェクト２０，認証メカニズム３２，サーバアプリケーション３８を含んでおり、それらすべてが一つの認証エージェント２４のサービスを用いている。複数の同様の種類の存在がある場合には、それらの各々がそれぞれのドメインとして取り扱われる。
【００３６】
図１についてより詳しく説明する前に、「ネームアサーション(name assertion: 名称言明)」と呼ばれる中核概念のFAST１０における役割を理解することが有用である。ネームアサーションはクリデンシャル（credential: 信用証明）の一種である。より詳しく言えば、実際の実施において、それは主張された身元（identity）を確立するために提示することのできる身元の宣言を含むデジタル署名されたデータ構造である、
【００３７】
FAST１０はセキュアリモートパスワード（SRP）プロトコルを用いて、ネームアサーションを提示する存在を認証する。FAST１０においてこれはネームアサーションにSRPベリファイア（verifier）を含ませ、そして自身を認証（証明authenticate）しなければならない当該存在にSRPシークレット(secret)を与えることによって成し遂げられる。このようにすれば、たとえばクライアント２２がサーバアプリケーション３８にネームアサーションを提示した際に、サーバアプリケーション３８はネームアサーションからSRPベリファイアを取り込み、かつSRP方式を用いてクライアント２２がSRPシークレットを有していることを証明するように要求する。
【００３８】
ここで図１の詳しい説明に戻る。図１はFAST１０における認証の全体的な流れを示している。一連のステップすなわちステップ４０〜５２は実際の認証プロセスであり、これらは常にではないが、サブジェクト２０がサーバアプリケーション３８に対して認証される必要のある度毎に行われる。これに対し、ステップ５６〜５８は登録プロセスであり、これらは認証メカニズム３２がエージェントドメイン１４において自身を登録するまたは更新する場合（メカニズムレポジトリ２８を変更する場合）にのみ行われる。
【００３９】
ステップ４０において、自身を認証しなければならないサブジェクト２０は、クライアント２２を用いてサーバアプリケーション３８へのアクセスを取得するプロセスを開始する。ここではクライアント２２とサブジェクト２０は別物として示しているが、サブジェクト２０がクライアント機能を一体的に有している場合、すなわちサブジェクト２０が人間でない場合にはこの限りではないことを理解されたい。
【００４０】
ステップ４２において、クライアント２２は認証エージェント２４に接触し、認証エージェント２４にサブジェクト２０の名称とドメインを送る。クライアント２２はオプションとして特定の認証メカニズム３２の名称およびその他のデータ（一般的には、認証メカニズムが提供することのできる方法および認証のストレングスを適宜の場合に含む）をも送ることができる。クライアント２２と認証エージェント２４との間のやりとり（相互作用）が成立するとクライアント２２が用いるべきただ一つの認証メカニズム３２についての情報が生成される。そうでない場合は、認証エージェント２４はクライアント２２の要求に合致する認証メカニズムが存在しないことを示すエラー状態を返信する。
【００４１】
ステップ４４において、認証エージェント２４はメカニズム決定プロセス(mechanism resolution process)２６を用いてクライアント２２に対する適切な認証メカニズム３２を決定する。適切なものが２つ以上ある場合には、認証エージェント２４はクライアント２２との間でのプロトコルを用いて（上記ステップ４２）ただ一つだけの認証メカニズム３２を決定する。
【００４２】
ステップ４６において、メカニズム決定プロセス２６はメカニズムレポジトリ２８を用いて、適切な認証メカニズム３２についての情報を取り込む。その後この情報は最終メカニズム決定としてクライアント２２に送ることができる。
【００４３】
ステップ４８において、クライアント２２はサーバアプリケーション３８へのアクセスのための認証要求を、標準の安全なプロトコル(standard secure protocol)を用いてプロトコルプロキシ３４に通信する。この通信は認証エージェント２４およびエージェントドメイン１４のいかなる部分も介する必要なく行われることに注目すべきである（しかし、場合によってはここで説明しているような仕方でそれを介してもよい）。
【００４４】
ステップ５０において、プロトコルプロキシ３４はクライアント２２からの認証要求を受信し、それを認証メカニズム本来のプロトコルに変換する。従って、各々のタイプの認証プロクシ３２に対して１つのプロトコルプロキシ３４が存在しうる。続いてプロトコルプロキシ３４は変換された要求を認証メカニズム３２に通信する。認証が成功すれば、プロトコルプロキシ３４は認証メカニズムからサブジェクト２０の属性(attributes)とアクセス権を含む応答を受信する。プロトコルプロキシ３４は次にネームアサーションおよびオプションとしてエンタイトルメント（entitlement: 権利付与）を生成する。プロトコルプロキシ３４はこれを認証応答に変換し、クライアント２２に返送する。
【００４５】
ステップ５２において、クライアント２２は該認証応答をサーバアプリケーション３８に送信する。クライアント２２およびサーバアプリケーション３８はクライアントが該ネームアサーションの正式の所有者であることを証明するプロトコルに入る。
【００４６】
前に述べたように、上記のステップ４０〜５２は一般的に（常にではないが）サブジェクト２０がサーバアプリケーション３８に対して自身を認証しなければならない場合ごとに行われる。ネームアサーションが再利用可能である限り、サブジェクト２０はそれをサーバアプリケーション３８に何度でも提示することができる。認証メカニズム３２を最初に登録する際には、以下のステップ５６〜５８が用いられる。
【００４７】
ステップ５６において、認証メカニズム３２はメカニズム登録プロセス３０に接触し、登録を開始する。
【００４８】
ステップ５８において、メカニズム登録プロセス３０は認証メカニズム３２についての情報をメカニズムレポジトリ２８に入力する。その後はステップ４０〜５２が運用可能となる。プロトコルプロキシ３４がすでに認証メカニズム３２によって利用可能である場合もあり、またはこれらの登録ステップの間にメカニズム登録プロセス３０がプロトコルプロキシ３４を提供するすなわち利用可能となす場合もある。
【００４９】
FAST１０の各要素はFAST１０内の他の要素と通信する場合に用いるプロトコルを持っている。サブジェクト２０は環境仕様(environment-specific)のデバイスを用いて自身を認証する。FAST１０は環境によらない(environment-agnostic)ので、サブジェクト２０はいかなる環境でいかなるタイプのクリデンシャルを用いて認証を行ってもよい。このようなクリデンシャルのいくつかの例としては、コンピュータや手持ち（ハンドヘルド）デバイスのID/パスワード、デジタル証明書および関連するプライベートキー、そして指紋や虹彩走査などのバイオメトリックデータ（生体測定データ）などがある。
【００５０】
クライアント２２はサブジェクト２０が自身を認証することを補助するアプリケーションまたはアプレットである。クライアント２２は環境仕様のプラットフォームで動作し必要なクリデンシャルを作り出すデバイスと相互作用（やりとり）する。例えばクライアント２２はバイオメトリックデバイスと相互作用して指紋データを収集する。
【００５１】
サブジェクトはいくつもの異なるやり方でクライアントを入手することができる。たとえば、サブジェクト２０はあらかじめクライアント２２を備えていてもよいし、またはクライアント２２を認証エージェント、サーバアプリケーション３８その他の場所から「急場で(on the fly)」」ダウンロードしてもよい。
【００５２】
上に述べたように、クライアント２２は最適な認証メカニズム３２を決定するために認証エージェント２４とやりとりする。認証エージェント２４は１つ以上の適切な認証メカニズム３２を返信する場合がある。クライアント２２は従ってどの１つの認証メカニズムを用いるべきかをその場で決定することを可能とするコールバックメカニズムを有してもよい。例えば、コールバックメカニズムはサブジェクト２０と相互作用（やりとり）してこれを決定してもよいし、またはコンフィギュレーションレポジトリ(configuration repository：構成情報レポジトリ)に問い合わせてもよい。
【００５３】
認証エージェント２４はクライアント２２とメカニズム決定プロセス２６とを仲介する。クライアントは最低でも認証エージェント２４にサブジェクト２０の名称とドメインを送らなければならないが、その他の情報をオプションとして送ってもよい。認証エージェント２４はこの情報を用いて適切な認証メカニズムを決定する。認証エージェント２４は次いで認証メカニズム３２を特定する情報をクライアントに返送する。一つ以上の認証メカニズムが提供された場合には、クライアント２２はコールバックメカニズムを用いてただ一つを選択する。
【００５４】
クライアント２２が認証エージェント２４の補助なしに認証メカニズム３２を選択する場合には特定のプロセスが準備されている。例えば、クライアント２２はサブジェクト２０とやりとりして認証メカニズム３２を選択することができる。この場合、クライアント２２は２つの選択肢を有する。第１の選択肢では、クライアント２２は所望の特定認証メカニズム３２の要求を認証エージェント２４に送る。次に認証エージェント２４はその認証メカニズム３２が実際にサブジェクト２０を認証するものであるかどうかを単にチェックして確かめる。第２の選択肢では、クライアント２２はプロトコルプロキシ３４に直接接触して認証メカニズム３２との認証プロセスを開始してよい。この場合メカニズム決定プロセス２６は効率的に省略される。
【００５５】
メカニズム決定プロセス２６は「ブラックボックス」プロセスである。好適な実施形態において、該プロセスはXML形式の入力ドキュメントを受信しゼロまたは１つ以上の認証メカニズム３２のリストを作成する。入力ドキュメントは少なくともサブジェクト２０の名称とドメインとを含む。入力ドキュメントを拡充して一群の認証メカニズム３２の選択を補助する他のデータ（例えば認証ストレングス）を含むようになすこともできる。例えば、サブジェクト２０として、「A.com」において仕事上のアカウントを有し、その他の「B.com」「C.com」等々において様々なアカウントを有するJohn Doe氏を考える。Doe氏は仕事上の立場でZ.comのリソースにアクセスする必要がある場合があり、この場合「JohnDoe@A.com」として認証する必要がある。このためにはZ.comのための適切な認証メカニズム３２の決定が必要とされるが、これはたとえば「＊＠A.com」というマスクを用いて設定され、リソース要求が特定の認証メカニズムを用いるように仕向けてもよい。
【００５６】
メカニズムレポジトリ２８は認証メカニズムについての情報を有するデータベースである。ここで注意すべきことは、「メカニズム」は、各認証メカニズム３２のプロトコルプロキシ３４とどのように接触し協働するか、すなわち例えばどのURLを用いてそこに行くかなどについて正確に特定しているということである。メカニズム決定プロセス２６およびメカニズム登録プロセス３０はメカニズムレポジトリ２８を用いて、認証メカニズム３２をそれぞれ決定および登録する。
【００５７】
メカニズム登録プロセス３０は、認証メカニズム３２がメカニズムレポジトリ２８に自身を登録するため、あるいはメカニズムレポジトリ２８内の自身の情報を変更するために用いるものである。認証に比べると、メカニズム登録プロセス３０は行われる頻度が低い。
【００５８】
各プロトコルプロキシ３４は認証メカニズム３２とクライアント２２とを媒介する。この好適な実施形態では、プロトコルプロキシ３４はクライアント２２と通信にはＸＭＬで表現された標準セキュリティのプロトコルを用い、それぞれに対応する認証メカニズム３２との通信には通信メカニズムに固有のプロトコルを用いる。
【００５９】
認証が成功した場合、認証の最後にプロトコルプロキシ３４はネームアサーション、およびオプションとしてエンタイトルメントを含む署名されたドキュメントを作成する。その例が付録Ａに示されている。
【００６０】
各プロトコルプロキシ３４はそれ自身が信頼できるもの（authentic）であって、有効なネームアサーションを持つものでなければならない。このように、クライアント２２がプロトコルプロキシ３４に対して開示しなければならないのは、秘密事項に係るクリデンシャルのみである。更にサーバアプリケーション３８は、信頼性のあるプロトコルプロキシ３４の作成したネームアサーションのみを信頼すればよい。従ってプロトコルプロキシ３４は自分自身のネームアサーションを用いてクライアント２２を認証し、その認証メカニズム３２に代わって作成したネームアサーションとエンタイトルメントとに署名する。（これについては以下にまた説明する。）
【００６１】
認証メカニズム３２は特定のプロトコルに従ってサブジェクト２０を認証するプロセスである。しかし、プロトコルプロキシ３４はこのために用いられれる認証メカニズム３２の特定のプロトコルをサブジェクト２０およびクライアントに対して秘匿する。従って、認証メカニズム３２は完全に従来型のものであってもよく、その場合でも複数の認証タイプ、認証ソースの方式全体と共に機能することが可能である。これは本発明のFAST１０の提供する大きな利点である。
【００６２】
各ネームアサーションはSRPベリファイアを含んでいる。ネームアサーションの正当な所有者は対応するSRPシークレットを所有している。SRPベリファイアとSRPシークレットを用いれば、任意の二者はSRPプロトコルを用いて互いを認証することができる。FAST１０においては、SRPプロトコルを拡張して任意の二者間での相互認証を可能とする（すなわちクライアント２２とサーバアプリケーション３８の間、クライアント２２とプロトコルプロキシ３４との間等々）。
【００６３】
各ネームアサーションは一群の公開値(public values)を含む。FAST１０において、これら公開値の使用は署名検証のために拡張される。即ち、ネームアサーションの所有者はSRPシークレットを用いて自分自身を認証し、デジタル署名を作成することができる。この所有者がネームアサーションを提示する提示先はこれを用いて所有者を認証しかつ所有者のデジタル署名を検証(verify)することができる。
【００６４】
ネームアサーション自体はこれを作成したプロトコルプロキシ３４によって署名されているので、所有者の署名はその認証された身元(identity)に拘束される。また、ネームアサーションは束の間のものであるから証明書失効リスト(certificate revocation list: CRL)の必要はない。デジタル証明書を用いてそのサブジェクト２０を認証する認証メカニズム３２はネームアサーション有効期間を次のCRL作成と一致するように細かく設定することができる。かくして、サブジェクト２０は次のCRLが発行される以前に自分自身を再認証しなければならない。
【００６５】
クライアント２２はプロトコルプロキシ３４（これは認証メカニズム３２を代理する）を信頼する必要がある。これはクライアント２２から秘密のクリデンシャルを受け取るプロトコルプロキシ３４の場合は特にそうである。従ってプロトコルプロキシ３４はメカニズム−認証メカニズム（メカニズムを認証するメカニズム）に対して認証しなければならない。この種の認証はいずれかの認証メカニズム３２におけるクライアント２２の認証と同一である。その結果として、プロトコルプロキシ３４がクライアント２２との相互認証に入り認証するクライアント２２にたいしてネームアサーションに署名するために用いるネームアサーションが得られる。
【００６６】
プロトコルプロキシ３４がメカニズム−認証メカニズムにおいて認証するとき、プロトコルプロキシ３４はどのクライアント２２もが行うのと同様のネームアサーションを受け取る。このようなネームアサーションはメカニズム−認証メカニズムによって署名されている（より正確に言えば、メカニズム−認証メカニズムに先立って、認証を必要としている、すなわち一時的にクライアント２２として振る舞っているプロトコルプロキシ３４との間の媒介を行っているプロトコルプロキシ３４によって署名されている）。クライアント２２は、メカニズム−認証メカニズムによって提供されたプロトコルプロキシ３４のネームアサーションの署名を検証してその認証性を確かめることができる。これはデジタル証明書の連鎖を検証するのと同様であるが、本件の場合はネームアサーションと証明書とが組み合わされており、すべてのもの（all parties）がデジタル証明書を所有する必要はない（メカニズム−認証メカニズムのみがデジタル証明書を持てばよい）という実際的なソリューションをもたらす点において異なっている。
【００６７】
クライアント２２はまず、プロトコルプロキシ３４との接触を確立することを想起されたい。実際の実施に当たって、もしクライアント２２が認証エージェント２４をプロトコルプロキシ３４として見ることができるとすると、このことは非常に便利である。これは実際FAST１０において可能である。なぜならそれはプロトコルプロキシ３４とクライアント２２とが相互認証セッションを確立することができ、そのプロトコルデータは通過点(pass-thru)として動作するどのプロセスに対しても秘匿されているからである。即ち、認証エージェント２４は透過型プロトコルプロキシ３４(transparent protocol proxy)として振る舞う。この場合、認証エージェント２４は通過点として振る舞う。このことはクライアント２２に非常な便利さと効率を提供するものであり、クライアント２２は認証プロセスのセキュリティ全般を維持しながら、あたかも一つのサーバ（即ち認証エージェント２４）を取り扱っているかのように振る舞う。
【００６８】
FAST１０においては認証タイプおよび認証ソースは抽象化されている。従って任意の認証メカニズム３２を用いた任意のサブジェクト２０の認証を援助することのできるプロトコルプロキシ３４を開発することが可能である。ここでは４つの認証タイプとそれらのFAST１０への導入について説明する。
【００６９】
考えられる第１の導入方法は、ユーザIDとクリデンシャルを用いるものである。これは今日最も多く用いられている認証形態の変型である。ここでは、ユーザ（サブジェクト２０）はプロトコルプロキシ３４に秘密のクリデンシャルを提示する。この秘密クリデンシャルは例えばパスワードやバイオメトリックデータでありうる。
【００７０】
FAST１０はプロトコルプロキシ３４とクライアント２２との間の秘密のリンクを確立することによってこの認証タイプを導入する。この秘密リンクは他のいかなる通信媒介物にも関わらない。言い換えると、クライアント２２とプロトコルプロキシ３４との間の通過点として作用するプロセスはこのデータを認識することができない。
【００７１】
クライアント２２とプロトコルプロキシ３４とは以下のようにして安全なリンクを確立する。第１に、クライアントはプロトコルプロキシ３４とのダイアログを開始する。第２に、プロトコルプロキシ３４は自分自身のネームアサーションをクライアントに提示する。第３に、クライアント２２は受け取ったネームアサーション内のベリファイアを用いてSRPメソッドによりプロトコルプロキシ３４を認証する。第４に、クライアントおよびプロトコルプロキシ３４はＳＲＰメソッドによて安全なリンクを確立する。
【００７２】
クライアント２２がプロトコルプロキシ３４との安全なリンクを一度確立した後、クライアント２２はクリデンシャルを送信し、認証が成功すればプロトコルプロキシ３４からネームアサーションを受け取る。
【００７３】
考えられる第２の導入方法は、ベリファイアに基づく認証を用いるものである。この認証形式においては、クライアント２２が秘密のクリデンシャルを所有していることをプロトコルプロキシ３４に対して証明する。プロトコルプロキシ３４はクライアント２２の秘密クリデンシャルに適合するベリファイアを有している。FAST１０の好適な実施形態では、この認証タイプは相互認証式のSRP（上に述べたようなもの）を用いて導入される。
【００７４】
考えられる第３の導入方法は、PKI方式のデジタル証明書を用いるものである。デジタル証明書を用いる認証は秘密のリンクを必要としない。プロトコルプロキシ３４は標準的な問いかけ／応答(challenge/response)プロトコルを用いてクライアント２２がプライベートキーを所有していることを証明する。認証が成功すれば、クライアント２２はプロトコルプロキシ３４からネームアサーションを受け取る。
【００７５】
考えられる第４の導入方法は、以前に発行されたネームアサーションを用いるものである。各ネームアサーションはベリファイアを含んでおり、そのベリファイアに対応するシークレットは該ネームアサーションの所有者（即ちクライアント２２）が保持している。有効なネームアサーションを持つクライアントは相互認証方式のSRPを用いて、プロトコルプロキシと認証を行う。
【００７６】
以上の説明は本発明の概要をまとめているが、FAST１０にその他の機能を取り入れることもできる。そのうちの一つは認証のストレングス（強度）である。クライアント２２は自身を認証することを望む場合のストレングスを指定することができる。このデータはメカニズム決定プロセス２６への入力とされる。逆に、各ネームアサーションはストレングスの指標を有しており、これがサブジェクト２０が実際に自身を認証する際のストレングスをサーバアプリケーション３８に表示する。クライアント２２は認証要求の一部として他の環境変数を指定することができる。これらの変数はメカニズム決定プロセス２６に入力される。ネームアサーションには有効期限があるが、クライアント２２はそれを所有していることを証明することができ、かつ元のネームアサーションの更新カウント即ち更新期間がさらなる更新を許容するならば、それを更新することができる
【００７７】
FAST１０は複数のメカニズムに対して認証するための特別な設備を必要としない。代わりに、この機能は単にクライアント２２が各認証メカニズム３２において認証し、個別のネームアサーションを受け取ることによって実施される。
【００７８】
ここでFAST１０の２つの実施例を示す。それぞれ実際的な（しかし異なった）配備計画である。第１の実施例の中では、協力しあうパートナーどうしが、組織を横断する認証(cross-organization authentication)を要求する。
【００７９】
図２は本発明のFAST１０のブロックダイアグラムであり、このFAST１０は新たな製品を開発するために協力関係にある２つの企業、アリコ（AliCo）１１２とザイランド（Zyland）１１４（実際の事業者と類似があったとしても全くの偶然である）において用いられている。アリコ１１２とザイランド１１４は、管理制御境界１１６のそれぞれの側にある領域として示されている。両者はアリコ従業員１１８およびザイランド従業員１２０としてそれぞれ形式的に示されている従業員を有している（図１におけるサブジェクト２０の例である、クライアント等はここでは明示されてはいないが存在している、なぜなら人間は直接情報システムにアクセスすることはできないからである）。これらの従業員１１８，１２０は共同でプロジェクトチーム１２２を作っている。
【００８０】
この例においては、アリコ１１２とザイランド１１４との関係は永続的なものではなく、これらの企業は非常に逼迫した製品開発サイクルを有しているものとする。従ってプロジェクトの続く間、プロジェクトチーム１２２のメンバーはパートナー企業の情報システムへのアクセスを必要とする。即ちアリコ従業員１１８およびザイランド従業員１２０は両方の企業のツールを用いる必要があり、これらは形式的にアリコアプリケーション１２４およびザイランドアプリケーション１２６として示されている。
【００８１】
アリコ１１２はアリコ認証メカニズム１２８を有しザイランド１１４はザイランド認証メカニズム１３０を有する（これらは図１の認証メカニズム３２の例である）。これらは企業の各ユーザ（従業員１１８、１２０およびこの例とは無関係の他の多くの人々）を認証する。アリコ１１２が用いるアリコ認証メカニズム１２８はユーザIDとパスワードを用いたLDAPディレクトリである。それに対しザイランドが用いるザイランド認証メカニズム１３０はデジタル証明書と関連する証明書失効リスト（ＣＲＬ）である。そしてアリコ１１２、ザイランド１１４共にそれぞれの従業員のエンタイトルメントを管理するそれぞれ独自の内部システムを用いている。
【００８２】
この状況に対する既存のソリューション（解決手段）は以下のうちの１つ以上を必要とする、即ち、プロジェクトチーム１２２のメンバーが個々にパートナー企業の認証システム１２８、１３０に登録するか；プロジェクトチーム１２２のメンバーがパートナー企業のレポジトリに一連のエンタイトルメントを有するか；両社のソフトウェアツール（アプリケーション１２４、１２６）がパートナー企業の認証プロトコルを理解している（例えばアプリケーションはPKIが可能とされているか、あるいはKerberos化されていなければならない）。
【００８３】
これは直ちに実現不可能なものとなる。一方の企業がある従業員のエンタイトルメントを変更したりクリデンシャルを無効とした場合、パートナー企業側に直ちに知らせなければならない。それに対してパートナー企業は自身のレポジトリにおいて対応する変更を行わなければならない。即時の付加またはアップグレードによってソフトウェアツールの変更も行われるかもしれない。
【００８４】
より単純とされているソリューションでは、プロジェクトチーム１２２の各メンバーが共通に信頼されている証明機関（certificate authority: CA）からのデジタル証明書を取得する必要がある。しかし仮にデジタル証明書の取得および管理が容易であったとしても、そのような証明書に実際上エンタイトルメント情報を含ませることはできない。従って例えば、エンタイトルメントの変更によって証明書は無効となることになる。この理由により、PKI方式においては長命の身元証明書と短命の属性証明書があるのであり、そして今日用いられている証明書の９９％以上が身元証明書なのである。
【００８５】
ここで図２に示すFAST１０を用いたソリューションについて考察する。アリコ１１２およびザイランド１１４は小規模なソフトウェアプロトコルプロキシ１３２、１３４（図１のプロトコルプロキシ３４の例である）をそれぞれの認証ソースに配備し、かつ標準のXMLアダプタ１３６、１３８をそれぞれのアプリケーション１２４、１２６の前に配備する（この例では、アプリケーション１２４，１２６はネームアサーションを直接処理するができず、そのためのアダプタ１３６、１３８を必要とするものと仮定している）。そうすると直ちに、アリコ１１２のアリコアプリケーション１２４はザイランド１１４のザイランド従業員１２０を認識し、その者のエンタイトルメントを決定することができる。その逆も同様に成り立つ。もし一方の企業が自社のユーザのエンタイトルメントを変更したり、あるいはクリデンシャルを無効とした場合、他方の企業は、次回の認証が試みられた際に直ちにそれを知ることができる。図２の説明を終える前に、この図は本発明の単純な実施形態を示したものであって、エージェントドメイン１４およびその構成要素は図示されていないことに注意されたい。ここではプロジェクトチーム１２２の従業員１１８、１２０じはパートナー企業のアプリケーション１２４、１２６にアクセスするのみなので、彼らは容易にそれぞれの必要な認証メカニズム１２８、１３０を知ることができ、それを決定するためのエージェントの補助を必要としない。
【００８６】
今日多くの組織は、組織のセキュリティサービスを外部の管理されたセキュリティサービスプロバイダ（managed security services providers: MSSP）に外注している。MSSPの課題はその業務を合理化し、規模の経済を実現することである。これにより次の例の状況がもたらされる。
【００８７】
図３はMSSP２１０に対して認証を提供する本発明のFAST１０のブロック図である。この第２の例において、MSSP２１０は数百の顧客２１２（図１のサブジェクト２０の例を含む存在）にわたるいくつかのタイプの認証をサポートする必要がある。MSSP２１０は認証プロセスの管理を管理する必要はあるが、認証ソースとなる必要はない。また秘密事項に係るクリデンシャル（例えばパスワード）を知る立場となる必要もない。このことはMSSP２１０とその顧客２１２に数多くの利点をもたらす。MSSP２１０はどんな顧客２１２でも、たとえきわめて高いセキュリティ要求を持った顧客でもサポートすることができる。またMSSP２１０は段階的に拡大するソリューションを提供できる、即ち最小限に管理されたソリューションから完全に管理されたソリューションへと顧客をシフトさせて行くことができる。また、クリデンシャルを知る必要がないため、何らかのセキュリティ侵害から生ずるMSSP２１０の法的責任が軽減される。またMSSP２１０がコストのかかる信頼の輪のルール(chain-of-trust rules)の導入をさけるのを助ける。
【００８８】
この問題の在来のソリューションでは、MSSP２１０は各顧客２１２に対して完全に別々の信頼されたシステムを設定する必要がある。そしてMSSP２１０は各顧客２１２の要求と期待に見合った厳格さで各システムを保護しなければならない。最も重要なことは、このソリューションはオール・オア・ナッシングであり、段階的な配備はできないということである。
【００８９】
ここで図３に描かれたFAST１０によるソリューションについて考察する。MSSP２１０はすべての顧客の認証管理に単一の認証エンジン２１４を配備する。実際の認証ソースは顧客２１２側に置かれても、MSSP２１０に置かれても、第三の場所（例えば図示された認証ドメイン）に置かれてもよい。実際、認証ソースの場所の移動と管理権限の変更（顧客２１２からMSSPへ、またはその逆）は何の困難もなく行うことができる。
【００９０】
図３の例では、認証ソース（図１のプロトコルプロキシ３４と認証メカニズム３２の組み合わせの例）は第三の場所にあるものとして描かれている。この構成は図１および図３において、FAST１０は認証ソースをユーザおよびツール（図１のサブジェクト２０およびサーバアプリケーション３８の例）から完全に取り除いた形態にも適応しうる、という事実を際だたせるために、意図的に用いている。
【００９１】
ここで図４を参照して、FAST１０の概要を説明する。ここでは「連合された(federated)」という用語は二つの特定の意味を持つ、即ち、あるシステムが連合されているとは、該システムは複数の認証タイプ、そして複数の認証ソースをサポートするということである。従来の方法は複数の認証タイプについては対応しているが、複数の認証ソースについては大部分無視している。従って、それらを用いた製品は一つの組織の複数の認証タイプをサポートしてはいるが、組織間の認証はサポートすることができない。本説明において「メカニズム」という用語は特定の認証ソースにおける特定の認証タイプを意味するものとして用いる。
【００９２】
図４はFAST１０がどのように多くの相互作用する要素を含んでいるかを示しており、図１をある程度拡張したものである。サブジェクト３１２は自身を認証する必要のある存在である（即ちユーザ、デバイスなど：なお、ここでもクライアントは示されていなくとも暗に含まれており、人間以外のサブジェクト３１２ではサブジェクトに組み込まれている場合もある）サーバアプリケーション３１４はサブジェクト３１２にサービスを提供する。そのためにはサーバアプリケーション３１４はサブジェクト３１２の認証された身元を知らなければならず、そして場合によってはサブジェクト３１２のエンタイトルメントを知らなければならない。メカニズム登録モジュール３１６は認証メカニズム３１８ａ、３１８ｂ、３１８ｃをサブジェクト３１２に結合するプロセスを行う（例えばalico.comのすべてのユーザはldapserver.alico.comに対して認証を行わなければならない）。メカニズムレポジトリ３２０はメカニズムについての情報、即ちそれらの場所、タイプ、クリデンシャル（例えばデジタル証明書）、プロトコルなどの情報を有するデータベースである。メカニズム決定モジュール３２２はサブジェクト３１２の名称（ネーム）を１つ以上のメカニズムに割り当てる。認証エージェント３２４は適切な認証メカニズムを見出しサブジェクト３１２とプロトコルプロキシ３２６ａ、３２６ｂ、３２６ｃとの認証プロトコルを促進するプロセスである。プロトコルプロキシ３２６ａ、３２６ｂ、３２６ｃは認証エージェント３２４と認証メカニズム３１８ａ、３１８ｂ、３１８ｃとの間のインターフェイスである。
【００９３】
認証タイプごとに一つのプロトコルプロキシ（例えばLDAPユーザID/パスワードプロキシ）がある。プロトコルプロキシは認証メカニズムまたは認証エージェントのどちらかと同じ場所にあってもよく、これらは異なる配備案となる。認証メカニズムは認証タイプと認証場所を具現化した特定のメカニズムである。図４においてプロトコルプロキシ３２６ａ、３２６ｃはそれぞれ認証メカニズム３１８ａ、３１８ｃと共にあり、プロトコルプロキシ３２６ｂは認証エージェント３２４と共にある。
【００９４】
サブジェクト３１２がサーバアプリケーション３１４を用いようとした場合、プロセスは認証エージェント３２４に接触するサブジェクト３１２から開始される。認証エージェント３２４はメカニズム決定モジュール３２２を用いてサブジェクト３１２（例えばjames@alico.com）の名称を処理し、認証メカニズム３１８ａ（例えば）を割り当てる。認証エージェント３２４はプロトコルプロキシ３２６ａ（ここでは例として用いられている）を用いてサブジェクト３１２と認証メカニズム３１８ａとの間でのクリデンシャルの送信を促進する。認証エージェント３２４はサブジェクト３１２がプロトコルプロキシ３２６ａに送る秘密事項に係るクリデンシャル（例えばパスワード）を全く見ていないことに注意されたい。サブジェクト３１２およびプロトコルプロキシ３２６ａはそれぞれ安全なトンネルを確立する。このように、秘密事項に係るクリデンシャルを知る必要のあるメカニズムは認証メカニズムのプロキシと同じ場所にあるのが最良であり、これは図４の認証メカニズム３１８ａとプロトコルプロキシ３２６ａの場合のごとくである。
【００９５】
サブジェクト３１２およびプロトコルプロキシ３２６ａは認証プロセスに入る。サブジェクト３１２が信頼できるものであれば、プロトコルプロキシ３２６ａはネームアサーションとエンタイトルメントからなるデジタル署名されたドキュメントを作成する。本発明者による現在好適な実施形態では、このドキュメントの実際のフォーマットはセキュリティ・サービス・マークアップ・ランゲージ(security service markup language: S2ML)に従ったものであり、これはセキュリティ情報を通信するドラフト段階のXMLスタンダードである。サブジェクト３１２は一度S2MLドキュメントを受信すれば、それをシンプルS2MLのエレメントおよびアトリビュート（属性）を理解するどのアプリケーションにも送ることができる。必要であれば、S2MLを解さないどんなアプリケーションにも（例えば、図４のサーバアプリケーション３１４）、XMLアダプタ３２８を用いてこの能力を与えることができる。
【００９６】
FAST１０の利点はその単純さおよび本来的な安全性にある。FAST10の諸要素はいくつもの仕方で配備することができ、これによって組織のセキュリティおよびビジネス両方の要請を満たす配備計画を作成することができる。
【００９７】
メカニズム決定モジュールは、サブジェクトが動作している環境を考慮に入れたプロセスを実行する。例えばサブジェクトに手持ち（ハンドヘルド）デバイスを介したクリデンシャルの入力を求めるのと、虹彩スキャンデバイスによってそのようなものを取得するのとではかなり異なっている。このように、サブジェクトは所望のどのような仕方でも認証を行うことができ、このことはより積極的な経験に導く。
【００９８】
認証メカニズムを改変する必要はない。その代わりにプロトコルプロキシが認証エージェントと認証メカニズムとの間のインターフェイスを行う。それにより、組織はその既存のメカニズムをすぐに用いることができ、これによってコストを節約し、出費を抑えることができる。
【００９９】
認証はアプリケーションから分離される。これにより、組織は組織のサブジェクトによって用いられている組織自身のアプリケーションまたは第三者のアプリケーションを変更する必要なしに、該組織の基礎的認証メカニズムを、徐々にあるいは一度に変更することができる。認証メカニズムは該メカニズムを所有する場所において（即ち該メカニズムの管理制御の境界内において）動作する。認証メカニズムとサブジェクトとの間の情報交換はプライベート（私秘的）である。従って、認証エージェントは秘密事項に係るクリデンシャルを見たり、盗んだりすることはできない。
【０１００】
サブジェクトは人間のユーザである必要はない。それはアプリケーション、デバイス、プロセスなどであってもよい。従って、FAST１０は人間のサブジェクト、人間以外のサブジェクトを包含する複数の環境に適用可能である。
【０１０１】
FAST１０の諸要素はどの場所で動作することもでき、またそれら要素は異なる制御ドメイン内に存在しうるので、各要素が内的にかつ他の要素との通信において安全（セキュア）であることが絶対に必要である。このFAST１０の全体的セキュリティについてここで説明する。
【０１０２】
引き続き図４を参照すると、認証エージェント３２４はサブジェクト３１２とプロトコルプロキシ３２６ａとの間の認証要求と応答とを媒介する。しかし、いかなる場合も認証エージェント３２４は秘密のクリデンシャルを見ることはできない。これはサブジェクト３１２とプロトコルプロキシ３２６ａとが、認証エージェントの知らない秘密キーを設定するからである。更に、認証エージェント３２４は認証結果（S2MLによるネームアサーションとエンタイトルメント）を改変することができない。これはプロトコルプロキシ３２６ａが認証応答にデジタル署名しているからである。
【０１０３】
図４に示されたFAST１０の例において、破線はエージェントドメイン３３０の境界を示している。サブジェクト３１２とプロトコルプロキシ３２６ａ、３２６ｂ、３２６ｃとの間のすべての通信はエージェントドメインを通過していることが見て取れるだろう。しかしながら、この構成の場合でさえも、すぐ上に述べた理由により安全である。
【０１０４】
プロトコルプロキシはサブジェクト３１２との間に安全なプロトコルを確立する。プロトコルプロキシは認証エージェント３２４と同じ場所で動作することもできるし（図４におけるプロトコルプロキシ３２６ａのごとく）、または認証メカニズムと同じ場所で動作することもできる（図４における、認証メカニズム３１８と共にあるプロトコルプロキシ３２６ａのごとく）。サブジェクト３１２が秘密事項に係るクリデンシャルを送るような場合には、プロトコルプロキシは認証エージェント３２４と同じ場所で動作するのが最良である。
【０１０５】
プロトコルプロキシは署名されたS2MLネームアサーションおよびエンタイトルメントを作成する。サブジェクト３１２はこのS2MLドキュメントを用いて任意のサーバ（例えばサーバアプリケーション３１４）に対して認証を行う。この点にFAST１０と他の認証アーキテクチュアとの重要な相違がある。他の認証アーキテクチュア（たとえばKerberos）においては、ネームアサーションは特定のサーバに向けられたものである。そのため、サーバはこのネームアサーションを盗むことができない。しかしながら、このような方式におけるサブジェクトはそれぞれのサーバに対して別々のネームアサーションを必要とすることになる。
【０１０６】
S2MLドキュメントの再生や盗難を防止するために、プロトコルプロキシはサブジェクトにSRPシークレットを送り、かつサーバアプリケーション用のSRPベリファイアをS2MLドキュメント中に入れる。このようにして、サーバはサブジェクトがS2MLドキュメントの元々の意図された受取者であることを常に検証するが、サーバはS2MLドキュメントを用いてサブジェクトを装うことはできない。要するに、S2MLネームアサーションおよびエンタイトルメントは、サーバがサブジェクトの認証にのみ用いることのできるデジタル証明書と類似したものである。
【０１０７】
認証メカニズムはFAST１０のその他の要素と直接通信することはない。その代わり、プロトコルプロキシが認証メカニズムとFAST１０の他の要素との間のインターフェイスとなる。このようにして、プロトコルプロキシと認証メカニズムとの間の通信は所望通りに安全となすことができる。
【０１０８】
FAST１０は広く用いられ信頼されているセキュリティ産業のスタンダードを用いることができる。例えば、X.509 version 3のデジタル証明書を用いてもよい。FAST１０の要素はこうしたデジタル証明書をSSL/TLS接続やデジタル署名検証の基盤として用いることができる。上にも述べたように、セキュリティサービスマークアップランゲージ（S2ML）を用いてもよい。プロトコルプロキシはS2ML方式に則ったXMLドキュメントを作成することができる。XMLデジタル署名もまた、使用可能な別のスタンダードである。FAST１０はS2MLネームアサーションおよびエンタイトルメントの電子署名の作成に、XML署名仕様を用いてもよい。セキュアリモートパスワード（SRP）スタンダードを使用すれば、FASTはRFC2945に記載されているようなSRP認証およびキー交換システムを用いることができる。更に、ここに説明したSRPの改良バージョンはまた別の利点を有する。FAST１０はプロトコルデータの私秘性(privacy)および完全性(integrity)を守るために、様々なスタンダードの暗号化およびメッセージダイジェストアルゴリズムを用いることもできる。これらは、Diffe-Hellman、RSA、AES、SHA-1、およびRFC2104に規定されているようなメッセージ認証のための鍵付きハッシングであってもよい。
【０１０９】
情報を企業の境界をこえて共有することができれば、組織は企業内ビジネスを創出することができ、競争上の優位性を得ることができる。同時に情報は重要な企業資産であり、その価値に応じて保護されなければならない。情報を守るために組織はユーザの身元を確かめる必要がある。
【０１１０】
実世界においては我々一人一人が知られており、多くの方法で認証することができる。友人や家族は声や外見で我々を知っており、金融機関や法的機関は署名や公的に発行された身分証で我々を知り、また法執行機関は指紋で我々を知る。
【０１１１】
全世界的な単一サインオンは単一の認証ソースを意味するものではないし、単一の認証タイプを意味するのでもない。結局のところ、複数の連合された認証ソースを効率的に用いることこそが、全世界的な単一サインオンを実現するのである。
【０１１２】
FAST１０は、異なる制御ドメインからの複数の認証タイプ複数の認証ソースを用いることを可能にする現在唯一の技術である。FAST１０を用いることによって、組織はきわめて厳格なセキュリティ条件を満たしながら、組織の既存の情報システムを用いて、迅速にビジネス関係を実現することができる。
【０１１３】
以上において様々な実施形態を説明してきたが、それらは例として示したものであり、本発明を限定するものではないことを理解されたい。従って、本発明の範囲は以上に説明した例示のための実施形態に限定されるものではなく、添付の請求の範囲およびその均等物にしたがって定義されるものである。
【産業上の利用可能性】
【０１１４】
このFAST１０はサーバアプリケーション３８、１２４、１２６、３１４に対するサブジェクト２０、１１８、１２０、２１２、３１２の認証に、好適に用いられる。FAST１０は図２に示すように、少数のサブジェクトとサーバアプリケーション用の小規模のものとすることもでき、または図３に示すように、潜在的には数千の数の大規模のものとすることもできる。これらは今現在存在している需要であり、これにFAST１０は十分に応えるものであり、かつFAST１０を導入して直ちにこれに応えることもできる。
【０１１５】
FAST１０は異なる制御ドメインの複数の認証タイプと複数の認証ソースの使用を可能とし、しかもそれらが互いにどれほど非協和的なものであってもかまわない。FAST１０は認証タイプとソースの両方を単純に抽象化する。従って、諸組織は所望のセキュリティインフラストラクチュアを選択し、組織の既存のセキュリティインフラストラクチュアを利用しながら、きわめて厳格なセキュリティ条件を満たしてビジネス関係を形成することができる。
【０１１６】
複数の認証タイプをサポートできるので、諸組織はある一つの認証タイプを配備し、そして例えば必要に応じてあるいはより強力な認証タイプが開発された場合に、他の所望の認証タイプに移行することができる。Kerberosやパブリックキーインフラストラクチュアのような既存の認証技術は、すべてのユーザにおいてその技術を有効化することを必要とする。これにより企業全体に対して完全導入か導入しないかの二者択一式の計画となる。これに対してFAST１０を用いれば、ユーザやサーバに影響を与えることなく認証メカニズムを変更することができる。複数の認証ソースをサポートできることにより、ユーザおよびサーバは認証場所を選択することができる。例えば、支払いのためにはユーザは自分の銀行において認証しなければならない。しかし医療記録を閲覧するためにはユーザは自分の医療サービス提供者もしくは場合によっては雇い主に対して認証しなければならないだろう。
【０１１７】
FAST１０はネームアサーションを用いた署名の作成と検証を可能とする。これにより署名の作成と検証のためにデジタル署名を用いる必要が無くなり、署名作成および検証のスピードと効率が向上する。ネームアサーションは既存のネームアサーションを更新する基盤として用いることもできる。これにより認証が必要となるたびにデジタル証明書を用いる必要がなくなり、認証プロセスのスピードと効率が向上する。
【０１１８】
これまで述べてきたように、FAST１０はKerberosユーティリティやパブリックキーインフラストラクチュア（PKI）方式、そしてまた特にセキュアリモートパスワード(SRP)プロトコルを用いることができ、かつそれらを改良することができるものであり、強力で相互的な認証プロトコルを導入することによってそれらを改良する。
【０１１９】
FAST１０は本来的に安全である。FAST１０は信頼性の階層(hierarchy of trust)を許容し、そこでは認証メカニズムは自分自身を認証しなければならない。このようにしてあるサブジェクトは秘密事項に係るクリデンシャルを認証された(authenticな)メカニズムに対してのみ開示し、認証されたメカニズムのみを信頼すればよい。FAST１０はまたクリデンシャルの期限切れについても融通性があり、何者がクリデンシャルの有効期間を設定したかという点について厳格で融通性のない従来アーキテクチュアの制約を解決する。FAST１０において、クライアント、サーバあるいはメカニズムがクリデンシャルの期限切れを要求することができる。
以上およびその他の理由により、本発明のFAST１０は広い産業上の利用性を有するであろう。従って、本発明の商業的利用は広範囲かつ長期間にわたるであろうと予想される。
【０１２０】
（用語集）
認証エージェントAuthentication Agent:
サブジェクトと認証メカニズムとの間の認証を援助促進するプロセス。認証エージェント自体はサブジェクトの認証を行うことはない。
認証メカニズム Authentication Mechanism:
特定のプロトコルに従ってサブジェクトを認証するプロセス。
管理ドメイン Administrative domain:
同一の団体の管理下にあるデバイス、人およびプロセスの集まり。
管理制御の境界 Boundary of Administrative Control:
管理ドメイン間の境界。
クライアント Client:
サブジェクトが自分自身を認証するために用いるプロセス。
クライアントアプレット Client Applet:
クライアントの特定の実行であって、認証コードが動的にダウンロードされるか、またはクライアント上に局在しており、かつブラウザーで実行されることができる。
クライアントアプリケーション Client Application:
クライアントの特定の実行であって、認証コードはクライアント上に存在し独立プロセスとして実行される。
クリデンシャル（信用証明） Credential:
主張された身元(identity)を確立するために提示されるデータ。
エンタイトルメント（権利付与） Entitlement:
アクセス決定情報を含むデータ構造。サーバはエンタイトルメントを用いてサブジェクトに許可する行為を決定する。
メカニズム−認証メカニズム Mechanism-Authentication; Mechanism:
他の認証メカニズムをサブジェクトとして認証することのできる認証メカニズム。
メカニズム登録 Mechanism Registration:
認証メカニズムが自分自身をメカニズムレポジトリに登録するために用いるプロセス。
メカニズムレポジトリ（メカニズム格納所） Mechanism Repository:
認証メカニズムについての情報を格納している格納所。この情報はメカニズムのタイプ、そのプロトコル、そのストレングス、およびクライアントがどうすればそれにコンタクトできるかについての情報を含む。
メカニズム決定 Mechanism Resolution:
サブジェクトについてのある情報（例えば名称と領域）を一連の認証メカニズムにマッピングするプロセス。
ネームアサーション（名称言明） Name Assertion:
身元の宣言を含む署名されたデータ構造。ネームアサーションは主張された身元を確立するために提示される。ネームアサーションはクリデンシャルの一種である。
プロトコルプロキシ Protocol Proxy:
互いのプロトコルを解さない２つのプロセスを仲介するプロセス。
ドメイン Domain:
認証オーソリティの領域。認証メカニズムは一つ以上のドメイン内のサブジェクトを認証することができる。
サーバ Server:
クライアントを通じてサブジェクトにサービスを提供するプロセス。サーバはサブジェクトに自分自身を認証することを要求する。場合によっては、サーバもまた自分自身をクライアント／サブジェクトに対して認証しなければならない。
サーバアプリケーション Server Application:
サーバプロセスの機能性を実行するアプリケーション。多くの場合、サーバとサーバアプリケーションとは同義語である。
ストレングス Strength:
認証の厳格性を示す指標。
サブジェクト Subject:
ユーザー、アプリケーション、デバイス、プロセス、その他認証を必要とするあらゆる存在。
（付録A）
１．これはクライアント２２からプロトコルプロキシ３４へ向かう認証要求の例である。
２．これはプロトコルプロキシ３４からクライアント２２への認証応答の例である。見てわかるように、この例はプロトコルプロキシ３４のネームアサーションを含んでいる（即ちこれはクライアント２２に自分自身のネームアサーションを送るプロトコルプロキシ３４である）。
３．これは上記例１の要求の「続き」である（即ちクライアント２２からプロトコルプロキシ３４に送られる第２のメッセージである）。
４．これはプロトコルプロキシ３４からクライアント２２への第２の応答である。この応答は＜暗号化＞要素上の暗号化されたネームアサーションおよびエンタイトルメントを含んでいる。
・・・（簡略化のためにここでは暗号化されたデータを省略する）・・・
５．これは単に例４の＜暗号化された＞要素の、明確なテキストバージョンである。
【図面の簡単な説明】
【０１２１】
【図１】本発明において、異なる管理ドメインにおいて動作する協働する一群の構成要素がどのように含まれるかを示すブロック図である。
【図２】新たな製品開発のために共同する２つの企業が本発明を利用した例を示すブロック図である。
【図３】外部の管理されたセキュリティサービスプロバイダ(MSSP)が顧客に認証を提供する際に本発明を利用して例を示すブロック図である。
【図４】本発明において、多くの相互作用する諸要素がどのように含まれるかを示す、図１を拡張したブロック図であり、複数の認証メカニズムの様々なオプションや利用法を示すものである。
【０００１】
本発明は広くはコンピュータネットワークの安全な使用に関わるものであり、詳しくは、認証のタイプや認証ソース(authentication source)が複数ある場合に情報システム内のセキュリティを効率よく保つことに関わる。
【背景技術】
【０００２】
今日のデジタル社会においては、情報システムとそのコンテンツは組織の最も貴重な資産の一つである。各組織は自身のデータを権限のないアクセスから守ることに少なからぬ出費をしている。同時に組織は、総括的なビジネス上の要請から、ビジネスパートナーや顧客、納入業者、そして時には競争相手や対抗者とも情報を共有する。このためには認証手続きが必要である。
【０００３】
認証が最も重要となるのは、それがアクセス制御規則を行使するための基盤となる局面である。すなわち、システムがあるサブジェクトにどういう行為を許可するかを決定するためには、システムはまずそのサブジェクトが何者であるかを確かめなければならないということである。
【０００４】
従来の認証システムはたいていの場合、単一の認証ソースおよび認証タイプを想定している。例えばKerberos（ケルベロス）においては、認証ソースは信頼されたキーディストリビューションセンター（key distribution center: KDC）であり、認証タイプはユーザーIDとパスワードである。（Kerberosのバージョン５はパブリックキー（公開鍵）に基づく初期認証をサポートしているが、Kerberosが商業的に利用されているケースの多くのものがユーザーIDとパスワードに基づいて認証を行っている。）別の例としてパブリックキーインフラストラクチュア（PKI）システムがある。そこでの認証ソースは証明機関（certificate authority: CA）であり、認証タイプは問いかけ／応答(challenge/response)である。KerberosとPKIは共に複数の認証ソースを許容しはするが、それらの認証ソースは緊密に結合されたものでなければならない。このことは多くの場合、認証ソース間に複雑な信頼関係があることを意味し、これは実際上実行不可能であり、かつ経済的にコストの非常に高いソリューション（解決方法）となる
【０００５】
新たな認証システムであって、ここでの議論において後に特別の重要性を持つものとして、セキュアリモートパスワード（secure remote pass word: SRP）プロトコルがある。SRPの唱道者である発明者のTom Wuとスタンフォード大学は「クライアントが（パスワードの如き）小さなシークレット（secret:秘密）を記憶しなければならず、かつその他の秘密情報を持たず、サーバは、サーバがクライアントを認証できるが、危険な状況になった時にも何者かがクライアントを偽装することを許さないような証明手段を有するようなケースにおいて、クライアント対サーバの問題を安全に解決する」と述べている。しかし、SRPは従来の認証システムと同様に、単一の認証ソースとタイプを前提としている。
【０００６】
組織内および組織間通信の実情を見れば、単一の認証タイプということはあり得ないことがわかる。実際、Giga Groupが２００１年に出版したレポートによれば、企業はパスワード、トークン、証明書(certificate)、スマートカードなどの複数の認証タイプをサポートするであろうとされている。従って、セキュリティ体系は、各々の認証タイプにたいして別々のインフラストラクチュアを有するのではなく、すべての認証タイプを処理する単一のインフラストラクチュアを有するべきである。いつの日にかは単一の認証タイプ（例えばバイオメトリックス）となるとしても、各々が一群のサブジェクトの管理制御をおこなう複数の認証ソースは常に存在し続けるであろう。
【０００７】
従って、アクセス制御を実行しようとする情報システムは、いかなる数のソースからも認証情報を受け入れられるように構成されていなければならない。実際アクセス制御の実行に当たって鍵となる基準は、認証の正確なソースとタイプを含む。実際のモデルにおいては、多くの認証ソースが連合体(federation)を形成する必要があり、その連合の各成員は一群のサブジェクトの信頼性を確認できる必要がある。
【０００８】
必要となるのは、組織が、組織自身、またはその顧客、パートナー、納入業者、その他の第三者に所属する認証ソースを利用することを可能とする技術である。我々はこのような技術を連合認証サービス技術（Federated Authentication Service Technology: FAST）と名付け、その目的を組織が高度に安全な情報システムを介してビジネス関係を形成することを可能にすることとする。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
従って本発明の一つの目的は、連合認証サービス技術(FAST)を提供し、組織が高度に安全な情報システムを介してビジネス関係を形成することを可能にすることである。
【００１０】
本発明の別の目的は複数の認証タイプおよび異なる制御ドメインからの複数の認証ソースを利用できる認証システムを提供することである。
【００１１】
本発明の別の目的は、組織がユーザーやサーバへの影響なしにその認証機構を改変できるようにする認証システムを提供することである。
【００１２】
本発明の別の目的は、組織の既存のセキュリティ・インフラストラクチュアを利用してビジネス関係を迅速に形成しながら、厳格なセキュリティ条件を提供する認証システムを提供することである。
【００１３】
本発明の別の目的はユーザーおよびサービスプロバイダが認証場所を選択できる認証システムを提供することである。
【課題を解決するための手段】
【００１４】
略述すると、本発明の好適な実施形態は、ネットワークの認証ドメインにある認証メカニズムがサーバアプリケーションの提供するサービスに作用する(affect:なんらかの影響を与える)場合において、ネットワークのサブジェクトドメインにあるサブジェクトをネットワークのサーバドメインにあるサーバアプリケーションに対して認証するためのシステムである。このシステムは他の構成要素と通信しかつサブジェクトを代理してクライアントのネームアサーションを与えることによってサブジェクトを認証するクライアントを含む。このクライアントもまたサブジェクトドメインにある。このシステムは、クライアントと認証メカニズムとの間で通信を行い、クライアントのクリデンシャルに基づいてクライアントを認証し、クライアントのサーバアプリケーションへのアクセスを許可するための認証ネームアサーションをクライアントのクリデンシャルに基づいて作成するプロトコルプロキシを更に含む。
【発明の効果】
【００１５】
本発明の一つの利点は、複数の認証タイプおよびソースを抽象化する(abstract)ことにより複数の認証タイプおよび認証ソースの使用が可能となることである。既存の認証技術は複数の認証タイプ（たとえばユーザID／パスワード、バイオメトリックス、デジタル証明書など）を許容する。しかし、これら既存の技術は複数の認証ソース（例えば雇い主、金融機関、医療サービス提供者など）を抽象化することはない。
【００１６】
本発明の別の利点はサーバの選択するどのメカニズムに対しても認証を行うことができる点である。サーバの認証メカニズムはクライアントの認証メカニズムとは全く独立している。
【００１７】
本発明の別の利点はクライアント、サーバアプリケーション、認証メカニズムによって要求されるクリデンシャルの期限切れに関して融通性があることである。
【００１８】
本発明の別の利点は異なるドメインからの認証をサポートし、全世界的な単一サインオンを可能とすることである。
【００１９】
本発明の別の利点はクリデンシャルの管理場所を単一として、管理を容易とし、かつ安全性の高い配備を可能とする点である。
【００２０】
本発明の別の利点は安全性の高い構成要素間プロトコルを用いていることである。これにより、多くの異なる配備計画が可能となり、管理されたセキュリティサービスを提供する。
【００２１】
本発明の別の利点は認証メカニズムを選ばないことである。これにより、既存の認証メカニズムへの組織の投資を保護しながら、将来の認証メカニズムをシームレスに取り込むことができる。
【００２２】
本発明の別の利点は信用の階層(hierarchy)を可能とすることである。本発明は、それら自身を認証するための認証メカニズムを必要とする。かくしてユーザは秘密事項に係るクリデンシャルを認証メカニズムに対してのみ開示すればよい。またサーバアプリケーションは認証メカニズムのアサーションのみを信頼すればよい。
【００２３】
本発明の別の利点はネームアサーションを用いた署名の作成および検証を可能とすることである。これにより、これにより署名の作成および検証にデジタル証明書を用いる必要がなくなり、署名作成および検証のスピードと効率が向上する。
【００２４】
本発明の別の利点はネームアサーションを用いて既存のネームアサーションを更新することを可能とすることである。これにより認証が必要となる度毎にデジタル証明書を用いる必要がなくなり、認証プロセスのスピードと効率が向上する。
【００２５】
本発明の別の利点はスタンダードに準拠していることである。これによりアプリケーションと現存および将来のセキュリティシステムと間の相互運用性を助成する。
【００２６】
本発明の別の利点はパブリックキーインフラストラクチュア(PKI)方式を用いかつ改善することができることである。本発明は長命のデジタル証明書を束の間の証明書（ネームアサーション）に変える。従って全体的な管理を最小のものとする。より詳しくは、本発明によって、PKIの普及の妨げとなっていたサーバによる失効証明書リスト(CRLs)の確認プロセスは不要なものとなる。
【００２７】
本発明の別の利点はKerberosを用いかつ改善することができることである。Kerberosにおいてはクライアントはあるサーバに最初に接触する度毎にKerberos認証メカニズムと通信しなければならなかった。本発明で用いられるネームアサーションは普遍的なものであり、それらネームアサーションを用いてどのサーバに対しても身元を証明することができる。従って一つのネームアサーションをどのサーバにも提示することができる。これによりクライアントが異なるサーバと通信しようとする度毎に認証メカニズムに接触する必要がなくなる。
【００２８】
本発明の別の利点はセキュアリモートパスワード(SRP)のユーティリティを用いかつ改善することができることである。SRPはサーバに対するクライアントの認証を可能にするがサーバをクライアントに対して強力に認証することはない。本発明は強力な相互認証プロトコルを導入することにより、この点を改善する。
【００２９】
本発明の別の利点は既存の認証技術とは異なって、なめらかな移行が可能であることである。既存の認証技術ではすべてのユーザおよびサーバにおいて当該技術を有効化することが必要であるため、企業全体で当該技術を完全導入するか導入しないかの二者択一となってしまう。本発明を用いれば、ある組織はそのユーザやサーバに影響を与えることなく認証メカニズムを変更することができる。
【００３０】
本発明の別の利点は構成が簡単で、そのアーキテクチュアを非常に簡単に導入することができ、バラエティに富んだ導入計画が可能であることである。
【００３１】
本発明を実施する現在知られている最適な態様およびその好適な実施態様の産業上の利用可能性についての以下における説明および図面における図示を参照することにより、当業者は本発明の上記およびその他の目的や利点を理解するであろう。
【発明を実施するための最良の形態】
【００３２】
本発明の諸目的および諸利点は添付の図面に関連してなされる以下の詳細な説明から明らかになるであろう。
【００３３】
本発明の好適な実施形態は連合認証サービス技術(FAST)である。様々な図面、特に図１に示すように、本発明の好適な実施形態は参照符号１０によって示されている。以下の議論の理解を助けるために「産業上の利用可能性」の項目の後に用語解説が付加されている。
【００３４】
図１はFAST１０が、ネットワークの異なる管理ドメインを横断して実行する一群の協働する要素をどのように含んでいるかを描いており、境界を破線で示している。ここで、サブジェクトドメイン１２はエージェントドメイン１４、認証ドメイン１６およびサーバードメイン１８に接するものとして描かれている。サブジェクトドメイン１２はサブジェクト２０（必ずしも人間ではない）およびクライアントアプリケーションおよびアプレット（クライアント２２）を含んでいる。エージェントドメイン１４は認証エージェント２４，メカニズム決定プロセス２６、メカニズムレポジトリ（メカニズム格納所）２８、メカニズム登録プロセス３０を含んでいる。認証ドメイン１６は認証メカニズム３２およびプロトコルプロキシ３４（これは認証ドメイン１６内に設けてもよい）を含んでいる。サーバードメイン１８はサーバーアプリケーション３８を含んでいる。
【００３５】
サブジェクトドメイン１２からサーバドメイン１８へのアクセスの取得が所望される。このようなアクセスは認証ドメイン１６において承認が成立し、エージェントドメイン１４が承認を補助することに基づいて行われる。要点を提示するために図１およびその説明はある程度簡略化しているが、これから説明するように、FAST１０の典型的な実施形態は多くのサブジェクト２０，認証メカニズム３２，サーバアプリケーション３８を含んでおり、それらすべてが一つの認証エージェント２４のサービスを用いている。複数の同様の種類の存在がある場合には、それらの各々がそれぞれのドメインとして取り扱われる。
【００３６】
図１についてより詳しく説明する前に、「ネームアサーション(name assertion: 名称言明)」と呼ばれる中核概念のFAST１０における役割を理解することが有用である。ネームアサーションはクリデンシャル（credential: 信用証明）の一種である。より詳しく言えば、実際の実施において、それは主張された身元（identity）を確立するために提示することのできる身元の宣言を含むデジタル署名されたデータ構造である、
【００３７】
FAST１０はセキュアリモートパスワード（SRP）プロトコルを用いて、ネームアサーションを提示する存在を認証する。FAST１０においてこれはネームアサーションにSRPベリファイア（verifier）を含ませ、そして自身を認証（証明authenticate）しなければならない当該存在にSRPシークレット(secret)を与えることによって成し遂げられる。このようにすれば、たとえばクライアント２２がサーバアプリケーション３８にネームアサーションを提示した際に、サーバアプリケーション３８はネームアサーションからSRPベリファイアを取り込み、かつSRP方式を用いてクライアント２２がSRPシークレットを有していることを証明するように要求する。
【００３８】
ここで図１の詳しい説明に戻る。図１はFAST１０における認証の全体的な流れを示している。一連のステップすなわちステップ４０〜５２は実際の認証プロセスであり、これらは常にではないが、サブジェクト２０がサーバアプリケーション３８に対して認証される必要のある度毎に行われる。これに対し、ステップ５６〜５８は登録プロセスであり、これらは認証メカニズム３２がエージェントドメイン１４において自身を登録するまたは更新する場合（メカニズムレポジトリ２８を変更する場合）にのみ行われる。
【００３９】
ステップ４０において、自身を認証しなければならないサブジェクト２０は、クライアント２２を用いてサーバアプリケーション３８へのアクセスを取得するプロセスを開始する。ここではクライアント２２とサブジェクト２０は別物として示しているが、サブジェクト２０がクライアント機能を一体的に有している場合、すなわちサブジェクト２０が人間でない場合にはこの限りではないことを理解されたい。
【００４０】
ステップ４２において、クライアント２２は認証エージェント２４に接触し、認証エージェント２４にサブジェクト２０の名称とドメインを送る。クライアント２２はオプションとして特定の認証メカニズム３２の名称およびその他のデータ（一般的には、認証メカニズムが提供することのできる方法および認証のストレングスを適宜の場合に含む）をも送ることができる。クライアント２２と認証エージェント２４との間のやりとり（相互作用）が成立するとクライアント２２が用いるべきただ一つの認証メカニズム３２についての情報が生成される。そうでない場合は、認証エージェント２４はクライアント２２の要求に合致する認証メカニズムが存在しないことを示すエラー状態を返信する。
【００４１】
ステップ４４において、認証エージェント２４はメカニズム決定プロセス(mechanism resolution process)２６を用いてクライアント２２に対する適切な認証メカニズム３２を決定する。適切なものが２つ以上ある場合には、認証エージェント２４はクライアント２２との間でのプロトコルを用いて（上記ステップ４２）ただ一つだけの認証メカニズム３２を決定する。
【００４２】
ステップ４６において、メカニズム決定プロセス２６はメカニズムレポジトリ２８を用いて、適切な認証メカニズム３２についての情報を取り込む。その後この情報は最終メカニズム決定としてクライアント２２に送ることができる。
【００４３】
ステップ４８において、クライアント２２はサーバアプリケーション３８へのアクセスのための認証要求を、標準の安全なプロトコル(standard secure protocol)を用いてプロトコルプロキシ３４に通信する。この通信は認証エージェント２４およびエージェントドメイン１４のいかなる部分も介する必要なく行われることに注目すべきである（しかし、場合によってはここで説明しているような仕方でそれを介してもよい）。
【００４４】
ステップ５０において、プロトコルプロキシ３４はクライアント２２からの認証要求を受信し、それを認証メカニズム本来のプロトコルに変換する。従って、各々のタイプの認証プロクシ３２に対して１つのプロトコルプロキシ３４が存在しうる。続いてプロトコルプロキシ３４は変換された要求を認証メカニズム３２に通信する。認証が成功すれば、プロトコルプロキシ３４は認証メカニズムからサブジェクト２０の属性(attributes)とアクセス権を含む応答を受信する。プロトコルプロキシ３４は次にネームアサーションおよびオプションとしてエンタイトルメント（entitlement: 権利付与）を生成する。プロトコルプロキシ３４はこれを認証応答に変換し、クライアント２２に返送する。
【００４５】
ステップ５２において、クライアント２２は該認証応答をサーバアプリケーション３８に送信する。クライアント２２およびサーバアプリケーション３８はクライアントが該ネームアサーションの正式の所有者であることを証明するプロトコルに入る。
【００４６】
前に述べたように、上記のステップ４０〜５２は一般的に（常にではないが）サブジェクト２０がサーバアプリケーション３８に対して自身を認証しなければならない場合ごとに行われる。ネームアサーションが再利用可能である限り、サブジェクト２０はそれをサーバアプリケーション３８に何度でも提示することができる。認証メカニズム３２を最初に登録する際には、以下のステップ５６〜５８が用いられる。
【００４７】
ステップ５６において、認証メカニズム３２はメカニズム登録プロセス３０に接触し、登録を開始する。
【００４８】
ステップ５８において、メカニズム登録プロセス３０は認証メカニズム３２についての情報をメカニズムレポジトリ２８に入力する。その後はステップ４０〜５２が運用可能となる。プロトコルプロキシ３４がすでに認証メカニズム３２によって利用可能である場合もあり、またはこれらの登録ステップの間にメカニズム登録プロセス３０がプロトコルプロキシ３４を提供するすなわち利用可能となす場合もある。
【００４９】
FAST１０の各要素はFAST１０内の他の要素と通信する場合に用いるプロトコルを持っている。サブジェクト２０は環境仕様(environment-specific)のデバイスを用いて自身を認証する。FAST１０は環境によらない(environment-agnostic)ので、サブジェクト２０はいかなる環境でいかなるタイプのクリデンシャルを用いて認証を行ってもよい。このようなクリデンシャルのいくつかの例としては、コンピュータや手持ち（ハンドヘルド）デバイスのID/パスワード、デジタル証明書および関連するプライベートキー、そして指紋や虹彩走査などのバイオメトリックデータ（生体測定データ）などがある。
【００５０】
クライアント２２はサブジェクト２０が自身を認証することを補助するアプリケーションまたはアプレットである。クライアント２２は環境仕様のプラットフォームで動作し必要なクリデンシャルを作り出すデバイスと相互作用（やりとり）する。例えばクライアント２２はバイオメトリックデバイスと相互作用して指紋データを収集する。
【００５１】
サブジェクトはいくつもの異なるやり方でクライアントを入手することができる。たとえば、サブジェクト２０はあらかじめクライアント２２を備えていてもよいし、またはクライアント２２を認証エージェント、サーバアプリケーション３８その他の場所から「急場で(on the fly)」」ダウンロードしてもよい。
【００５２】
上に述べたように、クライアント２２は最適な認証メカニズム３２を決定するために認証エージェント２４とやりとりする。認証エージェント２４は１つ以上の適切な認証メカニズム３２を返信する場合がある。クライアント２２は従ってどの１つの認証メカニズムを用いるべきかをその場で決定することを可能とするコールバックメカニズムを有してもよい。例えば、コールバックメカニズムはサブジェクト２０と相互作用（やりとり）してこれを決定してもよいし、またはコンフィギュレーションレポジトリ(configuration repository：構成情報レポジトリ)に問い合わせてもよい。
【００５３】
認証エージェント２４はクライアント２２とメカニズム決定プロセス２６とを仲介する。クライアントは最低でも認証エージェント２４にサブジェクト２０の名称とドメインを送らなければならないが、その他の情報をオプションとして送ってもよい。認証エージェント２４はこの情報を用いて適切な認証メカニズムを決定する。認証エージェント２４は次いで認証メカニズム３２を特定する情報をクライアントに返送する。一つ以上の認証メカニズムが提供された場合には、クライアント２２はコールバックメカニズムを用いてただ一つを選択する。
【００５４】
クライアント２２が認証エージェント２４の補助なしに認証メカニズム３２を選択する場合には特定のプロセスが準備されている。例えば、クライアント２２はサブジェクト２０とやりとりして認証メカニズム３２を選択することができる。この場合、クライアント２２は２つの選択肢を有する。第１の選択肢では、クライアント２２は所望の特定認証メカニズム３２の要求を認証エージェント２４に送る。次に認証エージェント２４はその認証メカニズム３２が実際にサブジェクト２０を認証するものであるかどうかを単にチェックして確かめる。第２の選択肢では、クライアント２２はプロトコルプロキシ３４に直接接触して認証メカニズム３２との認証プロセスを開始してよい。この場合メカニズム決定プロセス２６は効率的に省略される。
【００５５】
メカニズム決定プロセス２６は「ブラックボックス」プロセスである。好適な実施形態において、該プロセスはXML形式の入力ドキュメントを受信しゼロまたは１つ以上の認証メカニズム３２のリストを作成する。入力ドキュメントは少なくともサブジェクト２０の名称とドメインとを含む。入力ドキュメントを拡充して一群の認証メカニズム３２の選択を補助する他のデータ（例えば認証ストレングス）を含むようになすこともできる。例えば、サブジェクト２０として、「A.com」において仕事上のアカウントを有し、その他の「B.com」「C.com」等々において様々なアカウントを有するJohn Doe氏を考える。Doe氏は仕事上の立場でZ.comのリソースにアクセスする必要がある場合があり、この場合「JohnDoe@A.com」として認証する必要がある。このためにはZ.comのための適切な認証メカニズム３２の決定が必要とされるが、これはたとえば「＊＠A.com」というマスクを用いて設定され、リソース要求が特定の認証メカニズムを用いるように仕向けてもよい。
【００５６】
メカニズムレポジトリ２８は認証メカニズムについての情報を有するデータベースである。ここで注意すべきことは、「メカニズム」は、各認証メカニズム３２のプロトコルプロキシ３４とどのように接触し協働するか、すなわち例えばどのURLを用いてそこに行くかなどについて正確に特定しているということである。メカニズム決定プロセス２６およびメカニズム登録プロセス３０はメカニズムレポジトリ２８を用いて、認証メカニズム３２をそれぞれ決定および登録する。
【００５７】
メカニズム登録プロセス３０は、認証メカニズム３２がメカニズムレポジトリ２８に自身を登録するため、あるいはメカニズムレポジトリ２８内の自身の情報を変更するために用いるものである。認証に比べると、メカニズム登録プロセス３０は行われる頻度が低い。
【００５８】
各プロトコルプロキシ３４は認証メカニズム３２とクライアント２２とを媒介する。この好適な実施形態では、プロトコルプロキシ３４はクライアント２２と通信にはＸＭＬで表現された標準セキュリティのプロトコルを用い、それぞれに対応する認証メカニズム３２との通信には通信メカニズムに固有のプロトコルを用いる。
【００５９】
認証が成功した場合、認証の最後にプロトコルプロキシ３４はネームアサーション、およびオプションとしてエンタイトルメントを含む署名されたドキュメントを作成する。その例が付録Ａに示されている。
【００６０】
各プロトコルプロキシ３４はそれ自身が信頼できるもの（authentic）であって、有効なネームアサーションを持つものでなければならない。このように、クライアント２２がプロトコルプロキシ３４に対して開示しなければならないのは、秘密事項に係るクリデンシャルのみである。更にサーバアプリケーション３８は、信頼性のあるプロトコルプロキシ３４の作成したネームアサーションのみを信頼すればよい。従ってプロトコルプロキシ３４は自分自身のネームアサーションを用いてクライアント２２を認証し、その認証メカニズム３２に代わって作成したネームアサーションとエンタイトルメントとに署名する。（これについては以下にまた説明する。）
【００６１】
認証メカニズム３２は特定のプロトコルに従ってサブジェクト２０を認証するプロセスである。しかし、プロトコルプロキシ３４はこのために用いられれる認証メカニズム３２の特定のプロトコルをサブジェクト２０およびクライアントに対して秘匿する。従って、認証メカニズム３２は完全に従来型のものであってもよく、その場合でも複数の認証タイプ、認証ソースの方式全体と共に機能することが可能である。これは本発明のFAST１０の提供する大きな利点である。
【００６２】
各ネームアサーションはSRPベリファイアを含んでいる。ネームアサーションの正当な所有者は対応するSRPシークレットを所有している。SRPベリファイアとSRPシークレットを用いれば、任意の二者はSRPプロトコルを用いて互いを認証することができる。FAST１０においては、SRPプロトコルを拡張して任意の二者間での相互認証を可能とする（すなわちクライアント２２とサーバアプリケーション３８の間、クライアント２２とプロトコルプロキシ３４との間等々）。
【００６３】
各ネームアサーションは一群の公開値(public values)を含む。FAST１０において、これら公開値の使用は署名検証のために拡張される。即ち、ネームアサーションの所有者はSRPシークレットを用いて自分自身を認証し、デジタル署名を作成することができる。この所有者がネームアサーションを提示する提示先はこれを用いて所有者を認証しかつ所有者のデジタル署名を検証(verify)することができる。
【００６４】
ネームアサーション自体はこれを作成したプロトコルプロキシ３４によって署名されているので、所有者の署名はその認証された身元(identity)に拘束される。また、ネームアサーションは束の間のものであるから証明書失効リスト(certificate revocation list: CRL)の必要はない。デジタル証明書を用いてそのサブジェクト２０を認証する認証メカニズム３２はネームアサーション有効期間を次のCRL作成と一致するように細かく設定することができる。かくして、サブジェクト２０は次のCRLが発行される以前に自分自身を再認証しなければならない。
【００６５】
クライアント２２はプロトコルプロキシ３４（これは認証メカニズム３２を代理する）を信頼する必要がある。これはクライアント２２から秘密のクリデンシャルを受け取るプロトコルプロキシ３４の場合は特にそうである。従ってプロトコルプロキシ３４はメカニズム−認証メカニズム（メカニズムを認証するメカニズム）に対して認証しなければならない。この種の認証はいずれかの認証メカニズム３２におけるクライアント２２の認証と同一である。その結果として、プロトコルプロキシ３４がクライアント２２との相互認証に入り認証するクライアント２２にたいしてネームアサーションに署名するために用いるネームアサーションが得られる。
【００６６】
プロトコルプロキシ３４がメカニズム−認証メカニズムにおいて認証するとき、プロトコルプロキシ３４はどのクライアント２２もが行うのと同様のネームアサーションを受け取る。このようなネームアサーションはメカニズム−認証メカニズムによって署名されている（より正確に言えば、メカニズム−認証メカニズムに先立って、認証を必要としている、すなわち一時的にクライアント２２として振る舞っているプロトコルプロキシ３４との間の媒介を行っているプロトコルプロキシ３４によって署名されている）。クライアント２２は、メカニズム−認証メカニズムによって提供されたプロトコルプロキシ３４のネームアサーションの署名を検証してその認証性を確かめることができる。これはデジタル証明書の連鎖を検証するのと同様であるが、本件の場合はネームアサーションと証明書とが組み合わされており、すべてのもの（all parties）がデジタル証明書を所有する必要はない（メカニズム−認証メカニズムのみがデジタル証明書を持てばよい）という実際的なソリューションをもたらす点において異なっている。
【００６７】
クライアント２２はまず、プロトコルプロキシ３４との接触を確立することを想起されたい。実際の実施に当たって、もしクライアント２２が認証エージェント２４をプロトコルプロキシ３４として見ることができるとすると、このことは非常に便利である。これは実際FAST１０において可能である。なぜならそれはプロトコルプロキシ３４とクライアント２２とが相互認証セッションを確立することができ、そのプロトコルデータは通過点(pass-thru)として動作するどのプロセスに対しても秘匿されているからである。即ち、認証エージェント２４は透過型プロトコルプロキシ３４(transparent protocol proxy)として振る舞う。この場合、認証エージェント２４は通過点として振る舞う。このことはクライアント２２に非常な便利さと効率を提供するものであり、クライアント２２は認証プロセスのセキュリティ全般を維持しながら、あたかも一つのサーバ（即ち認証エージェント２４）を取り扱っているかのように振る舞う。
【００６８】
FAST１０においては認証タイプおよび認証ソースは抽象化されている。従って任意の認証メカニズム３２を用いた任意のサブジェクト２０の認証を援助することのできるプロトコルプロキシ３４を開発することが可能である。ここでは４つの認証タイプとそれらのFAST１０への導入について説明する。
【００６９】
考えられる第１の導入方法は、ユーザIDとクリデンシャルを用いるものである。これは今日最も多く用いられている認証形態の変型である。ここでは、ユーザ（サブジェクト２０）はプロトコルプロキシ３４に秘密のクリデンシャルを提示する。この秘密クリデンシャルは例えばパスワードやバイオメトリックデータでありうる。
【００７０】
FAST１０はプロトコルプロキシ３４とクライアント２２との間の秘密のリンクを確立することによってこの認証タイプを導入する。この秘密リンクは他のいかなる通信媒介物にも関わらない。言い換えると、クライアント２２とプロトコルプロキシ３４との間の通過点として作用するプロセスはこのデータを認識することができない。
【００７１】
クライアント２２とプロトコルプロキシ３４とは以下のようにして安全なリンクを確立する。第１に、クライアントはプロトコルプロキシ３４とのダイアログを開始する。第２に、プロトコルプロキシ３４は自分自身のネームアサーションをクライアントに提示する。第３に、クライアント２２は受け取ったネームアサーション内のベリファイアを用いてSRPメソッドによりプロトコルプロキシ３４を認証する。第４に、クライアントおよびプロトコルプロキシ３４はＳＲＰメソッドによて安全なリンクを確立する。
【００７２】
クライアント２２がプロトコルプロキシ３４との安全なリンクを一度確立した後、クライアント２２はクリデンシャルを送信し、認証が成功すればプロトコルプロキシ３４からネームアサーションを受け取る。
【００７３】
考えられる第２の導入方法は、ベリファイアに基づく認証を用いるものである。この認証形式においては、クライアント２２が秘密のクリデンシャルを所有していることをプロトコルプロキシ３４に対して証明する。プロトコルプロキシ３４はクライアント２２の秘密クリデンシャルに適合するベリファイアを有している。FAST１０の好適な実施形態では、この認証タイプは相互認証式のSRP（上に述べたようなもの）を用いて導入される。
【００７４】
考えられる第３の導入方法は、PKI方式のデジタル証明書を用いるものである。デジタル証明書を用いる認証は秘密のリンクを必要としない。プロトコルプロキシ３４は標準的な問いかけ／応答(challenge/response)プロトコルを用いてクライアント２２がプライベートキーを所有していることを証明する。認証が成功すれば、クライアント２２はプロトコルプロキシ３４からネームアサーションを受け取る。
【００７５】
考えられる第４の導入方法は、以前に発行されたネームアサーションを用いるものである。各ネームアサーションはベリファイアを含んでおり、そのベリファイアに対応するシークレットは該ネームアサーションの所有者（即ちクライアント２２）が保持している。有効なネームアサーションを持つクライアントは相互認証方式のSRPを用いて、プロトコルプロキシと認証を行う。
【００７６】
以上の説明は本発明の概要をまとめているが、FAST１０にその他の機能を取り入れることもできる。そのうちの一つは認証のストレングス（強度）である。クライアント２２は自身を認証することを望む場合のストレングスを指定することができる。このデータはメカニズム決定プロセス２６への入力とされる。逆に、各ネームアサーションはストレングスの指標を有しており、これがサブジェクト２０が実際に自身を認証する際のストレングスをサーバアプリケーション３８に表示する。クライアント２２は認証要求の一部として他の環境変数を指定することができる。これらの変数はメカニズム決定プロセス２６に入力される。ネームアサーションには有効期限があるが、クライアント２２はそれを所有していることを証明することができ、かつ元のネームアサーションの更新カウント即ち更新期間がさらなる更新を許容するならば、それを更新することができる
【００７７】
FAST１０は複数のメカニズムに対して認証するための特別な設備を必要としない。代わりに、この機能は単にクライアント２２が各認証メカニズム３２において認証し、個別のネームアサーションを受け取ることによって実施される。
【００７８】
ここでFAST１０の２つの実施例を示す。それぞれ実際的な（しかし異なった）配備計画である。第１の実施例の中では、協力しあうパートナーどうしが、組織を横断する認証(cross-organization authentication)を要求する。
【００７９】
図２は本発明のFAST１０のブロックダイアグラムであり、このFAST１０は新たな製品を開発するために協力関係にある２つの企業、アリコ（AliCo）１１２とザイランド（Zyland）１１４（実際の事業者と類似があったとしても全くの偶然である）において用いられている。アリコ１１２とザイランド１１４は、管理制御境界１１６のそれぞれの側にある領域として示されている。両者はアリコ従業員１１８およびザイランド従業員１２０としてそれぞれ形式的に示されている従業員を有している（図１におけるサブジェクト２０の例である、クライアント等はここでは明示されてはいないが存在している、なぜなら人間は直接情報システムにアクセスすることはできないからである）。これらの従業員１１８，１２０は共同でプロジェクトチーム１２２を作っている。
【００８０】
この例においては、アリコ１１２とザイランド１１４との関係は永続的なものではなく、これらの企業は非常に逼迫した製品開発サイクルを有しているものとする。従ってプロジェクトの続く間、プロジェクトチーム１２２のメンバーはパートナー企業の情報システムへのアクセスを必要とする。即ちアリコ従業員１１８およびザイランド従業員１２０は両方の企業のツールを用いる必要があり、これらは形式的にアリコアプリケーション１２４およびザイランドアプリケーション１２６として示されている。
【００８１】
アリコ１１２はアリコ認証メカニズム１２８を有しザイランド１１４はザイランド認証メカニズム１３０を有する（これらは図１の認証メカニズム３２の例である）。これらは企業の各ユーザ（従業員１１８、１２０およびこの例とは無関係の他の多くの人々）を認証する。アリコ１１２が用いるアリコ認証メカニズム１２８はユーザIDとパスワードを用いたLDAPディレクトリである。それに対しザイランドが用いるザイランド認証メカニズム１３０はデジタル証明書と関連する証明書失効リスト（ＣＲＬ）である。そしてアリコ１１２、ザイランド１１４共にそれぞれの従業員のエンタイトルメントを管理するそれぞれ独自の内部システムを用いている。
【００８２】
この状況に対する既存のソリューション（解決手段）は以下のうちの１つ以上を必要とする、即ち、プロジェクトチーム１２２のメンバーが個々にパートナー企業の認証システム１２８、１３０に登録するか；プロジェクトチーム１２２のメンバーがパートナー企業のレポジトリに一連のエンタイトルメントを有するか；両社のソフトウェアツール（アプリケーション１２４、１２６）がパートナー企業の認証プロトコルを理解している（例えばアプリケーションはPKIが可能とされているか、あるいはKerberos化されていなければならない）。
【００８３】
これは直ちに実現不可能なものとなる。一方の企業がある従業員のエンタイトルメントを変更したりクリデンシャルを無効とした場合、パートナー企業側に直ちに知らせなければならない。それに対してパートナー企業は自身のレポジトリにおいて対応する変更を行わなければならない。即時の付加またはアップグレードによってソフトウェアツールの変更も行われるかもしれない。
【００８４】
より単純とされているソリューションでは、プロジェクトチーム１２２の各メンバーが共通に信頼されている証明機関（certificate authority: CA）からのデジタル証明書を取得する必要がある。しかし仮にデジタル証明書の取得および管理が容易であったとしても、そのような証明書に実際上エンタイトルメント情報を含ませることはできない。従って例えば、エンタイトルメントの変更によって証明書は無効となることになる。この理由により、PKI方式においては長命の身元証明書と短命の属性証明書があるのであり、そして今日用いられている証明書の９９％以上が身元証明書なのである。
【００８５】
ここで図２に示すFAST１０を用いたソリューションについて考察する。アリコ１１２およびザイランド１１４は小規模なソフトウェアプロトコルプロキシ１３２、１３４（図１のプロトコルプロキシ３４の例である）をそれぞれの認証ソースに配備し、かつ標準のXMLアダプタ１３６、１３８をそれぞれのアプリケーション１２４、１２６の前に配備する（この例では、アプリケーション１２４，１２６はネームアサーションを直接処理するができず、そのためのアダプタ１３６、１３８を必要とするものと仮定している）。そうすると直ちに、アリコ１１２のアリコアプリケーション１２４はザイランド１１４のザイランド従業員１２０を認識し、その者のエンタイトルメントを決定することができる。その逆も同様に成り立つ。もし一方の企業が自社のユーザのエンタイトルメントを変更したり、あるいはクリデンシャルを無効とした場合、他方の企業は、次回の認証が試みられた際に直ちにそれを知ることができる。図２の説明を終える前に、この図は本発明の単純な実施形態を示したものであって、エージェントドメイン１４およびその構成要素は図示されていないことに注意されたい。ここではプロジェクトチーム１２２の従業員１１８、１２０じはパートナー企業のアプリケーション１２４、１２６にアクセスするのみなので、彼らは容易にそれぞれの必要な認証メカニズム１２８、１３０を知ることができ、それを決定するためのエージェントの補助を必要としない。
【００８６】
今日多くの組織は、組織のセキュリティサービスを外部の管理されたセキュリティサービスプロバイダ（managed security services providers: MSSP）に外注している。MSSPの課題はその業務を合理化し、規模の経済を実現することである。これにより次の例の状況がもたらされる。
【００８７】
図３はMSSP２１０に対して認証を提供する本発明のFAST１０のブロック図である。この第２の例において、MSSP２１０は数百の顧客２１２（図１のサブジェクト２０の例を含む存在）にわたるいくつかのタイプの認証をサポートする必要がある。MSSP２１０は認証プロセスの管理を管理する必要はあるが、認証ソースとなる必要はない。また秘密事項に係るクリデンシャル（例えばパスワード）を知る立場となる必要もない。このことはMSSP２１０とその顧客２１２に数多くの利点をもたらす。MSSP２１０はどんな顧客２１２でも、たとえきわめて高いセキュリティ要求を持った顧客でもサポートすることができる。またMSSP２１０は段階的に拡大するソリューションを提供できる、即ち最小限に管理されたソリューションから完全に管理されたソリューションへと顧客をシフトさせて行くことができる。また、クリデンシャルを知る必要がないため、何らかのセキュリティ侵害から生ずるMSSP２１０の法的責任が軽減される。またMSSP２１０がコストのかかる信頼の輪のルール(chain-of-trust rules)の導入をさけるのを助ける。
【００８８】
この問題の在来のソリューションでは、MSSP２１０は各顧客２１２に対して完全に別々の信頼されたシステムを設定する必要がある。そしてMSSP２１０は各顧客２１２の要求と期待に見合った厳格さで各システムを保護しなければならない。最も重要なことは、このソリューションはオール・オア・ナッシングであり、段階的な配備はできないということである。
【００８９】
ここで図３に描かれたFAST１０によるソリューションについて考察する。MSSP２１０はすべての顧客の認証管理に単一の認証エンジン２１４を配備する。実際の認証ソースは顧客２１２側に置かれても、MSSP２１０に置かれても、第三の場所（例えば図示された認証ドメイン）に置かれてもよい。実際、認証ソースの場所の移動と管理権限の変更（顧客２１２からMSSPへ、またはその逆）は何の困難もなく行うことができる。
【００９０】
図３の例では、認証ソース（図１のプロトコルプロキシ３４と認証メカニズム３２の組み合わせの例）は第三の場所にあるものとして描かれている。この構成は図１および図３において、FAST１０は認証ソースをユーザおよびツール（図１のサブジェクト２０およびサーバアプリケーション３８の例）から完全に取り除いた形態にも適応しうる、という事実を際だたせるために、意図的に用いている。
【００９１】
ここで図４を参照して、FAST１０の概要を説明する。ここでは「連合された(federated)」という用語は二つの特定の意味を持つ、即ち、あるシステムが連合されているとは、該システムは複数の認証タイプ、そして複数の認証ソースをサポートするということである。従来の方法は複数の認証タイプについては対応しているが、複数の認証ソースについては大部分無視している。従って、それらを用いた製品は一つの組織の複数の認証タイプをサポートしてはいるが、組織間の認証はサポートすることができない。本説明において「メカニズム」という用語は特定の認証ソースにおける特定の認証タイプを意味するものとして用いる。
【００９２】
図４はFAST１０がどのように多くの相互作用する要素を含んでいるかを示しており、図１をある程度拡張したものである。サブジェクト３１２は自身を認証する必要のある存在である（即ちユーザ、デバイスなど：なお、ここでもクライアントは示されていなくとも暗に含まれており、人間以外のサブジェクト３１２ではサブジェクトに組み込まれている場合もある）サーバアプリケーション３１４はサブジェクト３１２にサービスを提供する。そのためにはサーバアプリケーション３１４はサブジェクト３１２の認証された身元を知らなければならず、そして場合によってはサブジェクト３１２のエンタイトルメントを知らなければならない。メカニズム登録モジュール３１６は認証メカニズム３１８ａ、３１８ｂ、３１８ｃをサブジェクト３１２に結合するプロセスを行う（例えばalico.comのすべてのユーザはldapserver.alico.comに対して認証を行わなければならない）。メカニズムレポジトリ３２０はメカニズムについての情報、即ちそれらの場所、タイプ、クリデンシャル（例えばデジタル証明書）、プロトコルなどの情報を有するデータベースである。メカニズム決定モジュール３２２はサブジェクト３１２の名称（ネーム）を１つ以上のメカニズムに割り当てる。認証エージェント３２４は適切な認証メカニズムを見出しサブジェクト３１２とプロトコルプロキシ３２６ａ、３２６ｂ、３２６ｃとの認証プロトコルを促進するプロセスである。プロトコルプロキシ３２６ａ、３２６ｂ、３２６ｃは認証エージェント３２４と認証メカニズム３１８ａ、３１８ｂ、３１８ｃとの間のインターフェイスである。
【００９３】
認証タイプごとに一つのプロトコルプロキシ（例えばLDAPユーザID/パスワードプロキシ）がある。プロトコルプロキシは認証メカニズムまたは認証エージェントのどちらかと同じ場所にあってもよく、これらは異なる配備案となる。認証メカニズムは認証タイプと認証場所を具現化した特定のメカニズムである。図４においてプロトコルプロキシ３２６ａ、３２６ｃはそれぞれ認証メカニズム３１８ａ、３１８ｃと共にあり、プロトコルプロキシ３２６ｂは認証エージェント３２４と共にある。
【００９４】
サブジェクト３１２がサーバアプリケーション３１４を用いようとした場合、プロセスは認証エージェント３２４に接触するサブジェクト３１２から開始される。認証エージェント３２４はメカニズム決定モジュール３２２を用いてサブジェクト３１２（例えばjames@alico.com）の名称を処理し、認証メカニズム３１８ａ（例えば）を割り当てる。認証エージェント３２４はプロトコルプロキシ３２６ａ（ここでは例として用いられている）を用いてサブジェクト３１２と認証メカニズム３１８ａとの間でのクリデンシャルの送信を促進する。認証エージェント３２４はサブジェクト３１２がプロトコルプロキシ３２６ａに送る秘密事項に係るクリデンシャル（例えばパスワード）を全く見ていないことに注意されたい。サブジェクト３１２およびプロトコルプロキシ３２６ａはそれぞれ安全なトンネルを確立する。このように、秘密事項に係るクリデンシャルを知る必要のあるメカニズムは認証メカニズムのプロキシと同じ場所にあるのが最良であり、これは図４の認証メカニズム３１８ａとプロトコルプロキシ３２６ａの場合のごとくである。
【００９５】
サブジェクト３１２およびプロトコルプロキシ３２６ａは認証プロセスに入る。サブジェクト３１２が信頼できるものであれば、プロトコルプロキシ３２６ａはネームアサーションとエンタイトルメントからなるデジタル署名されたドキュメントを作成する。本発明者による現在好適な実施形態では、このドキュメントの実際のフォーマットはセキュリティ・サービス・マークアップ・ランゲージ(security service markup language: S2ML)に従ったものであり、これはセキュリティ情報を通信するドラフト段階のXMLスタンダードである。サブジェクト３１２は一度S2MLドキュメントを受信すれば、それをシンプルS2MLのエレメントおよびアトリビュート（属性）を理解するどのアプリケーションにも送ることができる。必要であれば、S2MLを解さないどんなアプリケーションにも（例えば、図４のサーバアプリケーション３１４）、XMLアダプタ３２８を用いてこの能力を与えることができる。
【００９６】
FAST１０の利点はその単純さおよび本来的な安全性にある。FAST10の諸要素はいくつもの仕方で配備することができ、これによって組織のセキュリティおよびビジネス両方の要請を満たす配備計画を作成することができる。
【００９７】
メカニズム決定モジュールは、サブジェクトが動作している環境を考慮に入れたプロセスを実行する。例えばサブジェクトに手持ち（ハンドヘルド）デバイスを介したクリデンシャルの入力を求めるのと、虹彩スキャンデバイスによってそのようなものを取得するのとではかなり異なっている。このように、サブジェクトは所望のどのような仕方でも認証を行うことができ、このことはより積極的な経験に導く。
【００９８】
認証メカニズムを改変する必要はない。その代わりにプロトコルプロキシが認証エージェントと認証メカニズムとの間のインターフェイスを行う。それにより、組織はその既存のメカニズムをすぐに用いることができ、これによってコストを節約し、出費を抑えることができる。
【００９９】
認証はアプリケーションから分離される。これにより、組織は組織のサブジェクトによって用いられている組織自身のアプリケーションまたは第三者のアプリケーションを変更する必要なしに、該組織の基礎的認証メカニズムを、徐々にあるいは一度に変更することができる。認証メカニズムは該メカニズムを所有する場所において（即ち該メカニズムの管理制御の境界内において）動作する。認証メカニズムとサブジェクトとの間の情報交換はプライベート（私秘的）である。従って、認証エージェントは秘密事項に係るクリデンシャルを見たり、盗んだりすることはできない。
【０１００】
サブジェクトは人間のユーザである必要はない。それはアプリケーション、デバイス、プロセスなどであってもよい。従って、FAST１０は人間のサブジェクト、人間以外のサブジェクトを包含する複数の環境に適用可能である。
【０１０１】
FAST１０の諸要素はどの場所で動作することもでき、またそれら要素は異なる制御ドメイン内に存在しうるので、各要素が内的にかつ他の要素との通信において安全（セキュア）であることが絶対に必要である。このFAST１０の全体的セキュリティについてここで説明する。
【０１０２】
引き続き図４を参照すると、認証エージェント３２４はサブジェクト３１２とプロトコルプロキシ３２６ａとの間の認証要求と応答とを媒介する。しかし、いかなる場合も認証エージェント３２４は秘密のクリデンシャルを見ることはできない。これはサブジェクト３１２とプロトコルプロキシ３２６ａとが、認証エージェントの知らない秘密キーを設定するからである。更に、認証エージェント３２４は認証結果（S2MLによるネームアサーションとエンタイトルメント）を改変することができない。これはプロトコルプロキシ３２６ａが認証応答にデジタル署名しているからである。
【０１０３】
図４に示されたFAST１０の例において、破線はエージェントドメイン３３０の境界を示している。サブジェクト３１２とプロトコルプロキシ３２６ａ、３２６ｂ、３２６ｃとの間のすべての通信はエージェントドメインを通過していることが見て取れるだろう。しかしながら、この構成の場合でさえも、すぐ上に述べた理由により安全である。
【０１０４】
プロトコルプロキシはサブジェクト３１２との間に安全なプロトコルを確立する。プロトコルプロキシは認証エージェント３２４と同じ場所で動作することもできるし（図４におけるプロトコルプロキシ３２６ａのごとく）、または認証メカニズムと同じ場所で動作することもできる（図４における、認証メカニズム３１８と共にあるプロトコルプロキシ３２６ａのごとく）。サブジェクト３１２が秘密事項に係るクリデンシャルを送るような場合には、プロトコルプロキシは認証エージェント３２４と同じ場所で動作するのが最良である。
【０１０５】
プロトコルプロキシは署名されたS2MLネームアサーションおよびエンタイトルメントを作成する。サブジェクト３１２はこのS2MLドキュメントを用いて任意のサーバ（例えばサーバアプリケーション３１４）に対して認証を行う。この点にFAST１０と他の認証アーキテクチュアとの重要な相違がある。他の認証アーキテクチュア（たとえばKerberos）においては、ネームアサーションは特定のサーバに向けられたものである。そのため、サーバはこのネームアサーションを盗むことができない。しかしながら、このような方式におけるサブジェクトはそれぞれのサーバに対して別々のネームアサーションを必要とすることになる。
【０１０６】
S2MLドキュメントの再生や盗難を防止するために、プロトコルプロキシはサブジェクトにSRPシークレットを送り、かつサーバアプリケーション用のSRPベリファイアをS2MLドキュメント中に入れる。このようにして、サーバはサブジェクトがS2MLドキュメントの元々の意図された受取者であることを常に検証するが、サーバはS2MLドキュメントを用いてサブジェクトを装うことはできない。要するに、S2MLネームアサーションおよびエンタイトルメントは、サーバがサブジェクトの認証にのみ用いることのできるデジタル証明書と類似したものである。
【０１０７】
認証メカニズムはFAST１０のその他の要素と直接通信することはない。その代わり、プロトコルプロキシが認証メカニズムとFAST１０の他の要素との間のインターフェイスとなる。このようにして、プロトコルプロキシと認証メカニズムとの間の通信は所望通りに安全となすことができる。
【０１０８】
FAST１０は広く用いられ信頼されているセキュリティ産業のスタンダードを用いることができる。例えば、X.509 version 3のデジタル証明書を用いてもよい。FAST１０の要素はこうしたデジタル証明書をSSL/TLS接続やデジタル署名検証の基盤として用いることができる。上にも述べたように、セキュリティサービスマークアップランゲージ（S2ML）を用いてもよい。プロトコルプロキシはS2ML方式に則ったXMLドキュメントを作成することができる。XMLデジタル署名もまた、使用可能な別のスタンダードである。FAST１０はS2MLネームアサーションおよびエンタイトルメントの電子署名の作成に、XML署名仕様を用いてもよい。セキュアリモートパスワード（SRP）スタンダードを使用すれば、FASTはRFC2945に記載されているようなSRP認証およびキー交換システムを用いることができる。更に、ここに説明したSRPの改良バージョンはまた別の利点を有する。FAST１０はプロトコルデータの私秘性(privacy)および完全性(integrity)を守るために、様々なスタンダードの暗号化およびメッセージダイジェストアルゴリズムを用いることもできる。これらは、Diffe-Hellman、RSA、AES、SHA-1、およびRFC2104に規定されているようなメッセージ認証のための鍵付きハッシングであってもよい。
【０１０９】
情報を企業の境界をこえて共有することができれば、組織は企業内ビジネスを創出することができ、競争上の優位性を得ることができる。同時に情報は重要な企業資産であり、その価値に応じて保護されなければならない。情報を守るために組織はユーザの身元を確かめる必要がある。
【０１１０】
実世界においては我々一人一人が知られており、多くの方法で認証することができる。友人や家族は声や外見で我々を知っており、金融機関や法的機関は署名や公的に発行された身分証で我々を知り、また法執行機関は指紋で我々を知る。
【０１１１】
全世界的な単一サインオンは単一の認証ソースを意味するものではないし、単一の認証タイプを意味するのでもない。結局のところ、複数の連合された認証ソースを効率的に用いることこそが、全世界的な単一サインオンを実現するのである。
【０１１２】
FAST１０は、異なる制御ドメインからの複数の認証タイプ複数の認証ソースを用いることを可能にする現在唯一の技術である。FAST１０を用いることによって、組織はきわめて厳格なセキュリティ条件を満たしながら、組織の既存の情報システムを用いて、迅速にビジネス関係を実現することができる。
【０１１３】
以上において様々な実施形態を説明してきたが、それらは例として示したものであり、本発明を限定するものではないことを理解されたい。従って、本発明の範囲は以上に説明した例示のための実施形態に限定されるものではなく、添付の請求の範囲およびその均等物にしたがって定義されるものである。
【産業上の利用可能性】
【０１１４】
このFAST１０はサーバアプリケーション３８、１２４、１２６、３１４に対するサブジェクト２０、１１８、１２０、２１２、３１２の認証に、好適に用いられる。FAST１０は図２に示すように、少数のサブジェクトとサーバアプリケーション用の小規模のものとすることもでき、または図３に示すように、潜在的には数千の数の大規模のものとすることもできる。これらは今現在存在している需要であり、これにFAST１０は十分に応えるものであり、かつFAST１０を導入して直ちにこれに応えることもできる。
【０１１５】
FAST１０は異なる制御ドメインの複数の認証タイプと複数の認証ソースの使用を可能とし、しかもそれらが互いにどれほど非協和的なものであってもかまわない。FAST１０は認証タイプとソースの両方を単純に抽象化する。従って、諸組織は所望のセキュリティインフラストラクチュアを選択し、組織の既存のセキュリティインフラストラクチュアを利用しながら、きわめて厳格なセキュリティ条件を満たしてビジネス関係を形成することができる。
【０１１６】
複数の認証タイプをサポートできるので、諸組織はある一つの認証タイプを配備し、そして例えば必要に応じてあるいはより強力な認証タイプが開発された場合に、他の所望の認証タイプに移行することができる。Kerberosやパブリックキーインフラストラクチュアのような既存の認証技術は、すべてのユーザにおいてその技術を有効化することを必要とする。これにより企業全体に対して完全導入か導入しないかの二者択一式の計画となる。これに対してFAST１０を用いれば、ユーザやサーバに影響を与えることなく認証メカニズムを変更することができる。複数の認証ソースをサポートできることにより、ユーザおよびサーバは認証場所を選択することができる。例えば、支払いのためにはユーザは自分の銀行において認証しなければならない。しかし医療記録を閲覧するためにはユーザは自分の医療サービス提供者もしくは場合によっては雇い主に対して認証しなければならないだろう。
【０１１７】
FAST１０はネームアサーションを用いた署名の作成と検証を可能とする。これにより署名の作成と検証のためにデジタル署名を用いる必要が無くなり、署名作成および検証のスピードと効率が向上する。ネームアサーションは既存のネームアサーションを更新する基盤として用いることもできる。これにより認証が必要となるたびにデジタル証明書を用いる必要がなくなり、認証プロセスのスピードと効率が向上する。
【０１１８】
これまで述べてきたように、FAST１０はKerberosユーティリティやパブリックキーインフラストラクチュア（PKI）方式、そしてまた特にセキュアリモートパスワード(SRP)プロトコルを用いることができ、かつそれらを改良することができるものであり、強力で相互的な認証プロトコルを導入することによってそれらを改良する。
【０１１９】
FAST１０は本来的に安全である。FAST１０は信頼性の階層(hierarchy of trust)を許容し、そこでは認証メカニズムは自分自身を認証しなければならない。このようにしてあるサブジェクトは秘密事項に係るクリデンシャルを認証された(authenticな)メカニズムに対してのみ開示し、認証されたメカニズムのみを信頼すればよい。FAST１０はまたクリデンシャルの期限切れについても融通性があり、何者がクリデンシャルの有効期間を設定したかという点について厳格で融通性のない従来アーキテクチュアの制約を解決する。FAST１０において、クライアント、サーバあるいはメカニズムがクリデンシャルの期限切れを要求することができる。
以上およびその他の理由により、本発明のFAST１０は広い産業上の利用性を有するであろう。従って、本発明の商業的利用は広範囲かつ長期間にわたるであろうと予想される。
【０１２０】
（用語集）
認証エージェントAuthentication Agent:
サブジェクトと認証メカニズムとの間の認証を援助促進するプロセス。認証エージェント自体はサブジェクトの認証を行うことはない。
認証メカニズム Authentication Mechanism:
特定のプロトコルに従ってサブジェクトを認証するプロセス。
管理ドメイン Administrative domain:
同一の団体の管理下にあるデバイス、人およびプロセスの集まり。
管理制御の境界 Boundary of Administrative Control:
管理ドメイン間の境界。
クライアント Client:
サブジェクトが自分自身を認証するために用いるプロセス。
クライアントアプレット Client Applet:
クライアントの特定の実行であって、認証コードが動的にダウンロードされるか、またはクライアント上に局在しており、かつブラウザーで実行されることができる。
クライアントアプリケーション Client Application:
クライアントの特定の実行であって、認証コードはクライアント上に存在し独立プロセスとして実行される。
クリデンシャル（信用証明） Credential:
主張された身元(identity)を確立するために提示されるデータ。
エンタイトルメント（権利付与） Entitlement:
アクセス決定情報を含むデータ構造。サーバはエンタイトルメントを用いてサブジェクトに許可する行為を決定する。
メカニズム−認証メカニズム Mechanism-Authentication; Mechanism:
他の認証メカニズムをサブジェクトとして認証することのできる認証メカニズム。
メカニズム登録 Mechanism Registration:
認証メカニズムが自分自身をメカニズムレポジトリに登録するために用いるプロセス。
メカニズムレポジトリ（メカニズム格納所） Mechanism Repository:
認証メカニズムについての情報を格納している格納所。この情報はメカニズムのタイプ、そのプロトコル、そのストレングス、およびクライアントがどうすればそれにコンタクトできるかについての情報を含む。
メカニズム決定 Mechanism Resolution:
サブジェクトについてのある情報（例えば名称と領域）を一連の認証メカニズムにマッピングするプロセス。
ネームアサーション（名称言明） Name Assertion:
身元の宣言を含む署名されたデータ構造。ネームアサーションは主張された身元を確立するために提示される。ネームアサーションはクリデンシャルの一種である。
プロトコルプロキシ Protocol Proxy:
互いのプロトコルを解さない２つのプロセスを仲介するプロセス。
ドメイン Domain:
認証オーソリティの領域。認証メカニズムは一つ以上のドメイン内のサブジェクトを認証することができる。
サーバ Server:
クライアントを通じてサブジェクトにサービスを提供するプロセス。サーバはサブジェクトに自分自身を認証することを要求する。場合によっては、サーバもまた自分自身をクライアント／サブジェクトに対して認証しなければならない。
サーバアプリケーション Server Application:
サーバプロセスの機能性を実行するアプリケーション。多くの場合、サーバとサーバアプリケーションとは同義語である。
ストレングス Strength:
認証の厳格性を示す指標。
サブジェクト Subject:
ユーザー、アプリケーション、デバイス、プロセス、その他認証を必要とするあらゆる存在。
（付録A）
１．これはクライアント２２からプロトコルプロキシ３４へ向かう認証要求の例である。
【図面の簡単な説明】
【０１２１】
【図１】本発明において、異なる管理ドメインにおいて動作する協働する一群の構成要素がどのように含まれるかを示すブロック図である。
【図２】新たな製品開発のために共同する２つの企業が本発明を利用した例を示すブロック図である。
【図３】外部の管理されたセキュリティサービスプロバイダ(MSSP)が顧客に認証を提供する際に本発明を利用して例を示すブロック図である。
【図４】本発明において、多くの相互作用する諸要素がどのように含まれるかを示す、図１を拡張したブロック図であり、複数の認証メカニズムの様々なオプションや利用法を示すものである。
Claims (41)
- ネットワークのサブジェクトドメインにあるサブジェクトをネットワークのサーバドメインにあるサーバアプリケーションに対して認証するシステムであって、ネットワーク認証ドメインにある認証メカニズムがサーバアプリケーションによって提供されるサービスに影響を与えるシステムにおいて、
このシステムの他の要素と通信し、サブジェクトを代理してクライアントネームアサーションを提供することによってサブジェクトをこのシステムの他の要素に対して認証するクライアントであって、サブジェクトドメインにあるクライアントと、
前記クライアントと認証メカニズムとの間で通信を行い、かつ認証メカニズムから前記クライアントがサーバアプリケーションにアクセスするためのクリデンシャルを取得し、かつ前記クリデンシャルから前記クライアントがサーバアプリケーションにアクセスすることを可能にする認証ネームアサーションを作成するプロトコルプロキシと、
を備えることを特徴とするシステム。 - サブジェクトは人間ではなく、前記クライアントはサブジェクトに組み込まれており、前記クライアントはサブジェクトのためにサブジェクトのクリデンシャルを収集して、該サブジェクトのクリデンシャルを前記プロトコルプロキシに通信する請求項１記載のシステム。
- 請求項１記載のシステムであって、ネットワーク内に複数の認証メカニズムが存在しており、該システムは、システム内の他の要素と通信しかつ前記クライアントと相互作用して前記複数の認証メカニズムの中から適切な認証メカニズムを選択するエージェントであって、ネットワークのエージェントドメインにあるエージェントを更に有するシステム。
- 前記クライアントは前記プロトコルプロキシと相互作用して認証メカニズムの明細事項を決定し、かつ前記クライアントは前記明細事項を前記エージェントに通信する請求項３記載のシステム。
- 前記クライアントは前記サーバアプリケーションのために前記複数の認証メカニズムの中から前記適切な認証メカニズムを決定するためのコールバックメカニズムを備える請求項３記載のシステム。
- 前記コールバックメカニズムはサブジェクトと相互作用して前記適切な認証メカニズムを決定する請求項５記載のシステム。
- 前記コールバックメカニズムはコンフィギュレーションレポジトリにアクセスして前記適切な認証エージェントを決定する請求項５記載のシステム。
- 前記エージェントは前記複数の認証メカニズムからサーバアプリケーションが提供するサービスに影響を与える認証メカニズムのゼロ個以上からなる部分集合を決定するためのメカニズム決定手段を備える請求項３記載のシステム。
- 前記エージェントは前記クライアントと前記メカニズム決定手段とを媒介するエージェントを更に備える請求項８記載のシステム。
- 前記エージェントは前記複数の認証メカニズムについての情報を記憶するメカニズムレポジトリを更に備え、前記メカニズム決定手段は、前記サーバアプリケーションが提供するサービスに影響を与える認証メカニズムのゼロ個以上の組を決定するにあたり、前記メカニズムレポジトリに問い合わせを行う請求項８記載のシステム。
- 前記エージェントは前記認証メカニズムが自分自身の情報を付加することによって前記メカニズムレポジトリに登録するためのメカニズム登録手段を更に備える請求項１０記載のシステム。
- 前記メカニズム登録手段は更に、認証メカニズムが自分自身の情報を変更することで前記メカニズムレポジトリにおいて自分自身を更新するためのものである請求項１１記載のシステム。
- 前記プロトコルプロキシはネットワークの前記エージェントドメインにある請求項４記載のシステム。
- 前記プロトコルプロキシはネットワークの認証ドメインにある請求項１記載のシステム。
- 前記プロトコルプロキシは標準のセキュリティプロトコルを用いて前記クライアントと通信し、認証メカニズムとの通信にはメカニズムに固有のプロトコルを用いる請求項１記載のシステム。
- 少なくとも一つの前記クライアントおよび前記プロトコルプロキシはSRPプロトコルを用いて認証を行う請求項１記載のシステム。
- 前記プロトコルプロキシは署名されたネームアサーションを作成する請求項１記載のシステム。
- 前記署名されたネームアサーションはS2MLドキュメントに含まれる請求項１８記載のシステム。
- 前記プロトコルプロキシは更に署名されたネームエンタイトルメントを作成する請求項１８記載のシステム。
- 前記プロトコルプロキシはネームアサーションを用いて自分自身をクライアントに対して認証する請求項１記載のシステム。
- 前記認証ネームアサーションを受信し、前記クリデンシャルを再作成し、前記クライアントが前記クリデンシャルに基づいてサーバアプリケーションにアクセスすることを可能にするアダプタを更に備える請求項１記載のシステム。
- ネットワークのサブジェクトドメインにあるサブジェクトをネットワークのサーバドメインにあるサーバアプリケーションに対して認証する方法であって、該方法においてネットワーク認証ドメインにある認証メカニズムがサーバアプリケーションによって提供されるサービスに影響を与えるものであり、
（ａ） クライアントを用いてサブジェクトを代理してサブジェクトのクリデンシャルを提供することによってサブジェクトをプロトコルプロキシに対して認証することと、
（ｂ） 認証メカニズムを介して前記プロトコルプロキシから前記クライアントがサーバアプリケーションにアクセスすることを可能とするネームアサーションを取得し、それによって前記プロトコルプロキシと認証メカニズムとの間を媒介し、サブジェクトが前記クライアントを介してサーバアプリケーションにアクセスすることを可能とすることと、
（ｃ） 前記サブジェクトのクリデンシャルに基づいて、前記プロトコルプロキシによって、前記クライアントがサーバアプリケーションにアクセスすることを可能とする認証ネームアサーションを作成することと、
（ｄ） 前記認証ネームアサーションを前記クライアントに通信することと、
（ｅ） 前記認証ネームアサーションをサーバアプリケーションに通信することと、
を含むことを特徴とする方法。 - 請求項２３記載の方法であって、サブジェクトは人間ではなく、前記クライアントはサブジェクトに組み込まれており、該方法は更に、
サブジェクトのためにサブジェクトのクリデンシャルをクライアントによって収集すること、および
前記サブジェクトのクリデンシャルを前記プロトコルプロキシに通信すること、
を含む方法。 - 請求項２３に記載の方法であって、ネットワーク内に複数の認証メカニズムが存在し、該方法は更に、
前記クライアントとエージェントとの間での相互作用を行い、前記複数の認証メカニズムの中から適切な認証メカニズムを選択することを含み、
前記エージェントはネットワークのエージェントドメインにある方法。 - 請求項２５に記載の方法であって、
前記クライアントと前記プロトコルプロキシとの間での相互作用を行って認証メカニズムの明細事項を決定することと、
前記明細事項を前記クライアントによって前記エージェントに通信することと、
を更に含む方法。 - 請求項２５に記載の方法であって、前記複数の認証メカニズムの中からサーバアプリケーションにアクセスするための適切な認証メカニズムを決定することを更に含む方法。
- 請求項２７に記載の方法であって、前記サブジェクトと相互作用して前記適切な認証メカニズムを決定することを更に含む方法。
- 請求項２７に記載の方法であって、コンフィギュレーションレポジトリにアクセスして前記適切な認証メカニズムを決定することを更に含む方法。
- 請求項２７に記載の方法であって、
（ｆ） 前記複数の認証メカニズムからサーバアプリケーションが提供するサービスに影響を与える認証メカニズムのゼロ個以上からなる部分集合を決定すること、
を更に含む方法。 - 請求項３０に記載の方法であって、前記エージェントは更に認証エージェントを備え、該方法は更に、
前記ステップ（ｆ）において、認証エージェントと前記クライアントとの間を媒介すること、
を含む方法。 - 請求項３０に記載の方法であって、前記エージェントドメインはメカニズムレポジトリを更に含み、該方法は更に
前記複数の認証メカニズムについての情報を前記メカニズムレポジトリに記憶すること、および
前記ステップ（ｆ）において前記メカニズムレポジトリに問い合わせすること、
とを含む方法。 - 請求項３２に記載の方法であって、認証メカニズムについての情報を付加することにより認証メカニズムを前記メカニズムレポジトリに登録することを更に含む方法。
- 前記プロトコルプロキシがネットワークの前記エージェントドメインにある請求項２５記載の方法。
- 前記プロトコルプロキシがネットワークの前記認証ドメインにある請求項２３記載の方法。
- 前記プロトコルプロキシは標準のセキュリティプロトコルを用いて前記クライアントと通信し、認証メカニズムとの通信にはメカニズムに固有のプロトコルを用いる請求項２３記載の方法。
- 少なくとも一つの前記クライアントおよび前記プロトコルプロキシはSRPプロトコルを用いて認証を行う請求項２３記載の方法。
- 前記プロトコルプロキシは署名されたネームアサーションを作成する請求項２３記載の方法。
- 前記署名されたネームアサーションはS2MLドキュメントに含まれる請求項３８記載の方法。
- 前記プロトコルプロキシは更に署名されたネームエンタイトルメントを作成する請求項３８記載の方法。
- 前記プロトコルプロキシはネームアサーションを用いて自分自身をクライアントに対して認証する請求項２３記載の方法。
- 請求項２３記載の方法であって、アダプタを更に含み、該方法は、
前記アダプタを用いて前記認証ネームアサーションを受信することと、
前記アダプタを用いて前記クリデンシャルを再作成することと、
前記クライアントが前記クリデンシャルに基づいてサーバアプリケーションにアクセスすることを可能にすることと、
を更に含む方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/827,697 US6959336B2 (en) | 2001-04-07 | 2001-04-07 | Method and system of federated authentication service for interacting between agent and client and communicating with other components of the system to choose an appropriate mechanism for the subject from among the plurality of authentication mechanisms wherein the subject is selected from humans, client applications and applets |
| PCT/US2002/008796 WO2002082296A1 (en) | 2001-04-07 | 2002-03-20 | Federated authentication service |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004537090A true JP2004537090A (ja) | 2004-12-09 |
| JP2004537090A5 JP2004537090A5 (ja) | 2005-12-22 |
Family
ID=25249902
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002580193A Pending JP2004537090A (ja) | 2001-04-07 | 2002-03-20 | 連合認証サービス |
Country Status (5)
| Country | Link |
|---|---|
| US (2) | US6959336B2 (ja) |
| EP (1) | EP1386243A4 (ja) |
| JP (1) | JP2004537090A (ja) |
| CA (1) | CA2443670A1 (ja) |
| WO (1) | WO2002082296A1 (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007148974A (ja) * | 2005-11-30 | 2007-06-14 | Fuji Xerox Co Ltd | 認証エージェント装置および認証方法 |
| JP2010531516A (ja) * | 2007-06-25 | 2010-09-24 | マイクロソフト コーポレーション | 安全でないネットワークを介する装置のプロビジョニング及びドメイン加入エミュレーション |
Families Citing this family (106)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7596606B2 (en) | 1999-03-11 | 2009-09-29 | Codignotto John D | Message publishing system for publishing messages from identified, authorized senders |
| US8719562B2 (en) * | 2002-10-25 | 2014-05-06 | William M. Randle | Secure service network and user gateway |
| EP1225499A3 (en) * | 2001-01-19 | 2004-03-24 | Matsushita Electric Industrial Co., Ltd. | Data processor for processing data with a digital signature |
| US7237257B1 (en) * | 2001-04-11 | 2007-06-26 | Aol Llc | Leveraging a persistent connection to access a secured service |
| US7305701B2 (en) * | 2001-04-30 | 2007-12-04 | Microsoft Corporation | Methods and arrangements for controlling access to resources based on authentication method |
| US20020161904A1 (en) * | 2001-04-30 | 2002-10-31 | Xerox Corporation | External access to protected device on private network |
| WO2003003295A1 (en) * | 2001-06-28 | 2003-01-09 | Trek 2000 International Ltd. | A portable device having biometrics-based authentication capabilities |
| JP2003069559A (ja) * | 2001-08-23 | 2003-03-07 | Sony Corp | コンテンツ保護システム |
| US7107446B2 (en) * | 2001-08-30 | 2006-09-12 | International Business Machines Corporation | Mechanism independent cluster security services |
| US7080092B2 (en) * | 2001-10-18 | 2006-07-18 | Bea Systems, Inc. | Application view component for system integration |
| US7676829B1 (en) * | 2001-10-30 | 2010-03-09 | Microsoft Corporation | Multiple credentials in a distributed system |
| JP3983035B2 (ja) * | 2001-11-19 | 2007-09-26 | 富士通株式会社 | ユーザ端末認証プログラム |
| US7318238B2 (en) * | 2002-01-14 | 2008-01-08 | Microsoft Corporation | Security settings for markup language elements |
| US7107615B2 (en) * | 2002-01-30 | 2006-09-12 | Hewlett-Packard Development Company, L.P. | Parameter verification in an authentication system and method |
| US7219231B2 (en) * | 2002-01-30 | 2007-05-15 | Hewlett-Packard Development Company, L.P. | Extensible authentication system and method |
| US7228417B2 (en) * | 2002-02-26 | 2007-06-05 | America Online, Inc. | Simple secure login with multiple-authentication providers |
| US7191467B1 (en) * | 2002-03-15 | 2007-03-13 | Microsoft Corporation | Method and system of integrating third party authentication into internet browser code |
| US7353383B2 (en) * | 2002-03-18 | 2008-04-01 | Jpmorgan Chase Bank, N.A. | System and method for single session sign-on with cryptography |
| US7290141B2 (en) * | 2002-06-27 | 2007-10-30 | Nokia, Inc. | Authentication of remotely originating network messages |
| US7747856B2 (en) * | 2002-07-26 | 2010-06-29 | Computer Associates Think, Inc. | Session ticket authentication scheme |
| ATE306776T1 (de) * | 2002-10-22 | 2005-10-15 | Verfahren und system zur authentifizierung von benutzern in einem telekommunikationssystem | |
| US7334013B1 (en) | 2002-12-20 | 2008-02-19 | Microsoft Corporation | Shared services management |
| US20040128541A1 (en) * | 2002-12-31 | 2004-07-01 | Iinternational Business Machines Corporation | Local architecture for federated heterogeneous system |
| US8561161B2 (en) * | 2002-12-31 | 2013-10-15 | International Business Machines Corporation | Method and system for authentication in a heterogeneous federated environment |
| US8554930B2 (en) * | 2002-12-31 | 2013-10-08 | International Business Machines Corporation | Method and system for proof-of-possession operations associated with authentication assertions in a heterogeneous federated environment |
| US20040128542A1 (en) * | 2002-12-31 | 2004-07-01 | International Business Machines Corporation | Method and system for native authentication protocols in a heterogeneous federated environment |
| US7076488B2 (en) * | 2003-01-29 | 2006-07-11 | Hewlett-Packard Development Comapny, L.P. | XML-LDAP adapters and methods therefor |
| US7428750B1 (en) * | 2003-03-24 | 2008-09-23 | Microsoft Corporation | Managing multiple user identities in authentication environments |
| US8108920B2 (en) * | 2003-05-12 | 2012-01-31 | Microsoft Corporation | Passive client single sign-on for web applications |
| US7562390B1 (en) * | 2003-05-21 | 2009-07-14 | Foundry Networks, Inc. | System and method for ARP anti-spoofing security |
| US7516487B1 (en) | 2003-05-21 | 2009-04-07 | Foundry Networks, Inc. | System and method for source IP anti-spoofing security |
| US20040255154A1 (en) * | 2003-06-11 | 2004-12-16 | Foundry Networks, Inc. | Multiple tiered network security system, method and apparatus |
| US7305705B2 (en) * | 2003-06-30 | 2007-12-04 | Microsoft Corporation | Reducing network configuration complexity with transparent virtual private networks |
| US7876772B2 (en) | 2003-08-01 | 2011-01-25 | Foundry Networks, Llc | System, method and apparatus for providing multiple access modes in a data communications network |
| US7735114B2 (en) * | 2003-09-04 | 2010-06-08 | Foundry Networks, Inc. | Multiple tiered network security system, method and apparatus using dynamic user policy assignment |
| US8176320B1 (en) * | 2003-09-11 | 2012-05-08 | Voice Signals Llc | System and method for data access and control |
| US7774833B1 (en) | 2003-09-23 | 2010-08-10 | Foundry Networks, Inc. | System and method for protecting CPU against remote access attacks |
| US8015301B2 (en) * | 2003-09-30 | 2011-09-06 | Novell, Inc. | Policy and attribute based access to a resource |
| US7467415B2 (en) * | 2003-09-30 | 2008-12-16 | Novell, Inc. | Distributed dynamic security for document collaboration |
| US7299493B1 (en) * | 2003-09-30 | 2007-11-20 | Novell, Inc. | Techniques for dynamically establishing and managing authentication and trust relationships |
| US7574603B2 (en) * | 2003-11-14 | 2009-08-11 | Microsoft Corporation | Method of negotiating security parameters and authenticating users interconnected to a network |
| US8528071B1 (en) * | 2003-12-05 | 2013-09-03 | Foundry Networks, Llc | System and method for flexible authentication in a data communications network |
| US20050138408A1 (en) * | 2003-12-22 | 2005-06-23 | International Business Machines Corporation | Autonomic self-configuring alternate operating system environment which includes personalization |
| CA2561906C (en) | 2004-03-30 | 2014-03-25 | International Business Machines Corporation | System, method and program for user authentication, and recording medium on which the program is recorded |
| US7467399B2 (en) | 2004-03-31 | 2008-12-16 | International Business Machines Corporation | Context-sensitive confidentiality within federated environments |
| US8528063B2 (en) * | 2004-03-31 | 2013-09-03 | International Business Machines Corporation | Cross domain security information conversion |
| US7506369B2 (en) * | 2004-05-27 | 2009-03-17 | Microsoft Corporation | Secure federation of data communications networks |
| US8607322B2 (en) * | 2004-07-21 | 2013-12-10 | International Business Machines Corporation | Method and system for federated provisioning |
| US7890992B2 (en) * | 2004-08-19 | 2011-02-15 | Cisco Technology, Inc. | Method and apparatus for selection of authentication servers based on the authentication mechanisms in supplicant attempts to access network resources |
| JP2006139747A (ja) * | 2004-08-30 | 2006-06-01 | Kddi Corp | 通信システムおよび安全性保証装置 |
| GB0419479D0 (en) * | 2004-09-02 | 2004-10-06 | Cryptomathic Ltd | Data certification methods and apparatus |
| ES2253101B1 (es) * | 2004-09-17 | 2007-07-16 | Vodafone España, S.A. | Metodo de solicitud y envio de vectores de autenticacion. |
| US7784092B2 (en) * | 2005-03-25 | 2010-08-24 | AT&T Intellectual I, L.P. | System and method of locating identity providers in a data network |
| US7748046B2 (en) * | 2005-04-29 | 2010-06-29 | Microsoft Corporation | Security claim transformation with intermediate claims |
| CN100571134C (zh) | 2005-04-30 | 2009-12-16 | 华为技术有限公司 | 在ip多媒体子系统中认证用户终端的方法 |
| CN100461942C (zh) * | 2005-05-27 | 2009-02-11 | 华为技术有限公司 | Ip多媒体子系统接入域安全机制的选择方法 |
| US8078740B2 (en) | 2005-06-03 | 2011-12-13 | Microsoft Corporation | Running internet applications with low rights |
| US7610345B2 (en) | 2005-07-28 | 2009-10-27 | Vaporstream Incorporated | Reduced traceability electronic message system and method |
| US9282081B2 (en) | 2005-07-28 | 2016-03-08 | Vaporstream Incorporated | Reduced traceability electronic message system and method |
| US7698555B2 (en) * | 2005-08-29 | 2010-04-13 | Schweitzer Engineering Laboratories, Inc. | System and method for enabling secure access to a program of a headless server device |
| WO2007027958A1 (en) * | 2005-08-29 | 2007-03-08 | Junaid Islam | ARCHITECTURE FOR MOBILE IPv6 APPLICATIONS OVER IPv4 |
| US20070094400A1 (en) * | 2005-10-20 | 2007-04-26 | Childress Rhonda L | Software installation within a federation |
| CA2524849A1 (en) * | 2005-10-28 | 2007-04-28 | Overcow Corporation | Method of providing secure access to computer resources |
| US20070101400A1 (en) * | 2005-10-31 | 2007-05-03 | Overcow Corporation | Method of providing secure access to computer resources |
| US20070101145A1 (en) * | 2005-10-31 | 2007-05-03 | Axalto Inc. | Framework for obtaining cryptographically signed consent |
| JP4218767B2 (ja) * | 2006-03-22 | 2009-02-04 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 秘密保持が要求されるモデルの認証設定のための情報処理装置 |
| US20070255958A1 (en) * | 2006-05-01 | 2007-11-01 | Microsoft Corporation | Claim transformations for trust relationships |
| US8185737B2 (en) | 2006-06-23 | 2012-05-22 | Microsoft Corporation | Communication across domains |
| JP4882546B2 (ja) * | 2006-06-28 | 2012-02-22 | 富士ゼロックス株式会社 | 情報処理システムおよび制御プログラム |
| US7949867B2 (en) * | 2006-07-19 | 2011-05-24 | Rel-Id Technologies, Inc. | Secure communications |
| US20080077704A1 (en) * | 2006-09-24 | 2008-03-27 | Void Communications, Inc. | Variable Electronic Communication Ping Time System and Method |
| US8307099B1 (en) | 2006-11-13 | 2012-11-06 | Amazon Technologies, Inc. | Identifying use of software applications |
| US8010795B2 (en) * | 2006-11-27 | 2011-08-30 | Red Hat, Inc. | Secure information transfer using dedicated public key pairs |
| US8613057B2 (en) | 2006-11-27 | 2013-12-17 | Red Hat, Inc. | Identity management facilitating minimum disclosure of user data |
| US20080201440A1 (en) * | 2007-02-15 | 2008-08-21 | Void Communications, Inc. | Electronic Messaging Recordlessness Warning and Routing System and Method |
| US10019570B2 (en) | 2007-06-14 | 2018-07-10 | Microsoft Technology Licensing, Llc | Protection and communication abstractions for web browsers |
| US8312154B1 (en) * | 2007-06-18 | 2012-11-13 | Amazon Technologies, Inc. | Providing enhanced access to remote services |
| US9455969B1 (en) | 2007-06-18 | 2016-09-27 | Amazon Technologies, Inc. | Providing enhanced access to remote services |
| US8347358B2 (en) | 2007-06-25 | 2013-01-01 | Microsoft Corporation | Open enhanced federation security techniques |
| US8738923B2 (en) * | 2007-09-14 | 2014-05-27 | Oracle International Corporation | Framework for notifying a directory service of authentication events processed outside the directory service |
| US8490160B2 (en) * | 2007-10-04 | 2013-07-16 | Microsoft Corporation | Open federation security techniques with rate limits |
| KR101285082B1 (ko) * | 2007-12-11 | 2013-08-23 | 삼성전자주식회사 | 대리 서명을 이용한 도메인 관리 장치 및 방법 |
| US8966584B2 (en) * | 2007-12-18 | 2015-02-24 | Verizon Patent And Licensing Inc. | Dynamic authentication gateway |
| KR20100133953A (ko) * | 2007-12-21 | 2010-12-22 | 코쿤 데이터 홀딩스 리미티드 | 데이터를 안전하게 하는 시스템 및 방법 |
| US9131008B2 (en) * | 2008-09-30 | 2015-09-08 | Lenovo Enterprise Solutions (Singapore) Pte. Ltd. | Discovery profile based unified credential processing for disparate security domains |
| US8281379B2 (en) * | 2008-11-13 | 2012-10-02 | Vasco Data Security, Inc. | Method and system for providing a federated authentication service with gradual expiration of credentials |
| US8756661B2 (en) * | 2009-08-24 | 2014-06-17 | Ufp Identity, Inc. | Dynamic user authentication for access to online services |
| US8984597B2 (en) | 2010-05-27 | 2015-03-17 | Microsoft Technology Licensing, Llc | Protecting user credentials using an intermediary component |
| US8990900B2 (en) * | 2010-06-23 | 2015-03-24 | Hewlett-Packard Development Company, L.P. | Authorization control |
| US8516138B2 (en) | 2010-08-31 | 2013-08-20 | International Business Machines Corporation | Multiple authentication support in a shared environment |
| US20120185920A1 (en) | 2011-01-13 | 2012-07-19 | International Business Machines Corporation | Serialized authentication and authorization services |
| US8938791B2 (en) * | 2011-06-10 | 2015-01-20 | International Business Machines Corporation | System and method to control display of a realm name |
| US9191394B2 (en) * | 2012-02-08 | 2015-11-17 | Microsoft Technology Licensing, Llc | Protecting user credentials from a computing device |
| JP6066586B2 (ja) * | 2012-05-22 | 2017-01-25 | キヤノン株式会社 | 情報処理システム、その制御方法、およびそのプログラム。 |
| US8893230B2 (en) | 2013-02-22 | 2014-11-18 | Duo Security, Inc. | System and method for proxying federated authentication protocols |
| NL1040084C2 (en) * | 2013-03-08 | 2014-09-10 | Authasas B V | Emulation of federative authentication. |
| US9654473B2 (en) | 2013-06-28 | 2017-05-16 | Bmc Software, Inc. | Authentication proxy agent |
| US10320770B2 (en) | 2014-01-31 | 2019-06-11 | British Telecommunications Public Limited Company | Access control system |
| US9442751B2 (en) | 2014-03-24 | 2016-09-13 | International Business Machines Corporation | Virtual credential adapter for use with virtual machines |
| US20150304289A1 (en) * | 2014-04-22 | 2015-10-22 | Electronics And Telecommunications Research Institute | Notarization agent and method for collecting digital evidence using notarization agent |
| EP3297242B1 (en) * | 2016-09-20 | 2018-09-05 | Deutsche Telekom AG | A system and a method for providing a user with an access to different services of service providers |
| US10135810B2 (en) | 2016-11-17 | 2018-11-20 | Adp, Llc | Selective authentication system |
| US9992029B1 (en) | 2017-04-05 | 2018-06-05 | Stripe, Inc. | Systems and methods for providing authentication to a plurality of devices |
| US11539684B2 (en) * | 2020-03-16 | 2022-12-27 | Microsoft Technology Licensing, Llc | Dynamic authentication scheme selection in computing systems |
| US11544373B2 (en) * | 2020-12-18 | 2023-01-03 | Huawei Technologies Co., Ltd. | Method and system for application security |
| US20230336530A1 (en) * | 2022-04-19 | 2023-10-19 | Microsoft Technology Licensing, Llc | Framework For Configurable Per-Service Security Settings In A Forward Proxy |
Family Cites Families (36)
| 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 |
| US5764890A (en) * | 1994-12-13 | 1998-06-09 | Microsoft Corporation | Method and system for adding a secure network server to an existing computer network |
| US6085223A (en) * | 1995-10-20 | 2000-07-04 | Ncr Corporation | Method and apparatus for providing database information to non-requesting clients |
| US5764887A (en) * | 1995-12-11 | 1998-06-09 | International Business Machines Corporation | System and method for supporting distributed computing mechanisms in a local area network server environment |
| US6104716A (en) * | 1997-03-28 | 2000-08-15 | International Business Machines Corporation | Method and apparatus for lightweight secure communication tunneling over the internet |
| US6134658A (en) | 1997-06-09 | 2000-10-17 | Microsoft Corporation | Multi-server location-independent authentication certificate management system |
| US6092199A (en) | 1997-07-07 | 2000-07-18 | International Business Machines Corporation | Dynamic creation of a user account in a client following authentication from a non-native server domain |
| US6574661B1 (en) * | 1997-09-26 | 2003-06-03 | Mci Communications Corporation | Integrated proxy interface for web based telecommunication toll-free network management using a network manager for downloading a call routing tree to client |
| US6067623A (en) * | 1997-11-21 | 2000-05-23 | International Business Machines Corp. | System and method for secure web server gateway access using credential transform |
| US6895510B1 (en) * | 1997-11-24 | 2005-05-17 | International Business Machines Corporation | Mutual internet authentication between a client and server utilizing a dummy IOP request |
| US6112228A (en) * | 1998-02-13 | 2000-08-29 | Novell, Inc. | Client inherited functionally derived from a proxy topology where each proxy is independently configured |
| US6219790B1 (en) | 1998-06-19 | 2001-04-17 | Lucent Technologies Inc. | Centralized authentication, authorization and accounting server with support for multiple transport protocols and multiple client types |
| US6606663B1 (en) * | 1998-09-29 | 2003-08-12 | Openwave Systems Inc. | Method and apparatus for caching credentials in proxy servers for wireless user agents |
| US6298383B1 (en) * | 1999-01-04 | 2001-10-02 | Cisco Technology, Inc. | Integration of authentication authorization and accounting service and proxy service |
| US6898577B1 (en) * | 1999-03-18 | 2005-05-24 | Oracle International Corporation | Methods and systems for single sign-on authentication in a multi-vendor e-commerce environment and directory-authenticated bank drafts |
| US6668327B1 (en) * | 1999-06-14 | 2003-12-23 | Sun Microsystems, Inc. | Distributed authentication mechanisms for handling diverse authentication systems in an enterprise computer system |
| US6463474B1 (en) * | 1999-07-02 | 2002-10-08 | Cisco Technology, Inc. | Local authentication of a client at a network device |
| US6286104B1 (en) * | 1999-08-04 | 2001-09-04 | Oracle Corporation | Authentication and authorization in a multi-tier relational database management system |
| US6892307B1 (en) * | 1999-08-05 | 2005-05-10 | Sun Microsystems, Inc. | Single sign-on framework with trust-level mapping to authentication requirements |
| US6609198B1 (en) * | 1999-08-05 | 2003-08-19 | Sun Microsystems, Inc. | Log-on service providing credential level change without loss of session continuity |
| US6735310B1 (en) * | 1999-09-17 | 2004-05-11 | International Business Machines Corporation | Technique of password encryption and decryption for user authentication in a federated content management system |
| US6466933B1 (en) * | 1999-09-21 | 2002-10-15 | International Business Machines Corporation | Delayed delivery of query results or other data from a federated server to a federated client until such information is needed |
| US6792416B2 (en) * | 1999-09-21 | 2004-09-14 | International Business Machines Corporation | Managing results of federated searches across heterogeneous datastores with a federated result set cursor object |
| US6728884B1 (en) * | 1999-10-01 | 2004-04-27 | Entrust, Inc. | Integrating heterogeneous authentication and authorization mechanisms into an application access control system |
| US6826696B1 (en) * | 1999-10-12 | 2004-11-30 | Webmd, Inc. | System and method for enabling single sign-on for networked applications |
| US6510464B1 (en) * | 1999-12-14 | 2003-01-21 | Verizon Corporate Services Group Inc. | Secure gateway having routing feature |
| US6324648B1 (en) | 1999-12-14 | 2001-11-27 | Gte Service Corporation | Secure gateway having user identification and password authentication |
| US7113994B1 (en) * | 2000-01-24 | 2006-09-26 | Microsoft Corporation | System and method of proxy authentication in a secured network |
| US6918041B1 (en) * | 2000-02-23 | 2005-07-12 | Microsoft Corporation | System and method of network communication with client-forced authentication |
| US7451312B2 (en) * | 2000-03-07 | 2008-11-11 | General Instrument Corporation | Authenticated dynamic address assignment |
| US7016875B1 (en) * | 2000-08-04 | 2006-03-21 | Enfotrust Networks, Inc. | Single sign-on for access to a central data repository |
| US20020120474A1 (en) * | 2000-11-06 | 2002-08-29 | Hele John C.R. | Automated insurance policy application |
| US7272833B2 (en) * | 2000-12-26 | 2007-09-18 | International Business Machines Corporation | Messaging service in a federated content management system |
| US20020124170A1 (en) * | 2001-03-02 | 2002-09-05 | Johnson William S. | Secure content system and method |
| US8185938B2 (en) * | 2001-03-29 | 2012-05-22 | International Business Machines Corporation | Method and system for network single-sign-on using a public key certificate and an associated attribute certificate |
| US6912582B2 (en) * | 2001-03-30 | 2005-06-28 | Microsoft Corporation | Service routing and web integration in a distributed multi-site user authentication system |
-
2001
- 2001-04-07 US US09/827,697 patent/US6959336B2/en not_active Expired - Lifetime
-
2002
- 2002-03-20 EP EP02725296A patent/EP1386243A4/en not_active Withdrawn
- 2002-03-20 JP JP2002580193A patent/JP2004537090A/ja active Pending
- 2002-03-20 WO PCT/US2002/008796 patent/WO2002082296A1/en active Application Filing
- 2002-03-20 CA CA002443670A patent/CA2443670A1/en not_active Abandoned
-
2005
- 2005-10-24 US US11/163,596 patent/US7194547B2/en not_active Expired - Lifetime
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007148974A (ja) * | 2005-11-30 | 2007-06-14 | Fuji Xerox Co Ltd | 認証エージェント装置および認証方法 |
| JP2010531516A (ja) * | 2007-06-25 | 2010-09-24 | マイクロソフト コーポレーション | 安全でないネットワークを介する装置のプロビジョニング及びドメイン加入エミュレーション |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1386243A4 (en) | 2007-12-05 |
| EP1386243A1 (en) | 2004-02-04 |
| US6959336B2 (en) | 2005-10-25 |
| US7194547B2 (en) | 2007-03-20 |
| US20030046391A1 (en) | 2003-03-06 |
| WO2002082296A1 (en) | 2002-10-17 |
| CA2443670A1 (en) | 2002-10-17 |
| US20060075473A1 (en) | 2006-04-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004537090A (ja) | 連合認証サービス | |
| US10333941B2 (en) | Secure identity federation for non-federated systems | |
| US7698375B2 (en) | Method and system for pluggability of federation protocol runtimes for federated user lifecycle management | |
| JP4832822B2 (ja) | データ処理システム、方法およびコンピュータ・プログラム（連合ユーザ・ライフサイクル管理用の信頼インフラストラクチャ・サポートを可能にする方法およびシステム） | |
| US7562382B2 (en) | Specializing support for a federation relationship | |
| US8607322B2 (en) | Method and system for federated provisioning | |
| JP4579546B2 (ja) | 単一サインオンサービスにおけるユーザ識別子の取り扱い方法及び装置 | |
| US7631346B2 (en) | Method and system for a runtime user account creation operation within a single-sign-on process in a federated computing environment | |
| US20060048216A1 (en) | Method and system for enabling federated user lifecycle management | |
| US20060021017A1 (en) | Method and system for establishing federation relationships through imported configuration files | |
| Kivinen | OpenID Connect Provider Certification | |
| AU2002255871A1 (en) | Federated authentication service | |
| Boettcher et al. | Unleash the power of single sign-on with Microsoft and SAP | |
| Lu | User-to-user delegation in a federated identity environment' | |
| SECTOR | TD 2609 Rev. 2 TELECOMMUNICATION |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050223 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050223 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080603 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20080829 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20080905 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20090317 |