JP5889988B2 - Httpベースの認証 - Google Patents

Httpベースの認証 Download PDF

Info

Publication number
JP5889988B2
JP5889988B2 JP2014206285A JP2014206285A JP5889988B2 JP 5889988 B2 JP5889988 B2 JP 5889988B2 JP 2014206285 A JP2014206285 A JP 2014206285A JP 2014206285 A JP2014206285 A JP 2014206285A JP 5889988 B2 JP5889988 B2 JP 5889988B2
Authority
JP
Japan
Prior art keywords
http
security token
message
header
token
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.)
Active
Application number
JP2014206285A
Other languages
English (en)
Other versions
JP2015026391A (ja
Inventor
ケー.ナンダ アルン
ケー.ナンダ アルン
ウィルソン ハーヴェイ
ウィルソン ハーヴェイ
Original Assignee
マイクロソフト コーポレーション
マイクロソフト コーポレーション
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority to US12/465,725 priority Critical patent/US8078870B2/en
Priority to US12/465,725 priority
Application filed by マイクロソフト コーポレーション, マイクロソフト コーポレーション filed Critical マイクロソフト コーポレーション
Publication of JP2015026391A publication Critical patent/JP2015026391A/ja
Application granted granted Critical
Publication of JP5889988B2 publication Critical patent/JP5889988B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/168Implementing security features at a particular protocol layer above the transport layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0807Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network using tickets, e.g. Kerberos

Description

本発明は、一般にネットワーク技術に関し、さらに具体的には、ネットワーク環境内の要求の認証のためのHTTPの使用に関する。

コンピュータネットワークは、様々なセキュリティ欠陥にさらされている。このような欠陥のタイプの1つは、アクセスが許可されていないリソースにアクセスするためか、または要求に正しく関連付けられることを避けるために、ユーザまたはコンピュータシステムが自身を偽って特定する際に発生する。要求認証を容易にするために、リソースまたはサービスを提供する団体(以下本明細書において「証明書利用者(relying party)」と称する)へのサービスに関する要求は、証明書利用者が身元の真偽を検証可能な態様における要求者の身元を含んでいる。要求認証は、要求の送信者の身元を検証する処理である。認証は、団体のID(identification)の各々が正確であるという、あるレベルのセキュリティをもたらす。要求者の身元は、証明書利用者によって行なわれるアクセス制御判定の基礎を形成する。

要求認証のタイプの1つは、ユーザ名およびパスワードの使用を含む。さらに強力なタイプの認証は、セキュリティトークンの使用を含む。あるタイプのセキュリティトークンは、信頼済みIDプロバイダ(identity provider)によって発行される。セキュリティトークンの所持は、所有団体に関する身元の証明を提供するのに役立つ。あるセキュリティトークンは、さらに強力なセキュリティのために埋め込まれた暗号化キーを有している。

やりとり(interaction)の1つのタイプにおいて、要求者は、IDプロバイダからセキュリティトークンを取得する。要求者は、その後、サービス要求を伴ったセキュリティトークンを、リソースまたはサービスを提供する団体に提示する。リソースプロバイダは、IDプロバイダとの信頼関係を有し、この信頼関係は、セキュリティトークンの信頼性を保証する役割を果たす。

REST(representation state transfer)は、ワールドワイドウェブ等の分散システムのソフトウェアアーキテクチャの様式である。RESTは、通常は、ドメイン特有のデータを、SOAP等の追加のメッセージ層無しにHTTPを介して伝送するインタフェースをいう。HTTPは、“RESTに適合した(RESTful)”アーキテクチャに従った、GET、POST、UPDATEおよびDELETE等のメソッドを含むインタフェースを提供する。RESTアーキテクチャの1つの態様は、ステートレスサーバ(stateless server)のサポートであり、当該態様において、各メッセージは、当該メッセージを理解するために必要な情報を含み、メッセージ間の通信状態を記憶する必要性からサーバを解放する。このことは、サーバファーム内等のサーバのスケーリング(scaling)を容易にする。

RFC2617(http://www.ietf.org/rfc/rfc2617.txtにて取得可能)は、BASIC認証スキームを記載しており、当該スキームにおいて、ユーザ名およびパスワードを、HTTPヘッダ領域内に送ることができる。このRFCは、このスキームを「ユーザ名およびパスワードを非暗号化形式でネットワークを介して送るので、ユーザ認証の安全な方法としては考えられない」として記載している。RFCは「デジタルアクセス認証」スキームも記載しており、当該スキームにおいて、ユーザ名、パスワード、ノンス値(nonce value)、HTTPメソッド、および要求されたURIのハッシュを使用する。RFCは、ダイジェストスキーム(digest scheme)が“...多くの既知の制限をうける”と記載している。

本概要を、発明を実施するための形態において以下にさらに詳細に説明される概念の選択を単純化された形式にて紹介するために提供する。本概要は、本発明の重要な特徴または本質的な特徴を特定することを意図しておらず、本発明の範囲を限定するために使用することも意図していない。

つまり、システム、メソッドおよびコンポーネントは、アプリケーションにHTTP要求を認証することを可能にするHTTPメッセージ認証フレームワークを提供するために機能する。このフレームワークは、様々な要求認証スキームを実装するための機構を有するアプリケーションを提供し、HTTPスタックの実装を活用する。例示の実施形態は、HTTPヘッダおよび関連するセマンティクスのセットを有するプロトコルを含む。HTTPメッセージを生成して処理する方法を、要求者と証明書利用者との間の様々なやりとりとともに説明する。

例示の実施形態において、要求者は、サーバから、認証仕様を有する1または複数のHTTPヘッダを含むサーバメッセージを受信する。それに応じて、要求者は、認証仕様に適合する要求メッセージを生成することができる。一実施形態において、要求メッセージは、メッセージ本文、セキュリティトークン(ST)、セキュリティトークンの配置を特定するHTTPヘッダを含む。要求メッセージは、メッセージの要約を含むHTTPヘッダを含むことができる。セキュリティトークンを、1または複数のHTTPヘッダ内またはメッセージ本文内に配置することできる。セキュリティトークンを複数のHTTPヘッダ内に配置する場合、セキュリティトークンをヘッダに亘って断片化することができる。セキュリティトークンをメッセージ本文内に配置する場合、セキュリティトークンは、本文全体であるか、HTMLフォームフィールドであるか、またはXML要素内に在ることができる。一実施形態において、要約は、メッセージ本文および少なくとも1つのHTTPヘッダまたはそれらの一部の暗号化表現を含む。

一実施形態において、要求者は、セキュリティトークンのサイズに基づいてセキュリティトークンの配置を判定する。1つのHTTPヘッダ内に収めるには長すぎる場合、セキュリティトークンを、複数のヘッダに亘って断片化することができる。複数のHTTPヘッダ内に収めるのに長すぎる場合、セキュリティトークンをメッセージ本文内に配置することができる。

一実施形態において、要求メッセージを受信するサーバは、セキュリティトークンを、トークン配置ヘッダ仕様に基づいて抽出することができる。セキュリティトークンは、1つのHTTPヘッダ内にあるか、複数のHTTPヘッダに亘って断片化されているか、またはメッセージ本文内に在ることができる。

一実施形態において、サーバは、要求者に署名仕様を送信し、および要求者は、セキュリティヘッダ内の署名仕様に適合するデジタル署名を含む。
一実施形態において、サーバは、コンテキストトークン(context token)を含むメッセージを用いて要求者に応答する。それに続く要求において、要求者は、セキュリティトークンを含む代わりにHTTPヘッダ内にコンテキストトークンを含むことができる。

上述および関連する目的の達成のために、システムのある例示の態様を、以下の説明および添付の図面とともに本明細書において説明する。しかし、これらの態様は、本発明の原理を使用することができる様々な方法のいくつかを示すものであり、本発明は、これら全ての態様およびそれらと均等なものを含むことを意図している。本発明の他の利点および新規な特徴は、図面と共に考慮される本発明の以下の詳細な説明から明らかになるだろう。

本発明の非限定的および非包括的な実施形態を、添付の図面を参照して説明する。図面において、同様の番号は、別途に特定されない限り、様々な図面を通じて同様の部分を参照する。

本発明の理解を助けるために、添付の図面とともに読まれるべき以下の発明を実施するための形態を参照する。

図1は、実施形態を実施することができる例示の環境のブロック図である。 図2は、証明書利用者を実装するために使用可能なコンピュータシステムの例示の実施形態を示すブロック図である。 図3は、実施形態を実施することができる例示の環境を示す図である。 図4は、要求者を認証するためにHTTPヘッダを使用する処理の例示の実施形態を示すフロー図である。 図5は、図4の動作のいくつかをさらに詳細に示すフロー図である。 図6は、例示の実施形態に従って、HTTPメッセージ内にセキュリティトークンを挿入する処理を示すフロー図である。 図7は、例示の実施形態に従って、HTTPメッセージからセキュリティトークンを抽出する処理を示すフロー図である。 図8は、例示の実施形態におけるHTTPメッセージを生成する処理を示すフロー図である。

本発明の例示の実施形態を、本明細書の一部を形成しかつ本発明を実施することができる特定の例示の実施形態を例示の目的で示す添付の図面を参照して、本明細書で以下にさらに十分に説明する。しかし、本発明を、多くの異なった形態にて実施することができ、本明細書にて説明されている実施形態に限定されるとして解釈するべきではない。むしろ、これらの実施形態を、本開示が完全かつ完璧となるように、ならびに本発明の範囲を当業者に十分に伝達するように提供する。様々ある中で、本発明を、方法またはデバイスとして実施することができる。従って、本発明を、完全なハードウェア実施形態、完全なソフトウェア実施形態またはソフトウェアおよびハードウェアの態様を組み合わせた実施形態の形式で実施することができる。従って、以下の詳細な説明を、限定するものとして理解すべきではない。

明細書および特許請求の範囲の請求項を通して、以下の用語は、文脈が明らかに他のことを記述していない限り、本明細書において明示的に関連付けられている意味を持つ。本明細書において用いられている「一実施形態において」という表現は、必ずしもそれまでの実施形態をいうわけではない。さらに、本明細書において用いられている「他の実施形態において」という表現は、必ずしも異なった実施形態をいうわけではない。従って、本発明の様々な実施形態を、本発明の範囲または趣旨から逸脱することなく容易に組み合わせることができる。同様に、本明細書において用いられている「1つの実装例において」という表現は、必ずしも同一の実装例を言うわけではないので、様々な実装例の技術を組み合わせることができる。

さらに、本明細書で用いられている用語「または」は、文脈が明らかに他のことを記述していない限り、包含的な「または」演算子であり、用語「および/または」と同等である。用語「に基づいて」は、排他的ではなく、文脈が明らかに他のことを記述していない限り、追加の要素に基づいていることを許容する。さらに、本明細書を通して、不定冠詞および定冠詞は複数のものを指すことができる。「内に」という語は、「内に」および「上に」の意味を含む。

本明細書で使用されている用語「認証する」は、許容可能な確度まで、事実または要求が真であることを確認することをいう。ユーザまたはユーザの身元を認証することを、ユーザの表明されている身元が、十分かつ正確であることを確認するために用いる。ユーザからの要求の認証は、要求に含まれる身元情報が正確であること、要求が特定されたユーザからのものであるかもしくは特定されたユーザによって許可されていること、要求が不適切に変更されていないこと、または要求内の他の情報が正確であることの確認を含むことができる。認証は付随する確度を有しており、まだ不正確であるだろう場合でも、情報が認証されている状態を許容する。

本明細書で説明されているコンポーネントを、様々なデータ構造を有する様々なコンピュータ可読媒体から実行することができる。これらの構成要素は、1または複数のデータパケット(例えば、信号によって、ローカルシステム内もしくは分散システム内の他のコンポーネントとやりとりするか、またはインターネット等のネットワークを介して他のシステムとやりとりをする1つのコンポーネントからのデータ)を有する信号に従うようなローカルまたはリモート処理を介して通信することができる。ソフトウェアコンポーネントを、本発明の実施形態によって、例えば、限定するわけではないが、特定用途向け集積回路(ASIC)、CD(compact disk)、DVD(digital versatile disk)RAM(random access memory)、ROM(read only memory)、フロッピー(登録商標)ディスク、ハードディスク、EEPROM(electrically erasable programmable read only memory)、フラッシュメモリ、またはメモリスティックを含むコンピュータ可読記憶媒体に保存することができる。

本明細書において用いられるコンピュータ可読媒体という用語は、記憶媒体および通信媒体を含む。通信媒体は、通常は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを搬送波または他の搬送メカニズム等の変調データ信号において表し、かつ任意の情報伝送媒体を含む。例示であり、限定するものではないが、通信媒体は、有線ネットワークおよび直接有線接続等の有線媒体、並びに音波、ラジオ、赤外線および他の無線媒体を含む。

図1は、実施形態を実施することができる環境100のブロック図である。図1は、例示の環境の基本的な理解を提供するが、多くの構成を使用することができ、および多くの詳細は図1内に記載されていない。図1に示されているように、例示の環境100は要求者102を含む。要求者102は、リモートサービスプロバイダからのリソースまたはサービスを要求するクライアントコンピュータデバイス、処理、または任意のコンポーネントとすることができる。例示の実施形態において、要求者102は、HTTPスタック104を含む。HTTPスタックは、HTTP規格および本明細書に記載されているメカニズムの少なくとも少なくともいくつかに従って、HTTP(hypertext protocol)メッセージを受信するか、処理するか、生成するかまたは送信することができる。

例示の環境100は、証明書利用者106を含む。証明書利用者106は、コンピュータデバイス、サーバ、または複数のサーバを含むサーバファームとすることができる。図2は、証明書利用者106の実装例を示している。

図示された例示の実施形態において、証明書利用者はHTTPスタック108を含む。HTTPスタック108は、HTTPスタック104に説明されたような動作を実行するが、HTTPスタック108およびHTTPスタック104の実装は異なってもよく、各々によって提供される機能が異なってもよい。

一実施形態において、要求者102は、証明書利用者106に1または複数の要求を送信する。要求は、いくつかのタイプの識別情報を含むことができる。要求は、リソースまたはサービスに対する要求とすることができる。本明細書で用いられているように、サービスに対する要求は、リソースに対する要求であるとみなされる。証明書利用者106は、要求を処理して、および要求が、当該要求または要求者102のユーザを十分に認証するための情報を含んでいるかを判定する。この情報は、特有の形式であってもよく、セキュリティ認証情報と称される。セキュリティ認証情報が含まれていないかまたは不十分である場合、証明書利用者106は、要求を拒否し、および十分なセキュリティ認証情報を提供するように要求者102に命令することができる。この処理を、本明細書でさらに詳細に説明する。

例示の環境100は、IDプロバイダ110を含む。IDプロバイダは、要求者102にセキュリティ認証情報を発行するネットワークエンティティとすることができる。セキュリティ認証情報は、証明書利用者106によって信頼可能な要求者102に関する要求を表すことができる。従って、IDプロバイダ110は、証明書利用者106によって、信頼済みの団体とみなされる。一実施形態において、セキュリティ認証情報は、セキュリティトークン(ST)を含み、およびIDプロバイダ110は、セキュリティトークンを提供するセキュリティトークンサービス(STS)を含む。

1つのタイプのセキュリティトークンは、エンティティに関する1または複数の要求の一群を表すデータを含む。この要求を、要求者に関連する情報が正確であるアサーションとしてみなすことができる。これは、例えば、名前、識別子、キー、グループメンバシップ、特権、能力等を含むことができる。このタイプのセキュリティトークンは、本明細書において「ダイレクトセキュリティトークン」と称される。

第2のタイプのセキュリティトークンは、ダイレクトセキュリティトークンへの参照を含み、この参照はダイレクトセキュリティトークンへのアクセスを特定するかまたは可能にする。ダイレクトセキュリティトークンへのこのタイプの参照は、本明細書において非ダイレクトセキュリティトークンと称される。URI(uniform resource identifier)は、それがダイレクトセキュリティトークンを参照する場合、非ダイレクトセキュリティトークンの例である。本明細書で用いられているように、用語「セキュリティトークン」は、文脈が1つの特定のタイプを明確に指していない限り、ダイレクトセキュリティトークンまたは非ダイレクトセキュリティトークンをいう。

要求者102は、ネットワーク120を介して、証明書利用者106またはIDプロバイダ110と通信することができる。ネットワーク120は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはこれらの組み合わせを含む。一実施形態にておいて、ネットワーク120は、ネットワークのネットワークであるインターネットを含む。ネットワーク120は、有線通信メカニズム、無線通信メカニズム、またはこれらの組み合わせを含む、要求者102、証明書利用者106、またはIDプロバイダ110間の通信、これらの互いのまたは他のコンピューティングデバイスとの通信は、IP、TCP/IP、UDP、HTTP、SSL、TLS、FTP、SMTP、WAP、BlueTooth(登録商標)、またはWLAN等の1または複数の様々な有線または無線通信プロトコルを使用することができる。

図1は、適切な環境の単なる一実施例であり、および本発明の用途または機能の範囲に関する限定を提案するものではない。従って、様々なシステム構成を、本発明の範囲または趣旨から逸脱することなく用いることができる。例えば、証明書利用者106またはIDプロバイダ110の任意の機能を、様々な方法で複数のコンピュータデバイスの間に分散されているかまたは複製されている1または複数のコンピュータデバイス内で組み合わせることができる。同様に、要求者102の機能は、1または複数のコンピュータデバイス間で様々な方法で構成することができる。一実施形態において、証明書利用者106およびIDプロバイダ110の機能を、1または複数のコンピュータデバイス内に組み込むことができる。

一実施形態において、要求者102、証明書利用者106、およびIDプロバイダ110の各々を、1または複数のコンピュータデバイスによって実装する。コンピュータデバイスは、専用または汎用コンピュータデバイスとすることができる。簡単にいえば、使用可能なコンピュータデバイスの一実施形態は、1または複数の処理ユニット、メモリ、ディスプレイ、キーボードおよびポインティングデバイス、並びに通信インタフェースを含む。1または複数の処理ユニットは、1または複数のマルチコアプロセッサを含むことができる。例示のコンピュータデバイスは、メインフレーム、サーバ、ブレードサーバ、パーソナルコンピュータ、ポータブルコンピュータ、通信デバイス、家電等を含む。コンピュータデバイスは、汎用または専用オペレーティングシステムを含むことができる。ワシントン州レドモンドのマイクロソフト社によるオペレーションシステムのWindows(登録商標)ファミリーは、開発システムのコンピュータデバイスにおいて実行することができるオペレーティングシステムの例である。

図2は、証明書利用者106を実装するために使用可能なコンピュータシステム200の例示の実施形態またはこれらの一部を示すブロック図である。様々な実施形態において、システム200を、様々な方法で構成されている1または複数のサーバまたは他のコンピュータデバイスを用いて実装することができる。

図示されているように、コンピュータシステム200は、様々なコンピュータプログラムの命令を実行するために動作を実行する1または複数のプロセッサ202を含む。1つの構成において、プロセッサ202は、1または複数の中央演算ユニット、1または複数のプロセッサコア、ASIC、または他のハードウェア処理コンポーネント並びに関連するプログラムロジックを含むことができる。例示の実施形態において、コンピュータシステム200は、揮発性または不揮発性メモリを含むことができるメモリ204を含むことができる。コンピュータシステム200は、ネットワークを介してメッセージもしくは信号を離れたデバイスに送信するか、または当該デバイスから受信するように動作を実行するネットワーク通信ユニットを含むこともできる。

例示の実施形態において、コンピュータシステム200は、メモリ内に保存されているHTTPスタック206および1または複数のアプリケーション210を含む。HTTPスタック206は、HTTPスタック108(図1)とすることができる。一実施形態において、HTTPスタック206は、受信された要求を認証するように動作を実行する認証モジュール208を含む。ある実施形態において、HTTPスタック206は、認証モジュール208を含まない。

一実施形態において、コンピュータシステム200は、アプリケーション210を含む。アプリケーション210は、様々なサービスを実行するか、1または複数のリソースへのアクセスを提供するか、または要求に応じて他の動作を実行することができる。アプリケーション210の例は、ウェブサーバ、FTPサーバ、およびメールサーバを含む。アプリケーション210は、アプリケーション認証モジュール212を含むことができる。アプリケーション認証モジュール212は、受信された要求を認証するための動作を実行するが、認証モジュール208と同一の動作である必要はない。

図3は、実施形態を実施することができる例示の環境300を示す。環境300は、図1の環境100またはこれらの変形例とともに存在することができる。図示されているように、環境300は、要求者102、証明書利用者106、およびIDプロバイダ110を含む。要求者102は、証明書利用者106およびIDプロバイダ110の各々と直接的にまたは非直接的に通信する。この通信は、直接的、またはネットワーク120(図1)等のネットワークを介することができる。

図3内の矢印は、図示されたコンポーネント間で交換されるメッセージを表している。さらに、一実施形態において、メッセージの参照符号は、様々な実施形態において順序が異なるが、図面の頂部から底部方向の時系列に対応している。一実施形態において、図示されているメッセージの各々は、HTTPメッセージであり、HTTPメッセージの内容を以下でさらに詳細に説明する。

図3のメッセージを、図4とともに説明する。図4は、要求者を認証するためのHTTPヘッダの使用の処理400の例示の実施形態を示しているフロー図である。処理400のいくつかの動作は、要求者102(図1)によって実行され、かつ図4の左側欄のヘッダ「要求者」の下に表されている。処理400の他の動作は、証明書利用者106によって実行され、かつ図4の右側欄のヘッダ「証明書利用者」の下に表されている。処理400のいくつかの動作は、図3に示されているメッセージの送信または受信に関連している。以下の説明は、図3のメッセージを参照する。

処理400の図示されている部分を、ブロック402で開始することができ、ここで、要求者102は、要求メッセージを証明書利用者106に送信する(要求メッセージ310)。一実施形態において、要求メッセージ310は、アクセスを認証処理によって保護するリソースに対する要求である。この処理は、ブロック402から404に流れることができ、そこで、証明書利用者106は要求メッセージ310を受信する。処理400は、ブロック404から判定ブロック406に流れることができ、そこで、要求が十分に認証されたかについて判定がなされる。一実施形態において、これは、要求が有効かつ十分なセキュリティ認証情報を含んでいるかの判定を含む。十分性の判定は、証明書利用者106の構成に基づくことができる。一実施形態において、ブロック406の判定は、要求がセキュリティトークンを含むこと、および設定されたスキームを守って実行しているかの判定を含む。この判定は、要求されたリソースの値、要求者の位置もしくは設定、時刻、または他の要素に基づくことができる。ブロック406の動作のさらなる詳細を、本明細書で説明する。

判定ブロック406において、要求が十分に認証されていると判定した場合、処理はブロック408に流れることができ、そこで、証明書利用者106が応答メッセージ320を要求者102に送信することができる。ある構成において、応答メッセージ320は、良好な応答(successful response)を示すことができる。応答は、リソース、リソースが利用可能であることの表示、サービスを提供しているかまたは提供することの表示、リソースの取得を容易にするデータ、または要求に従った他の応答を含むことができる。ある構成において、応答メッセージ320は、認証以外の理由で拒否された要求を示すことができる。例えば、要求を適切に認証したが、ユーザがリソースにアクセスすることを許可されていない場合がある。リソースは、他の理由で利用不可能とすることができる。処理は、ブロック408からプログラムの終了に流れるか、またはプログラムの呼び出しに戻ることができる。

判定ブロック406において、要求メッセージに含まれている十分なセキュリティ認証情報がないと判定した場合、処理400は、ブロック410に流れることができ、そこでHTTPエラー応答メッセージを生成し、かつ証明書利用者106から要求者102に送信する。一実施形態において、HTTPエラー応答メッセージは、HTTP「不許可」メッセージ312である。これは、「WWW-Authenticate」応答ヘッダを含む、HTTP401エラーメッセージとすることができる。このメッセージは、要求されたセキュリティ認証情報の仕様、または1もしくは複数のセキュリティ認証情報を送信する際に順守されるべきプロトコルを示すデータを含むことができる。このプロトコルは「スキーム」と称され、かつ1または複数のHTTPヘッダを使用するスキームの具体的な事例においては「HTTPスキーム」と称される。

処理400は、ブロック410からブロック412に流れることができ、そこで、要求者102は「不許可」メッセージ312を受信する。ある環境において、要求者102は、十分なセキュリティ認証情報を保持するか、またはそれらを生成可能とすることができるが、例示した環境においては、「不許可」メッセージ312の受信に応答して、処理がブロック414に流れ、そこで、要求者102は、「不許可」メッセージ312にて証明書利用者106によって特定されたスキームに準ずる十分なセキュリティ認証情報を取得することを試行することができる。一実施形態では、ブロック414において、要求者102が、IDプロバイダ110等の信頼済みIDプロバイダからのセキュリティトークンを要求することができる。この要求は、IDプロバイダ110に送信される要求STメッセージ314の形式とすることができる。要求STメッセージ314は、要求者102のユーザを認証するために使用可能なセキュリティ認証情報または他のデータを含むことができる。

ある実施形態において、要求STメッセージ314に応答して、IDプロバイダ110が、要求者102が十分な識別情報を提供していないこと、またはそうでなければセキュリティトークンを受信することを許可されていないことを判定する。この動作を、図4には記載しない。例示の処理400は、IDプロバイダ110が、要求されたセキュリティトークンを要求者102に返信する環境を示している。示されているように、処理400は、ブロック416に流れ、そこで要求者102がセキュリティトークン325を含むST応答メッセージ316を受信する。ある実施形態において、セキュリティトークンは、1または複数の暗号化キーを含む。キーベアリング(key-bearing)セキュリティトークンの例は、セッションキーを用いたケロベロスv5チケット、およびホルダー−オブ−キー(holder-of-key)サブジェクト確認を用いたSAMLv1.1もしくはv2.0トークンを含む。

一実施形態において、要求STメッセージ314およびST応答メッセージ316は、本明細書において説明されているメッセージプロトコルの少なくともいくつかに従っている。例えば、要求者は、ST要求メッセージ314内に、本明細書において説明されているトークン配置ヘッダおよびトークンヘッダを挿入することができる。このメッセージは、さらに、要約ヘッダおよびデジタル署名を含むことができる。これらのメッセージの例を、本明細書において提供する。

ブロック416におけるセキュリティトークンの受信に応答して、処理はブロック418に流れることができ、そこで、要求者102は要求メッセージ318を生成し、かつ証明書利用者106に送信することができる。要求メッセージ318は、要求メッセージ310の要求と同様の要求を含むことができる。しかし、要求メッセージ318は、IDプロバイダ110から受信されたセキュリティトークン325を含むことができる。一実施形態において、要求メッセージ318は、追加のHTTPヘッダを有しかつ認証データを提供する要求メッセージ310と同様である。処理は、ブロック418からブロック404に流れることができ、そこで、証明書利用者106は要求メッセージ318を受信する。

ブロック404において、要求メッセージ318の受信に応答して、証明書利用者106は、当該メッセージを処理して、当該要求が十分な識別認証情報を含みかつ要求メッセージ310に関して説明されたような設定された認証スキームに従っているかを判定することができる。識別認証情報が不十分であるとみなされる場合、処理400は、ブロック410に流れることができ、そこで証明書利用者は他の不許可メッセージ312を送信することができる。判定ブロック406において、セキュリティ認証情報が十分であると判定された場合、処理はブロック408に流れることができ、上述のように、そこで応答を送信する。図3は、メッセージの例示のシーケンスを示しており、この場合第1の要求メッセージは不十分であり、第2の要求メッセージは十分である。このメッセージの例示のシーケンスは、以下のメッセージのシーケンスを示している。
要求メッセージ310。
不許可メッセージ312。
要求STメッセージ314。
ST応答メッセージ316。
(セキュリティトークンを伴う)要求メッセージ318。
応答メッセージ320。

一実施形態において、環境は以下のメッセージのシーケンスをもたらすることができる。
要求STメッセージ314。
ST応答メッセージ316。
(セキュリティトークンを伴う)要求メッセージ318。
応答メッセージ320。

上述の例示のシーケンスにおいて、要求者102は、ブロック414において、要求STメッセージ314を送信することができ;ブロック416において、要求者102は、セキュリティST応答メッセージ316を受信することができ;それに応じて、ブロック418において、要求者102は、要求メッセージ318を生成し、かつ送信することができる。証明書利用者106は、その後、ブロック408において応答メッセージ320を送信することができる。例えば、要求者102が、事前の要求に応答して事前に受信した不許可メッセージ312を有している環境か、またはそうでなければ、要求者102が、適切なセキュリティトークンを取得して要求メッセージ内の適切なスキームを用いてそれを送信する環境において、このシーケンスは生じる場合がある。さらに他のシーケンスにおける例示されたメッセージまたはそれら一部の送信を含む、処理400のバリエーションが生じる場合がある。

図5は、図4の判定ブロック406の実装例を示すフロー図である。判定ブロックの動作のいくつかを、証明書利用者106(図1)のHTTPスタック206(図2)によって実行することができ、かつ図5の左側欄のヘッダ「HTTPスタック」の下に表す。判定ブロック406の他の動作を、アプリケーション210の認証モジュール212によって実行することができ、かつ右側欄のヘッダ「アプリケーション」の下に表す。図5は、前後関係に関して、破線にて図4のブロック404、410および408を含んでいるが、これらは、示されている実施形態における判定ブロック406の動作には含まれない。図5に示されている判定ブロック406の動作は、本明細書において処理500と称される。

図5に示されているように、処理は、ブロック404からブロック504に流れることができ、そこで、認証スキームの仕様を、HTTPメッセージのHTTPヘッダから抽出することができる。要求メッセージ318は、このようなHTTPメッセージの一例である。一実施形態において、この仕様は、証明書利用者106において設定された任意のスキーム名とすることができる。

処理500は、ブロック504から判定ブロック506に流れることができ、そこで、HTTPスタック206を、特定された認証スキームに対応しているハンドラ(handler)を用いて設定しているかの判定を行なう。本明細書において説明されているフレームワークは、処理500を、証明書利用者において、特定された認証スキームに対応するHTTPスタックハンドラを用いて、またはそのように構成されていないHTTPスタックを用いて実行することを可能にする。

判定ブロック506において、HTTPスタック206が対応するハンドラを用いて設定されていると判定した場合、処理はブロック508に流れることができ、そこで、セキュリティトークンを、受信されたメッセージから抽出することができる。本明細書で説明されているように、本明細書において説明されているフレームワークは、セキュリティトークンを、1または複数のHTTPヘッダ内、または要求メッセージ本文内に配置することを可能にする。ブロック506の動作は、セキュリティトークンの配置を判定するステップ、セキュリティトークンを抽出するステップ、および2以上ある場合にセキュリティトークンの断片を組み合わせるステップを含む。図7は、ブロック508の動作のいくつかをさらに詳細に示している。

この処理は、ブロック508からブロック510に流れることができ、ここでセキュリティトークンの検証を実行することができる。一実施形態において、ブロック510の動作は、セキュリティトークンを、セキュリティトークンを含んで受信された要求に適切に関連付けていることを検証するステップを含む。一実施形態において、メッセージは、要求メッセージの要約、またはその一部を含むことができる。当該メッセージは、メッセージ本文、セキュリティトークン、およびHTTPヘッダの選択された部分を含むことができる。要約は、メッセージの指定された部分のハッシュを含むことができる。ブロック510の動作は、要約がメッセージ本文およびHTTPヘッダの選択された部分を正確に表していることの検証を含むことができる。セキュリティトークンの検証は、要約の生成および当該要約がセキュリティトークンに含まれている要約と一致していることの検証を含むことができる。一実施形態において、ブロック510の動作は、少なくとも要約をカバーするデジタル署名の検証を含む。この署名は、セキュリティトークン内に埋め込まれている暗号化キーを使用することができる。このことは、セキュリティトークンとメッセージとの強い関連付けをもたらす。

セキュリティトークンの検証は、セキュリティトークンを、図1のIDプロバイダ110等の信頼済みIDプロバイダによって発行したことを検証することを含む。ブロック510の動作は、証明書利用者の構成に基づいて、セキュリティトークンによって表された要求が十分であることを検証すること、または設定されているセキュリティトークンデータの追加の検証を含むことができる。

処理は、判定ブロック512に流れることができ、そこで、セキュリティトークンおよび関連するデータを適切に検証したかを判定する。検証が失敗している場合、処理は処理400のブロック410に流れることができ、かつ本明細書に記載されているように継続する。検証が成功している場合、処理はブロック514に流れることができ、そこで、要求メッセージまたはその一部をアプリケーション210に送る。アプリケーション210は、ブロック408を含む処理400の様々な方法でメッセージを処理することができ、処理は本明細書において説明されているように継続することができる。

一実施形態において、HTTPスタックを、特定された認証スキームに従ってセキュリティトークンを抽出し、かつ確認するように構成していなくともよい。判定ブロック506において、HTTPスタックを、特定された認証スキームに対するハンドラを用いて構成していないと判定した場合、処理はブロック526に流れることができ、そこで、要求メッセージまたはその一部をアプリケーション210に送る。このことは、アプリケーション210に、受信されたメッセージの認証を実行するメカニズムを提供する。

処理は、ブロック516からブロック518に流れることができ、そこで、セキュリティトークンを、受信されたメッセージから抽出することができる。一実施形態において、アプリケーション210を、要求メッセージの認証に関連してHTTPスタック206の動作の少なくともいくつかを実行するように構成することができる。特に、ブロック518および520、並びに判定ブロック522は、本明細書に説明されているように、対応するブロック508、510および512の動作をそれぞれ含むことができる。従って、処理は、対応するブロックに関して上述されているように、ブロック518からブロック520、ブロック522に流れ、その後、ブロック410またはブロック408に流れることができる。一実施形態において、判定ブロック522において失敗した認証は、本明細書に記載されているようにHTTPエラーの注入をもたらすことができる。

本明細書に記載されているメカニズムの少なくともいくつかは、証明書利用者106が、受信された要求メッセージに関連する様々な構成を有することを可能にする。1つの構成において、HTTPスタック206の認証モジュール208を、受信された要求の認証を実行するように構成することができる。1つの構成において、認証モジュール208を、そのように構成しなくともよく、およびメッセージを、アプリケーション210に送り、そこでアプリケーションモジュール212は認証を実行する。1つの構成において、認証モジュール208は、認証動作の一部を実行することができ、および認証モジュール212は、他の部分を実行することができる。従って、アプリケーション210を、様々なコンピュータシステム200にインストールし、かつ様々なHTTPスタック構成とともに動作することができる。

図6は、例示の実施形態において、セキュリティトークンをHTTPメッセージ内に挿入する処理600を示すフロー図である。処理600は、上述のように、ブロック418の動作の少なくともいくつかを示している。処理600の示されている部分を、ブロック602において開始することができ、そこで、セキュリティトークンの1または複数の配置を判定することができる。一実装において、セキュリティトークンを、1または複数のHTTPヘッダ内にあるように構成することができ、またはメッセージ本文における3つの配置のうちの1つの配置とするように構成することができる。判定ブロック604において、処理は、配置オプションのそれぞれを取り扱うために4つのブロックのうちの1つに分岐することができる。このような配置の1つは、1または複数のHTTPヘッダ内にある配置である。これがセキュリティトークンの配置であると判定すると、処理は判定ブロック606に流れることができ、そこで、セキュリティトークンを断片化するかの判定を行なう。一実施形態において、この判定を、セキュリティトークンのサイズに基づいて行なう。判定ブロック606において、セキュリティトークンを1つのヘッダに挿入することができることを判定すると、この処理はブロック608に流れることができ、そこで、セキュリティトークンを1つのHTTPヘッダ内に挿入する。この処理は、ブロック620に流れることができる。一実施形態にて、ブロック620において、HTTPトークン配置ヘッダを、セキュリティトークンの配置の仕様とともに生成する。処理は、その後、終了ブロック622に流れて終了し、またはブロック418等の呼び出しプログラムに戻ることができる。判定ブロック606において、断片化を行なうべきと判定した場合、処理は、ブロック610に流れることができ、そこで、セキュリティトークンの断片化を実行し、複数のHTTPトークンヘッダを生成し、セキュリティトークンの断片を、各ヘッダに挿入する。処理は、その後、ブロック620に流れることができ、そこでトークン配置ヘッダを生成することができる。ブロック620において、セキュリティトークンを断片化している場合、トークン配置ヘッダは、断片の数および各断片のサイズを特定することができる。この処理は、終了ブロック622に流れることができる。

判定ブロック604において。HTTPメッセージの本文全体がセキュリティトークンを含むべきであることを判定することができる。このように判定すると、この処理は、ブロック612に流れることができ、そこで、セキュリティトークンを本文内に挿入する。処理は、その後、ブロック620において継続することができ、そこで、トークン配置ヘッダを生成することができる。

判定ブロック604において、セキュリティトークンを、受信されたメッセージのHTMLフォームフィールド内に配置するべきであることを判定することができる。このように判定すると、処理は、ブロック614に流れることができ、そこで、特定のフォームフィールドを生成することができ、かつセキュリティトークンをその中に挿入する。処理は、その後、ブロック620において継続することができ、そこで、トークン配置ヘッダを生成することができる。

判定ブロック604において、セキュリティトークンを、メッセージ本文内の特定のXML要素内に配置するべきであることを判定することができる。このように判定すると、処置はブロック616に流れることができ、そこで、特定のXML要素を生成し、かつセキュリティトークンをその中に挿入する。処理は、その後、ブロック620において継続することができ、そこでトークン配置ヘッダを生成することができる。

図7は、例示の実施形態における、HTTPメッセージからセキュリティトークンを抽出する処理700を示すフロー図である。処理700は、上述のように、ブロック508および518の動作の少なくともいくつかの動作を示す。処理700の示された部分を、ブロック702で開始することができ、そこで、セキュリティトークンの1または複数の配置を判定することができる。このことは、トークンの配置を特定し、およびトークンを断片化する場合、断片の数を特定するトークン配置ヘッダの分析を含むことができる。一実装において、セキュリティトークンを、4つの配置のいずれかにて構成することができる。判定ブロック704において、処理は、4つのブロックのうちの1つに分岐し、それぞれ配置オプションを取り扱うことができる。このような配置の1つは、1または複数のHTTPヘッダ内にある配置である。この配置であると判定した場合、処理はブロック706に流れることができ、そこで、セキュリティトークンの断片を、ヘッダの各々から抽出する。2以上の断片が2以上の対応するヘッダ内にある場合、これらを組み合わせて、セキュリティトークンを形成する。この処理は、その後、図5のブロック510または520において継続することができる。

判定ブロック704において、HTTPメッセージの本文全体がセキュリティトークンを含んでいると判定することができる。このように判定した場合、処理はブロック708に流れることができ、そこで、セキュリティトークンを本文から抽出する。この処理は、その後、ブロック510または520において継続することができる。

判定ブロック704において、セキュリティトークンを、受信されたメッセージの特定のHTMLフォームフィールド内に配置していることを判定することができる。このように判定した場合、処理はブロック710に流れることができ、そこで、セキュリティトークンを特定のフォームフィールドから抽出する。この処理は、その後、ブロック510または520において継続することができる。

判定ブロック704において、セキュリティトークンを、メッセージ本文内の特定のXML要素内に配置していることを判定することができる。このように判定した場合、処理はブロック712に流れることができ、そこでセキュリティトークンをXML要素から抽出する。一実施形態において、XML要素の抽出を、トークン配置ヘッダフィールド内で特定されているクエリを用いて実行することができる。この処理は、その後、ブロック510または520において継続することができる。

処理600および700は、セキュリティトークンの配置に関する多数のオプションを可能にする。例えば、セキュリティトークンが、特定のHTTPヘッダサイズ制約に基づいて、単一のHTTPヘッダ内に収めるには長すぎる場合、セキュリティトークンを、複数のHTTPヘッダ内に配置することができる。セキュリティトークンが、全体ヘッダサイズにおけるHTTP制約に基づいて、複数のHTTPヘッダ内に収めるには長すぎる場合、セキュリティトークンを、メッセージ本文内に配置することができる。この処理は、さらに、HTMLまたはXMLを含む異なったプロトコルのメッセージ本文に適応する。例えば、要求は、HTTP POSTメッセージの形式とすることができる。
例示のメッセージ
この節は、環境300において説明されたメッセージまたは他のメッセージを実装するために使用することができるメッセージ内容の例を説明する。これらの説明を、実施例のセットとして理解すべきである。様々な実施形態において、これらの実施例を、それら全体としてまたはそれらのサブセットとして使用し、これにより認証スキームまたはプロトコルを形成することができる。様々な実施形態において、キーワードまたはパラメータは異なってもよく、およびその上、キーワードまたはパラメータを使用し、本明細書に記載されているメカニズムの少なくともいくつかを実行することができる。一実施形態において、これらの実施例を1つも使用しない。

一実施形態において、本明細書に記載されているメッセージを使用し、RFC2617の認証プロトコルの拡張部であるプロトコルを形成する。名称「WSSEC」を、本明細書において、このプロトコルに関する呼称として使用する。本明細書で説明されているプロトコルは、HTTP要求を認証する様々なスキームを容易にする。このプロトコルはまた、WSSECプロトコルと共に使用するそのセマンティクス、および新しいHTTP拡張ヘッダのセットを、このプロトコルをスタック内のHTTP層においてまたはHTTP層の上のアプリケーション内で実装することができるような方法にて定義することができる。

本明細書において上述されているように、本明細書内に記載されている様々な動作を、アプリケーション210のアプリケーション認証モジュール212(図2)、またはHTTPスタック206の認証モジュール208によって実行することができる。一実施形態において、メッセージおよびメッセージヘッダを、アプリケーション210またはHTTPスタック206による実装を提供するように設計し、アプリケーションは、HTTPスタックがヘッダまたはパラメータの少なくともいくつかを認識せずまたは処理しない環境においてこれらのメカニズムの少なくともいくつかを実装することができる。例えば、いくつかのウェブサーバを、特定されている認証スキームをウェブサーバが認識しない場合に、標準のHTTP認証ヘッダを取り除くように構成する。このような環境において、本明細書において定義されているカスタムヘッダは、アプリケーションにまだ使用可能であり、認証プロトコルを成立させる。

ある環境において、HTTPスタックを、本明細書において説明されている認証スキームを認識し、かつ処理するように構成することができ、アプリケーションを、これらのタスクを実行することから解放する。従って、証明書利用者が本明細書に記載されているヘッダを認識するかまたは実装するHTTPスタックを有するかに関わらず、要求者は、同一の態様にて様々な証明書利用者とやりとりをすることができる。同様に、証明書利用者は、要求者の各HTTPスタックが本明細書に記載されているHTTPヘッダを実装しているかに関わらず、様々な要求者とやりとりすることができる。さらに、アプリケーションは、HTTPスタックを、認証スキームを処理しない環境において展開することができる。HTTPスタックを更新し、認証スキームを処理する場合、アプリケーションは、機能し続けて、HTTPスタックが認証動作を実行することを可能にする。

表1は、記載されたメッセージの各々において使用可能なHTTPヘッダを示す。各メッセージにおいて、記載されていない追加のHTTPヘッダを含むことができる。

表2は、表1の各HTTPヘッダに関して、ヘッダに包含可能なパラメータのセットを示す。例示の実施形態において、パラメータの多くが、パラメータ名を表すキーワードの後にパラメータの値が続く「name=value」形式である。一実施形態において、様々な実施形態においてプロトコルが異なり得るが、角括弧内に列挙されているパラメータは任意的であるとみなされる。

以下の説明において、ヘッダを使用し、ヘッダの記述の特定を補助するが、ヘッダの使用は、関連するテキストをヘッダに限定すること、またはヘッダの記述を付随するテキストに限定することを示唆しない。

WWW−Authenticateヘッダ
一実施形態において、不許可メッセージ312内のキーワード「WSSEC」を伴うWWW−Authenticateヘッダの使用は、本明細書内に記載されているメカニズムの少なくともいくつかに関するサポートを示す。

WWW−Authenticateヘッダは、1または複数の認証仕様を含む。このHTTPヘッダにおいて、「realm-spec」は、保護領域を特定することができる。セキュリティトークンプロファイルは、ダイレクトセキュリティトークンの生成の形式および対応するアルゴリズムを特定する。トークンプロファイルの例は、仕様ケロベロスv.5サービスチケットプロファイル、x.509v3認証プロファイル、SAMLv1.1アサーション、SAMLv2.0アサーション、または証明書利用者によって発行されたセキュリティコンテキストトークンを含む。
X−WSS−Authenticateヘッダ
一実施形態において、X−WSS−Authenticateヘッダを、不許可メッセージ312の中で証明書利用者によって使用し、認証仕様および、さらに具体的には、要求者を指示し、後に続くメッセージで使用するという署名仕様を送ることができる。パラメータを以下のように定義する。

nonce-value:Base64でエンコードされたノンス値。
signature-method:要求を署名するために使用される署名アルゴリズムの任意的な仕様。

signature-usage:証明書利用者が要求内の署名を介して要求者に伝達したい意味論的使用法または目的(semantic usage or purpose)の任意的な仕様。
version;プロトコルバージョンの任意的な仕様。

以下は、WWW−AuthenticateおよびX−WSS−Authenticateヘッダを含む不許可メッセージ312の少なくとも一部の例示の実施形態である:

許可ヘッダ
一実施形態において、許可ヘッダを、要求者によって要求メッセージ318内に含め、認証に関するWSSECプロトコルへの準拠を示す。「realm-spec」および「token-profile」パラメータは、各々任意的とすることができる。一実施形態において、これらのフィールドの各々は、許可ヘッダを含む場合、不許可メッセージ312において証明書利用者から受信されるWWW−Authenticateヘッダ内の対応するフィールドに合致する。
X−WSS−Securityヘッダ
一実施形態において、X−WSS−Securityヘッダを要求メッセージ318内で使用し、デジタル署名に関連するセキュリティ情報を提供し、および証明書利用者から受信された署名仕様への準拠を示すことができる。このヘッダは、要求認証に使用されるセキュリティトークンの所有の証明を提供することを要求者に可能にするプロトコルパラメータを有する。さらに具体的にいうと、このヘッダは、トークンを要求に暗号的に結び付ける認証トークン内にある暗号化キー(key material)を使用するデジタル署名を含むことができる。一実施形態において、パラメータを以下のように定義する。

「timestamp-value」、これは、整数のタイムスタンプ値を特定する。
「nonce-value」、これは、Base64でエンコードされたノンス値とすることができる。

「signature-method」、これは、要求を署名するために使用される署名アルゴリズムを任意的に特定する。
「signature-usage」、これは、要求者が要求内の署名を介して伝達したいと望む意味論的使用方法または目的の任意的な仕様である。

「signature-value」、これは、要求のデジタル署名の任意的な値である。
「protocol-version」、これは、プロトコルバージョンの任意的な仕様である。
ノンスおよびタイムスタンプは、要求リプレイ攻撃の阻止の前に、要求を提示しなかったことの保証を提供する。このノンスは、同一のタイムスタンプを有する複数のメッセージをリプレイするかまたは複製するかを判定することを証明書利用者に可能とさせる乱数とすることができる。以下は、認証およびX−WSS−Securityヘッダを含む要求メッセージ318の部分の一例である。

X−WSS−TokenLoc
一実施形態において、X−WSS−TokenLocヘッダは、HTTPメッセージ内のセキュリティトークンの配置を特定する。このセキュリティトークンは、ダイレクトまたは非ダイレクトセキュリティトークンとすることができる。これらのパラメータを、以下のように定義する。

「location-type」、これは、トークンの配置を特定する。これは、キーワード「header」「body」「body-form」または「body-xml」のうちの1つとすることができる。
「fragment-count」および「fragment-size」、これらのパラメータを、「header」配置と共に使用し、ならびにそれぞれ、断片の数および各断片のサイズを特定する。

「form-field-name」、これを、「body-form」配置と共に使用する。これは、HTMLフォーム内のフィールド名を特定する。
「query-type」および「query-string」、これらのパラメータは、「body-xml」配置と共に使用され、およびクエリを特定し、xml要素を抽出することができる。
X−WSS−Tokenヘッダ
一実施形態において、本明細書において説明されているように、X−WSS−TokenLocヘッダの「location-type」パラメータの値を「header」として特定する場合、X−WSS−Tokenヘッダを使用し、セキュリティトークンを送信する。ダイレクトセキュリティトークンの仕様を、認証ヘッダ内の「token-profile」パラメータによって特定することができ、かつ証明書利用者から受信された認証仕様に準拠することができる。

セキュリティトークンは1つの断片内にあるか、または複数の断片内に分割可能であり、各断片を、異なったX−WSS−Tokenヘッダフィールドによって保持する。断片の数を、X−WSS−TokenLocヘッダの「fragment-count」フィールドによって示すことができる。

一実施形態において、各X−WSS−Tokenヘッダの名前を、基本の「X-WSS-Token」に、整数値の添え字 N=1,...,断片数 を付けることによって生成し、ここで断片数は、X−WSS−TokenLocヘッダの「fragment-count」フィールドによって特定されるような、トークンを分割して入れる断片の数である。例えば、「X-WSS-Token1」と名付けられたヘッダは、第1のトークン断片を保持することができ、「X-WSS-Token2」と名付けられたヘッダは、第2のトークン断片を保持することができる、等である。一実施形態において、このヘッダによって送信されたトークンの受信者は、基本名「XWSS-Token」を有する全てのヘッダを収集して、およびそれらの内容を、順番に結び付けてトークン全部の内容を再構築する。
X−WSS−Digestヘッダ
一実施形態において、X−WSS−Digestヘッダを使用し、メッセージ内に保持されている本文の要約を送信することができる。少なくともいくつかのHTTPヘッダの一部を、要約内に含むことができる。特に、認証に関連するHTTPヘッダの少なくともいくつかを含むことができる。これは、表2に列挙されている「X−WSS」ヘッダを含むことができる。要約を処理する前に、処理すべき内容を、正規化形式に変換することができる。内容の正規化は、全ての文字を小文字にすること、空白スペースを除去すること、ヘッダまたはパラメータをアルファベット順にソートすること、URLを正規化すること等の変換を含むことができる。この要約は、完全性保護を提供して、かつメッセージ本文またはヘッダの検証を容易にする。一実施形態において、このヘッダを、「sigusage」パラメータによって示されるメッセージ本文をカバーする署名を有するX−WSS−セキュリティヘッダとともに使用する。一実施形態において、このメッセージのパラメータを以下のように使用する。

「digest-method」、この文字列は、本文の要約を処理するために使用されるハッシュアルゴリズムを特定する。
「content-digest」、これはBase64でエンコードされた要約値を特定するバイナリ値パラメータである。

以下は、SHA−1要約方法を特定する際に使用することができるX−WSS−要約ヘッダの一例である。
X-WSS-Digest: method=”sha1” digest=”3F679YHluax2dc”
X−WSS−AuthInfoヘッダ
一実施形態においてX−WSS−AuthInfoヘッダを、証明書利用者によって応答メッセージ320内で使用し、要求認証が成功した後に、追加のパラメータを、認証に関連する要求者に送信することができる。これらのパラメータは、任意の後の要求認証の動作に影響を与えるか、または当該動作を変更することができる。一実施形態において、このメッセージのパラメータを以下のように使用する。

「nonce-value」、これは、次の要求認証に使用されるべき新しいノンス値を特定する。このパラメータが存在する場合、このパラメータは、この証明書利用者への次の要求メッセージのX−WSS−Securityヘッダ内で、この値を使用するように要求者に指示する。

「context-token」、このパラメータは、証明書利用者によって要求者のために設定されるセキュリティコンテキストを表す暗号化クッキー等のセキュリティコンテキストトークンを含む。このパラメータは、そのセキュリティコンテキストトークンを、将来の要求において使用すべきことを要求者に指示する。セキュリティコンテキストの保持の証明を提供するために使用される暗号化キーを、「context-token」パラメータ内で特定する。

「context-token-secret」、このパラメータを、「context-token」パラメータと共に使用する。このパラメータは、「context-token」パラメータによって表されたセキュリティコンテキストの所有権を証明するために要求者によって使用可能な秘密対称暗号化キーを特定する。

証明書利用者は、ワンタイム・ノンスを実装する手段として「nonce-value」パラメータを送信することができる。証明書利用者は、「context-token」および「context-token-secret」パラメータの組み合わせを使用して、要求者のためのセキュリティコンテキストを構築し、そのコンテキスト内の将来の認証は、(例えば、トークンサイズが大きい場合、)最初の要求と共に提示されるセキュリティトークンを含む必要は無い。一実施形態において、要求者および証明書利用者は、SSLまたはTLS等のトランスポート層セキュリティを使用して、このやりとりの機密性を保護する。

以下は、セキュリティコンテキストトークンおよび対応する証明キーを有するX−WSS−AuthInfoヘッダを含む応答メッセージ320の例である。
X-WSS-AuthInfo: ctxtoken=”fg75kVB890Uwstm…”,ctxtokensecret=”gU59cJH…”
図8は、実施形態の一例における、HTTPメッセージの生成の処理800を示すフロー図である。処理800は、上述されるようなブロック418の動作の少なくともいくつかを示している。処理800の示されている部分を、ブロック802で開始することができ、そこで、セキュリティトークンを、メッセージ本文または1もしくは複数のHTTPヘッダに挿入する。ブロック802の動作は、図6において説明されている。

ブロック804において、セキュリティトークンの配置の仕様を含むトークン説明ヘッダを生成する。ブロック804の動作は、図6において説明されている。表2および関連する説明は、トークン配置ヘッダの一実施形態を説明している。

ブロック806において、デジタル署名を生成し、かつセキュリティヘッダ内に挿入することができる。表2および関連する説明は、セキュリティヘッダの一実施形態を説明している。

ブロック808において、許可ヘッダを生成することができる。表2および関連する説明は、許可ヘッダの一実施形態を説明している。
ブロック810において、要約を生成し、かつ要約ヘッダ内に挿入することができる。表2および関連する説明は、要約ヘッダの一実施形態を説明している。処理800は、ブロック820に流れて終了するか、またはプログラム呼び出しに戻ることができる。

一実施形態では、ブロック810の動作を実行せず、および要約ヘッダを生成しない。様々な実施形態において、本明細書において説明されている他のヘッダを、要求ヘッダから除外することができる。図8のブロックおよび関連する動作の順序は、様々な順序でなされてもよく、およびこの処理を図示された順序に限定しない。

本明細書において上述されたように、一実施形態において、要求者は、本明細書において説明されたメカニズムおよびプロトコルの少なくともいくつかを使用して、IDプロバイダからのトークンを要求することができる。以下は、このような使用法の一例であり、この例は、要求STメッセージ314の少なくとも一部を形成することができる。この例において、HTTP POSTメソッドを要求に使用している。

他の例において、POST本文内のXMLベースのペイロードの代わりに、XMLタグ名とフォームフィールド名との間のマッピングを定義することによって、フォームベース(form-based)のペイロードを使用することができる。例えば、フォームベースのペイロードを使用する上述の要求を、以下に示す。

図4−8のフローチャート図の各ブロック、およびフローチャート図内のブロックの組み合わせを、ソフトウェア命令によって実装することができることを理解されたい。これらのプログラム命令を、プロセッサに提供し、プロセッサ上で実行される命令が、フローチャートのブロック(1または複数)内で特定される動作を実装する手段を生成するようなマシンをもたらすことができる。ソフトウェア命令をプロセッサによって実行し、フローチャートのブロック(1または複数)内で特定される動作を実装するステップをもたらすることができる。さらに、フローチャート図内の1もしくは複数のブロックまたはブロックの組み合わせを、本発明の範囲または趣旨から逸脱することなく、他のブロックもしくはブロックの組み合わせと同時に実行することができ、または図示されているのと異なる順序で実行することができる。

上述の明細書、例示、およびデータは、本発明の製品および本発明の構成の使用法の完全な説明を提供する。従って、本発明の多くの実施形態を、本発明の趣旨および範囲から逸脱することなく行なうことができ、本発明は添付の特許請求の範囲内にある。

Claims (7)

  1. 要求者が使用するクライアントコンピュータと、サーバコンピュータとの間で交換されるメッセージを処理するコンピュータベースのシステムであって、前記システムは、動作を実行するように構成され、前記動作は、
    前記クライアントコンピュータが、認証仕様を含む1または複数のHTTPヘッダを含むサーバメッセージに応答して、前記認証仕様に適合する要求メッセージを生成するステップと、
    前記クライアントコンピュータが、前記要求メッセージ内に、前記認証仕様内のセキュリティトークン仕様に適合するセキュリティトークンを挿入するステップと、
    前記クライアントコンピュータが、前記要求メッセージ内に、前記セキュリティトークンの配置を特定するHTTPトークン配置ヘッダを挿入するステップと、
    前記クライアントコンピュータが、前記要求メッセージ内に、少なくとも1つのHTTPヘッダの暗号化表現を含む要約を含むHTTP要約ヘッダを挿入するステップと、
    前記クライアントコンピュータが、前記要求メッセージ内に、前記要求メッセージの少なくとも一部のデジタル署名を含むセキュリティヘッダを挿入するステップと
    を含むことを特徴とするコンピュータベースのシステム。
  2. 請求項1に記載のコンピュータベースのシステムであって、前記動作は、前記クライアントコンピュータが、前記セキュリティトークンのサイズに基づいて前記セキュリティトークンの配置を判定するステップをさらに含み、前記配置を判定するステップは、前記セキュリティトークンが1もしくは複数のHTTPヘッダ内にあるかまたはメッセージ本文内にあるかの判定を含むことを特徴とするコンピュータベースのシステム。
  3. 請求項1に記載のコンピュータベースのシステムであって、前記要求メッセージはHTTP POSTメッセージであり、前記動作は、前記クライアントコンピュータが、前記セキュリティトークンをメッセージ本文内のHTMLフォームフィールド内に挿入するステップをさらに含むことを特徴とするコンピュータベースのシステム。
  4. 請求項1に記載のコンピュータベースのシステムであって、前記動作は、前記クライアントコンピュータが、前記セキュリティトークンの配置を前記セキュリティトークンのサイズに基づいて判定するステップをさらに含み、前記配置を判定するステップは、前記セキュリティトークンが、正確に1つのHTTPヘッダの中にあるか、複数のHTTPヘッダの中にあるか、またはメッセージ本文内にあるかの判定を含むことを特徴とするコンピュータベースのシステム。
  5. 請求項1に記載のコンピュータベースのシステムであって、前記要求メッセージは、前記サーバコンピュータによって受信され、前記セキュリティトークンは、前記サーバコンピュータによって、メッセージ本文から、前記HTTPトークン配置ヘッダに基づいて選択的に抽出され、前記セキュリティトークンは、前記サーバコンピュータによって、正確に1つのHTTPヘッダから、前記HTTPトークン配置ヘッダに基づいて選択的に抽出され、および前記セキュリティトークンの複数の断片は、前記サーバコンピュータによって、複数のHTTPヘッダから、前記HTTPトークン配置ヘッダに基づいて選択的に抽出されることを特徴とするコンピュータベースのシステム。
  6. 請求項1に記載のコンピュータベースのシステムであって、前記要求メッセージを生成するステップは、前記1または複数のHTTPヘッダを、HTTPヘッダ名を使用することによって生成することを含み、前記HTTPヘッダ名は、前記メッセージを認証することを、前記セキュリティトークンを抽出してかつ検証することによって、前記サーバコンピュータのHTTPスタックができるようにし、および前記サーバコンピュータの前記HTTPスタックが前記セキュリティトークンを抽出してかつ検証するように構成されていない場合に、前記HTTPヘッダ名は、前記メッセージを認証することを、前記セキュリティトークンを抽出してかつ検証することによって、前記サーバコンピュータのアプリケーションができるようにすることを特徴とするコンピュータベースのシステム。
  7. 請求項1に記載のコンピュータベースのシステムであって、前記動作は、前記クライアントコンピュータが、前記セキュリティトークンをメッセージ本文内に挿入するステップをさらに含み、前記HTTPトークン配置ヘッダは、前記メッセージ本文全体が前記セキュリティトークンを含むことを特定することを特徴とするコンピュータベースのシステム。
JP2014206285A 2009-05-14 2014-10-07 Httpベースの認証 Active JP5889988B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/465,725 US8078870B2 (en) 2009-05-14 2009-05-14 HTTP-based authentication
US12/465,725 2009-05-14

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2012510942 Division 2010-05-11

Publications (2)

Publication Number Publication Date
JP2015026391A JP2015026391A (ja) 2015-02-05
JP5889988B2 true JP5889988B2 (ja) 2016-03-22

Family

ID=43069462

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2012510942A Active JP5658745B2 (ja) 2009-05-14 2010-05-11 Httpベースの認証
JP2014206285A Active JP5889988B2 (ja) 2009-05-14 2014-10-07 Httpベースの認証

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2012510942A Active JP5658745B2 (ja) 2009-05-14 2010-05-11 Httpベースの認証

Country Status (5)

Country Link
US (1) US8078870B2 (ja)
EP (1) EP2430792B1 (ja)
JP (2) JP5658745B2 (ja)
CN (1) CN102422593B (ja)
WO (1) WO2010132462A2 (ja)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7739724B2 (en) * 2005-06-30 2010-06-15 Intel Corporation Techniques for authenticated posture reporting and associated enforcement of network access
US20080201338A1 (en) * 2007-02-16 2008-08-21 Microsoft Corporation Rest for entities
US9191235B2 (en) * 2010-02-05 2015-11-17 Microsoft Technology Licensing, Llc Moderating electronic communications
WO2012005739A1 (en) * 2010-07-09 2012-01-12 Hewlett-Packard Development Company, L.P. Responses to server challenges included in a hypertext transfer protocol header
US8825745B2 (en) 2010-07-11 2014-09-02 Microsoft Corporation URL-facilitated access to spreadsheet elements
US8713589B2 (en) 2010-12-23 2014-04-29 Microsoft Corporation Registration and network access control
US8447857B2 (en) * 2011-03-25 2013-05-21 International Business Machines Corporation Transforming HTTP requests into web services trust messages for security processing
US8775555B2 (en) * 2011-05-13 2014-07-08 Sap Ag Rest interface interaction with expectation management
CN102938757B (zh) * 2011-08-15 2017-12-08 中兴通讯股份有限公司 共享网络中用户数据的方法和身份提供服务器
US8914502B2 (en) * 2011-09-27 2014-12-16 Oracle International Corporation System and method for dynamic discovery of origin servers in a traffic director environment
US8819794B2 (en) * 2012-01-19 2014-08-26 Microsoft Corporation Integrating server applications with multiple authentication providers
US9026784B2 (en) 2012-01-26 2015-05-05 Mcafee, Inc. System and method for innovative management of transport layer security session tickets in a network environment
CN103312665A (zh) * 2012-03-09 2013-09-18 阿尔卡特朗讯公司 用于敏感数据的安全机制
CN102799631B (zh) * 2012-06-26 2015-06-17 公安部第三研究所 基于rest实现网络电子身份标识业务过程管理控制的方法
US9628542B2 (en) * 2012-08-24 2017-04-18 Akamai Technologies, Inc. Hybrid HTTP and UDP content delivery
US9210145B2 (en) 2012-10-02 2015-12-08 Blackberry Limited Method and system for hypertext transfer protocol digest authentication
US9553915B2 (en) * 2012-10-10 2017-01-24 Ca, Inc. Method and system for implementing commands
JP6190106B2 (ja) * 2012-11-19 2017-08-30 キヤノン株式会社 認証システム、認証装置、認証方法、及びプログラム
WO2014193896A2 (en) * 2013-05-28 2014-12-04 Raytheon Company Message content ajudication based on security token
US9231915B2 (en) * 2013-10-29 2016-01-05 A 10 Networks, Incorporated Method and apparatus for optimizing hypertext transfer protocol (HTTP) uniform resource locator (URL) filtering
US10223550B2 (en) * 2013-11-06 2019-03-05 Vmware, Inc. Generating canonical representations of JSON documents
US9397990B1 (en) * 2013-11-08 2016-07-19 Google Inc. Methods and systems of generating and using authentication credentials for decentralized authorization in the cloud
US9509694B2 (en) 2013-12-31 2016-11-29 EMC IP Holding Company LLC Parallel on-premises and cloud-based authentication
JP5838248B1 (ja) * 2014-09-24 2016-01-06 株式会社 ディー・エヌ・エー ユーザに所定のサービスを提供するシステム及び方法
CN104394147B (zh) * 2014-11-26 2017-06-16 西安电子科技大学 在安卓系统的http协议中添加身份认证信息的方法
US9641504B2 (en) * 2014-12-15 2017-05-02 Sap Se HTTP header-based adaptable authentication mechanism
JP6418966B2 (ja) * 2015-01-29 2018-11-07 キヤノン株式会社 画像形成システム、画像形成装置、該システムの制御方法、及びプログラム
US9350556B1 (en) 2015-04-20 2016-05-24 Google Inc. Security model for identification and authentication in encrypted communications using delegate certificate chain bound to third party key
US10044718B2 (en) 2015-05-27 2018-08-07 Google Llc Authorization in a distributed system using access control lists and groups
CN105407102B (zh) * 2015-12-10 2019-05-17 四川长虹电器股份有限公司 http请求数据可靠性验证方法
SG11201806343XA (en) * 2016-01-26 2018-08-30 Soracom Inc Server and program
WO2017131892A1 (en) 2016-01-29 2017-08-03 Google Inc. Device access revocation
JP6130941B2 (ja) * 2016-02-03 2017-05-17 キヤノン株式会社 認証装置、方法、及びプログラム
JP6342441B2 (ja) * 2016-03-09 2018-06-13 株式会社東芝 認証処理装置および認証システム

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7000A (en) * 1850-01-08 Smut-machine
JP3932685B2 (ja) * 1998-08-11 2007-06-20 富士ゼロックス株式会社 ネットワーク上で遠隔手続き呼び出しを実行するための方法、及び、遠隔手続き呼び出しを実行可能なネットワーク・システム
US6986047B2 (en) * 2001-05-10 2006-01-10 International Business Machines Corporation Method and apparatus for serving content from a semi-trusted server
JP4053269B2 (ja) * 2001-09-27 2008-02-27 株式会社東芝 データ転送装置およびデータ転送方法
US7191467B1 (en) * 2002-03-15 2007-03-13 Microsoft Corporation Method and system of integrating third party authentication into internet browser code
JP2006525592A (ja) * 2003-05-01 2006-11-09 サムスン エレクトロニクス カンパニー リミテッド 認証方法及びその装置
KR100856674B1 (ko) * 2003-07-11 2008-09-04 인터내셔널 비지네스 머신즈 코포레이션 클라이언트 서버 환경에서 클라이언트를 인증하는 시스템및 방법
JP4612906B2 (ja) * 2003-09-12 2011-01-12 キヤノン株式会社 シーケンスを送信する方法、装置、及びコンピュータ・プログラム
JP4384177B2 (ja) * 2003-10-14 2009-12-16 シーメンス アクチエンゲゼルシヤフトSiemens Aktiengesellschaft 移動無線網とimsネットワークとの間のデータトラフィックを保護する方法
US20050154886A1 (en) * 2004-01-12 2005-07-14 International Business Machines Corporation Declarative trust model between reverse proxy server and websphere application server
US20050268326A1 (en) * 2004-05-04 2005-12-01 Microsoft Corporation Checking the security of web services configurations
US7434252B2 (en) * 2004-07-14 2008-10-07 Microsoft Corporation Role-based authorization of network services using diversified security tokens
US8019818B2 (en) * 2005-01-18 2011-09-13 Zlango Ltd. Communications network system and methods for using same
US20060282886A1 (en) * 2005-06-09 2006-12-14 Lockheed Martin Corporation Service oriented security device management network
US8266327B2 (en) * 2005-06-21 2012-09-11 Cisco Technology, Inc. Identity brokering in a network element
US7788499B2 (en) * 2005-12-19 2010-08-31 Microsoft Corporation Security tokens including displayable claims
CN101060519B (zh) * 2006-04-19 2011-08-17 上海贝尔阿尔卡特股份有限公司 使用户使用指定拨号程序进行拨号的控制方法及其装置
US7694131B2 (en) * 2006-09-29 2010-04-06 Microsoft Corporation Using rich pointers to reference tokens
US8001588B2 (en) * 2006-12-12 2011-08-16 Oracle International Corporation Secure single sign-on authentication between WSRP consumers and producers
US20080168273A1 (en) * 2007-01-05 2008-07-10 Chung Hyen V Configuration mechanism for flexible messaging security protocols
US8407767B2 (en) * 2007-01-18 2013-03-26 Microsoft Corporation Provisioning of digital identity representations
JP2008276724A (ja) * 2007-03-30 2008-11-13 Terumo Corp webサーバ、webサーバとして機能させるためのプログラム及び情報提供方法
EP1993255B1 (en) * 2007-05-18 2009-04-15 Sap Ag Method and system for protecting a message from an XML attack when being exchanged in a distributed and decentralized network system
US8528058B2 (en) * 2007-05-31 2013-09-03 Microsoft Corporation Native use of web service protocols and claims in server authentication
CA2720398C (en) * 2008-04-02 2016-08-16 Twilio Inc. System and method for processing telephony sessions
US8479006B2 (en) * 2008-06-20 2013-07-02 Microsoft Corporation Digitally signing documents using identity context information
US9736153B2 (en) * 2008-06-27 2017-08-15 Microsoft Technology Licensing, Llc Techniques to perform federated authentication
US8910256B2 (en) * 2008-08-08 2014-12-09 Microsoft Corporation Form filling with digital identities, and automatic password generation
CN101350820A (zh) * 2008-08-29 2009-01-21 中兴通讯股份有限公司 一种推送业务代理网关对推送业务发起者的安全认证方法
US8347356B2 (en) * 2009-03-31 2013-01-01 Microsoft Corporation Adaptive HTTP authentication scheme selection

Also Published As

Publication number Publication date
EP2430792A4 (en) 2016-09-28
WO2010132462A2 (en) 2010-11-18
EP2430792B1 (en) 2017-04-19
JP2015026391A (ja) 2015-02-05
CN102422593B (zh) 2013-03-13
JP2012527179A (ja) 2012-11-01
WO2010132462A3 (en) 2011-02-24
JP5658745B2 (ja) 2015-01-28
US8078870B2 (en) 2011-12-13
US20100293385A1 (en) 2010-11-18
EP2430792A2 (en) 2012-03-21
CN102422593A (zh) 2012-04-18

Similar Documents

Publication Publication Date Title
US10642969B2 (en) Automating internet of things security provisioning
US9026788B2 (en) Managing credentials
JP6170158B2 (ja) モバイルマルチシングルサインオン認証
US20190081799A1 (en) System for authenticating certificate based on blockchain network, and method for authenticating certificate based on blockchain network by using same
Chadwick et al. Adding federated identity management to openstack
EP2545482B1 (en) Secure dynamic authority delegation
EP2633716B1 (en) Data processing for securing local resources in a mobile device
KR101434769B1 (ko) 신뢰적인 연합 아이덴티티 관리 및 데이터 액세스 인가를 위한 방법 및 장치
TWI475860B (zh) 可攜式裝置關聯性
US8112787B2 (en) System and method for securing a credential via user and server verification
US9537861B2 (en) Method of mutual verification between a client and a server
US7197568B2 (en) Secure cache of web session information using web browser cookies
ES2660541T3 (es) Marco de autenticación de dispositivo modular
US7690026B2 (en) Distributed single sign-on service
US6446206B1 (en) Method and system for access control of a message queue
US7904952B2 (en) System and method for access control
US8499339B2 (en) Authenticating and communicating verifiable authorization between disparate network domains
US8812838B2 (en) Configuring a valid duration period for a digital certificate
CN101427510B (zh) 用于网络功能描述的数字通行
KR100946110B1 (ko) 기존 ssl 세션을 브레이킹하지 않고 인증서-기반 인증으로 스텝 업하는 방법 및 시스템
CA2463034C (en) Method and system for providing client privacy when requesting content from a public server
EP1427160B1 (en) Methods and systems for authentication of a user for sub-locations of a network location
US8990356B2 (en) Adaptive name resolution
US8024488B2 (en) Methods and apparatus to validate configuration of computerized devices
KR101459802B1 (ko) 암호화 증명의 재검증에 기반을 둔 인증 위임

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20151216

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: 20160119

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160217

R150 Certificate of patent or registration of utility model

Ref document number: 5889988

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

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