2012年8月17日金曜日

OpenID Connect Session Management 1.0 - draft 08 日本語私訳

Draft: OpenID Connect Session Management 1.0 - draft 08

「OpenID Connect Session Management 1.0 - draft 08」も和訳してみました。 原文は http://openid.net/specs/openid-connect-session-1_0.html です。

 TOC 
DraftB. de Medeiros
 N. Agarwal
 Google
 N. Sakimura, Ed.
 NRI
 J. Bradley
 Ping Identity
 M. Jones
 Microsoft
 August 2, 2012


OpenID Connect Session Management 1.0 - draft 08

概要

注：これは2012年5月5日のワーキンググループ会議での決定に基づく、大幅な書き換えの最初のカットです。

OpenID Connect 1.0は、OAuth 2.0上に作られたシンプルなアイデンティティ層である。そして、相互運用可能でRESTfulな方法により、エンドユーザに関する基本的なプロファイル情報の取得と同様に、認可サーバによる認証に基づくエンドユーザのアイデンティティの検証も、クライアントに対し可能とする。

このドキュメントでは、OpenID Connectのセッションを管理する方法について記述する。


目次

1.  はじめに
    1.1.  要求記法および規則
    1.2.  用語
2.  エンドポイントディスカバリ
3.  セッションの作成と更新
4.  セッション状態変更通知
    4.1.  OP iframe
    4.2.  RP iframe
5.  RP開始のログアウト
6.  IANAに関する考慮事項
7.  セキュリティに関する考慮事項
8.  規定文献
Appendix A.  謝辞
Appendix B.  通知
Appendix C.  文書履歴
§著者アドレス



 TOC 

1.  はじめに

OpenID Connect MessageとStandardはIDトークンに基づいてRPにユーザがログインする方法を定義しているが、ユーザがOPからログアウトしたらRPでもログアウトさせるために、OPにおけるユーザのログイン状態を継続的に監視する方法については述べていない。


 TOC 

1.1.  要求記法および規則

本文書で用いられる各キーワード「MUST (しなければならない)」、「MUST NOT (してはならない)」、「REQUIRED (必須である)」、「SHALL (するものとする)」、「SHALL NOT (しないものとする)」、「SHOULD (すべきである)」、「SHOULD NOT (すべきではない)」、「RECOMMENDED (推奨される)」、「MAY (してもよい)」、「OPTIONAL (任意である)」は [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) で述べられている通りに解釈されるべきものである。 [RFC2119].

本文書では、書いてあるままに解釈されるべき値は引用符 ("") で囲んで示している。プロトコルメッセージの中でこれらの値を使用する場合は、値の一部として引用符を用いてはならない (MUST NOT)。


 TOC 

1.2.用語

当仕様は、OAuth 2.0 (Hardt, D., “OAuth 2.0 Authorization Protocol,” July 2012.) [OAuth2.0]で定義されている、「アクセストークン」、「リフレッシュトークン」、「認可コード」、「認可グラント」、「認可サーバ」、「認可エンドポイント」、「クライアント」、「クライアント識別子」、「クライアントシークレット」、「保護リソース」、「リソース所有者」、「リソースサーバ」、「トークンエンドポイント」という用語と、OpenID Connect Messages 1.0 (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.) [OpenID.Messages]で定義されている用語を用いる。


 TOC 

2.  エンドポイントディスカバリ

OpenID Connectのセッション管理をサポートするために、RPは、セッション管理に関連するエンドポイントURLを取得しなければならない (MUST)。OpenID Connect Discoveryの記述のとおり、これはアウトオブバンドか、OPの構成ファイルを介することによって、取得することができる。

当仕様で定義されているOPのエンドポイントは以下のとおり:

OP iframe URL
OP iframeがロードされている元のURL。 このURLは、関連するRPのiframeからのpostMessageを受け付け、OPでのユーザのログイン状態を返すページを提供する。
OPログアウトエンドポイントURL
OPでのユーザログアウトを開始するURL。

当仕様で定義されているRPのエンドポイントは以下のとおり:


 TOC 

3.  セッションの作成と更新

OpenID Connectで、RPでのセッションは、通常、RPがユーザのIDトークンを検証したときに開始する。IDトークンの取得とそれの検証の方法を調査するには、OpenID Connect Standardを参照すること。通常、RPがユーザのアイデンティティについて十分な知識を持っている場合、RPは、prompt=noneと、ユーザーのヒントとして以前に取得したIDトークンを指定して、認証要求を送信する。

当仕様では、IDトークンに追加のクレームを一つ定義する。

ops
OPセッション状態。OPでのユーザのログイン状態を表すJSON文字列。この文字列は、RPに対し不透明である。 セッション管理がサポートされている場合は必須 (REQUIRED) 。

 TOC 

4.  セッション状態変更通知

IDトークンは、通常、有効期限が設定されている。RPは、RPセッションの期限切れに、それを利用することがある (MAY)。しかし、ユーザは有効期限切れの前にOPからログアウトする可能性も高い。よって、OPでのユーザのログイン状態を検出できることは非常に望ましい。

これを行うには、prompt=noneを使用して認証要求を繰り返すことで可能である。しかし、これはネットワークトラフィックの原因となり、ますます人気が高まっているモバイルデバイス上では問題である。よって、一度セッションが認証要求と応答で確立されたら、以下のように生成元が制限されたpostMessageと共にRP iframeから隠されたOP iframeをポーリングすることにより、ネットワークトラフィックを発生させずに、OPでのログイン状態をチェックできることが望ましい。


 TOC 

4.1.  OP iframe

RPは、以下のパラメータと共にOP iframe URLから、通常目に見えないOP iframeをロードする。

user_hint
必須。ユーザがログインしたときにRPが受信したIDトークン。RPのclient_idが設定されているaudフィールドの値が、postMessage要求のソース生成元に設定するために使用される。

後で参照できるように、RPはiframeにid属性を割り当てなければならない (MUST)。

OP iframeは、クライアントと共に登録されたソース生成元からのpostMessageを受け付けなければならない (MUST)。他のソース生成元からのpostMessage要求は拒否しなければならない (MUST)。

RP iframeからのpostMessageは、dataパラメータとして以下を連結したセッション状態を提供する:

  1. クライアントID、ソース生成元URL、OPセッション状態、128bit以上のソルトを連結したもののSHA-256ハッシュ。
  2. ASCIIのピリオド('.')文字、つまり0x2E。
  3. ソルト

OP iframeは、事前に取得した、クライアントID、ソース生成元URL、現在のOPセッション状態およびdataパラメータから取得したソルトから、再計算しなければならない (MUST)。受信値と計算値が一致しない場合、OP iframeはソースに文字列changedをpostMessageし返さなければならない (MUST)。一致した場合、文字列unchangedをpostMessageしなければならない (MUST)。

以下は、OP iframeの参考疑似コードである。

window.addEventListener("message",receiveMessage, false);
function receiveMessage(e){
  if ( e.origin !== "http://client.example.net" ) {
    return;
  }
  var stat;
  var opss = get_op_session_state();
  var ss = CryptoJS.SHA256(client_id + origin + opss + salt) + "." + salt;
  if (e.data == ss) {
    stat = 'unchanged';
  } else {
    stat = 'changed';
  }
  e.source.postMessage(stat, e.origin);
};


 TOC 

4.2.  RP iframe

RPは同じページに自身から目に見えないiframeもロードする。このiframeは、OP iframeにpostMessageできるように、OP iframeのidを知らなければならい (MUST)。

RP iframeは、RPアプリケーションに適した一定の間隔のpostMessageでポーリングする。各postMessageと共に、4.1節に定義されたセッション状態を送信する。OP iframeからのpostMessageバックを受信できるようにもしなければならない。受信するデータは、changedかunchangedのいずれかである。changedの受信時は、RPは、OPでの現在のセッション状態を調べるためにprompt=noneと共に再認証しなければならない (MUST)。

以下は、RP iframeの参考疑似コードである。

Var stat = "unchanged";
var mes = CryptoJS.SHA256(client_id + origin + opss + salt) + "." + salt;

function check_session()
{
  var targetOrigin  = "http://server.example.com";
  var win = window.parent.document.getElementById("op").contentWindow;
  win.postMessage( mes, targetOrigin);

}
function setTimer()
{
  check_session();
  timerID = setInterval("check_session()",3*1000);
}

window.addEventListener("message", receiveMessage, false);

function receiveMessage(e)
{
  var targetOrigin  = "http://server.example.com";
  if (e.origin !== targetOrigin ) {return;}
  stat = e.data;
}


 TOC 

5.  RP開始のログアウト

時には、RPはユーザがサイトからログアウトしたことをOPに通知したいこともあるかもしれない。そしてユーザは、OPからも同様にログアウトしたいかもしれない。このケースでは、ユーザがログアウトした後、OPのプロバイダ構成情報の通知か、アウトオブバンドの知識のいずれかによって得たOPのログアウトエンドポイントURL宛てに、RPはユーザを送る。

このようなメッセージの受信時には、OPは、OPからもログアウトしたいかどうか、ユーザにプロンプ​​トを表示すべきである (SHOULD)。ユーザが "yes"と答えた場合、OPはユーザをログアウトさせなければならない (MUST)。


 TOC 

6.  IANAに関する考慮事項

この文書ではIANAへの要求はない。


 TOC 

7.  セキュリティに関する考慮事項

未定


 TOC 

8. 規定文献

[OAuth2.0] Hardt, D., “OAuth 2.0 Authorization Protocol,” July 2012.
[OpenID.Messages] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).

 TOC 

Appendix A.  謝辞

Breno de Medeiros, Naveen Agarwal, George Fletcher, Torsten Lodderstedt, Axel Nennker, Amanda Anganes, Justin Richer, Tony Nadalin, Edmund Jay, Michael B. Jones, John Bradley, and Nat Sakimura contributed to the design of this specification.


 TOC 

Appendix B.  通知

Copyright (c) 2012 The OpenID Foundation.

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.


 TOC 

Appendix C.  文書履歴

[[ To be removed from the final specification ]]

-08

  • Complete rewrite based on the decisions made at the May 5, 2012 face to face working group meeting.

-07

  • Added warning about the significant revisions planned to session management to the abstract and introduction.
  • Changed client.example.com to client.example.org, per issue #251
  • Listed author of ISO29115 as "International Telecommunication Union and International Organization for Standardization", per issue #589
  • Use standards track version of JSON Web Token spec (draft-ietf-oauth-json-web-token)

-06

  • Updated Notices
  • Updated References

-05

  • Removed Check Session Endpoint
  • Updated ID Token claims to reflect changes in Messages

-04

  • Changes associated with renaming "Lite" to "Basic Client" and replacing "Core" and "Framework" with "Messages" and "Standard".
  • Numerous cleanups, including updating references.

-03

  • Corrected examples.

-02

  • Correct issues raised by Johnny Bufu and discussed on the 7-Jul-11 working group call.

-01

  • Consistency and cleanup pass, including removing unused references.

-00

  • Split from core when all optional features were removed.

 TOC 

著者アドレス

  Breno de Medeiros
  Google
Email:  breno@google.com
  
  Naveen Agarwal
  Google
Email:  naa@google.com
  
  Nat Sakimura (editor)
  Nomura Research Institute, Ltd.
Email:  n-sakimura@nri.co.jp
  
  John Bradley
  Ping Identity
Email:  ve7jtb@ve7jtb.com
  
  Michael B. Jones
  Microsoft
Email:  mbj@microsoft.com
投稿者 時刻:
ラベル: ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)