- 追加された行はこのように表示されます。
- 削除された行は
このように表示されます。
!!!CAS Protocol 【CAS Protocol(CAS 1.0/2.0)の私的日本語訳】
著者：Drew Mazurek
協力者：Susan Bramhall, Howard Gilbert, Andy Newman, Andrew Petro
Version：1.0
リリース：2005/05/04
Copyright 2005, Yale University
(翻訳：Tsubasa Sakamoto http://www.himajin2001.com/ 2010/07/01)
----
!!! 0.免責
※本章(「0.免責」)は原文には無い、本翻訳文書(以下、本文書)の翻訳者による追記です。
この翻訳文書は「CAS Protocol」(http://www.jasig.org/cas/protocol)についてのTsubasa Sakamotoの個人的な翻訳物です。
本文書によって被る一切の不利益について翻訳者はその責を負わないものとさせていただきます。
また本文書に関する問い合わせについては原文著者に行わず、Tsubasa Sakamotoに対して行うようにしてください。
原文著者は本文章に対してのサポートの責任を負いません。
但し、本文書に対してのリンクはそれを制限するものではありません。(リンクはインターネットの文化ですから:-))
リンクする場合は必ず原文へのリンクも付記して、参照者が原文へのアクセスをできるようにし、参照者の自己責任での利用を前提として下さい。
誤訳、その他不適切な表記など、翻訳に関すると思われる問題についてはTsubasa Sakamotoまでお問い合わせください。
尚、原文の文中に脚注番号があり、Appendix Cに説明のあった脚注は本文章では省略させていただきました。
!!! 1.Introduction
本文書はCAS 1.0とCAS 2.0プロトコルに関する公式仕様です。これは変更される場合があります。
!! 1.1. 慣例の定義
このドキュメント内のキーワード「MUST」と「MUST NOT」、「REQUIRED」と「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」、そして「OPTIONAL」の意味はRFC2119で定義されている意味とする。(※訳注：本文章では翻訳者の文章力不足で結構曖昧です。はい。)
* "Client"とはエンドユーザ、あるいはWebブラウザの事を指す
* "Server"とはCentral Authentication Service(CAS)サーバの事を指す
* "Service"とはClientがアクセスしようとしているアプリケーションの事を指す
* "Back-end Service"とはClientの代わりにアプリケーションにアクセスしようとするサービスを指す。"target service"を指す事もある。
* ＜LF＞はライン・フィード文字(ASCIIコード 0x0a)の事を指す
!!! 2. CAS URIs
CASは特定のURIを通してアクセスできるコンポーネントを必要とするHTTPベースのプロトコルです。このセクションでは各URIについて説明します。
!! 2.1. 認証要求としての「/login」
URI「/login」は2つの振る舞いを実行します。認証要求者(credential requestor)と認証承認者(credential acceptor)です。既に認証されている場合は認証承認を行い、そうでない場合には認証要求を行います。
Clientが既にCASによってシングル・サイン・オン(Single sign-on：以下SSO)のセッションを確立している場合、WebブラウザはCASに対してチケット認可チケット(a ticket-granting ticket)を指す文字列を含んだSecure cookieを提示します。このcookieはチケット認可クッキー(ticket-granting cookie)と呼ばれます。チケット認可チケットの内容が正しい場合、この仕様の定める他の条件を全てクリアしていれば、CASはservice ticketを発行します。
! 2.1.1. パラメータ
以下のHTTPリクエストパラメータを認証要求時に/loginに渡す事ができます。これらは全て大文字小文字を意識する必要があり(case-sensitive)、/login処理が取り扱えなくてはなりません。
::service(OPTIONAL)
:::ClientがアクセスしようとしているアプリケーションへのID。ほとんどの場合、このIDはアプリケーションのURLの事です。HTTPリクエストのパラメータとして注意するべき事として、このURL文字列はRFC1738のセクション2.2に記述されている方法に従ってURLエンコードされていなくてはなりません。もし「service」パラメータが指定されておらず、かつ未だSSOセッションが存在しない場合、CASはSSOセッションを開始する為にユーザに認証を入力されるようにするべきです。「service」パラメータが指定されておらず、しかしSSOセッションが既に存在する場合、CASは既にログイン済みである旨のメッセージをユーザに表示するべきです。
::renew(OPTIONAL)
:::このパラメータが指定されている場合、SSOはバイパスされます。CAS内のSSOセッションの有無にかかわらず、CASはclientに対して再度認証を求めます。このパラメータは「gateway」パラメータと互換性がありません。「/login」へのリダイレクトを行うServiceや「/login」へ認証情報をPOSTするformは「renew」と「gateway」両方のパラメータを同時にセットするべきではありません。その際の動作は(仕様的に)未定義となります。推奨としては、CASの実装は「nenew」がセットされている場合「gateway」パラメータを無視するべきです。「renew」パラメータをセットする場合、その値は「true」であることが推奨されます。
::gateway(OPTIONAL)
:::このパラメータが指定されている場合、CASはユーザに対して認証情報の入力を求めません。clientが既にCASによるSSOセッションを持っている場合、又は非インタラクティブな手段(例えばtrust authenticationなど)によってSSOセッションを開始できる場合、CASはclientのアクセスを「service」パラメータによって指定されているURLに有効なservice ticketを付加してリダイレクトすることができます。(またCASは、CASの認証が行われた事をclientに知らせるためのページを挟むかもしれません。) ClientがCASによるSSOセッションを持っておらず、かつ非インタラクティブな手段による認証ができなかった場合、CASはclientを「ticket」パラメータを付加せずに「service」パラメータのURLにリダイレクトします。「service」パラメータが指定されずに「gateway」パラメータが指定された場合のCASの動作は仕様的に未定義です。そのような場合、両方のパラメータが付加されていない場合と同じように認証画面を表示することが推奨されます。このパラメータは「renew」パラメータと互換性がありません。「gateway」と「renew」の両方のパラメータが同時に指定された場合の動作は仕様的に未定義です。「gateway」パラメータを指定する場合はその値を「true」とする事が推奨されます。
! 2.1.2. /loginのURLの例
シンプルなログインの例：
https://server/cas/login?service=http%3A%2F%2Fwww.service.com
username/passwordをプロンプトしない：
https://server/cas/login?service=http%3A%2F%2Fwww.service.com&gateway=true
常にusername/passwordをプロンプトする：
https://server/cas/login?service=http%3A%2F%2Fwww.service.com&renew=true
! 2.1.3. username/password認証時のレスポンス
「/login」が認証要求として使われる場合、レスポンスはどのような認証方式かに大きく依存します。ほとんどの場合、CASはusernameとpasswordを入力させる画面を表示する事になります。このフォーム画面は「username」「password」と「lt」いうパラメータを用意しなくてはなりません。また、フォーム画面は「warn」というパラメータを用意する事ができます。「/login」に対して「service」パラメータが指定されている場合、「service」は「/login」へ回される前の元のページへ渡されるはずだったフォームへのパラメータでもなくてはなりません。(※訳注：ちょっと怪しい…。原文：If "service" was specified to /login, "service" MUST also be a parameter of the form, containing the value originally passed to /login.)これらのパラメータの詳細は本書のセクション2.2.1.で説明されている。フォームは本書セクション2.2.で説明されているとおり認証承認で
扱うことのできるHTTP POSTメソッドで送信されなくてはならない。
! 2.1.4. trust authentication時のレスポンス
Trust authenticationは認証の為の基礎として要求の任意の関心(aspects)が考慮されています。Trust authenticationの適切なユーザ体験はローカルポリシーや個別の認証システム実装によって供給者毎の非常に特異なものです。(※訳注：非常にアヤシイ…けど総論的な文章なので深く考えないこと！)
「/login」がTrust authenticationの認証要求として振る舞う時、その振る舞いは受け付けている認証方式によって判別されます。認証が正しい場合、CASはユーザを透過的にServiceへリダイレクトします。あるいは、CASはclientがその認証を使う事が許可された事を警告表示する事もあります。(※訳注：心で読んで下さい。) CASの実装は認証の供給者に対して優先する振る舞いを指定できるようにしてあることを推奨します。もし認証が無効なものであったり存在しなかった場合、CASはclientに認証が失敗した理由を表示し、代替の認証手段(例えばusername/password認証)を行えるようにするべきでしょう。
! 2.1.5. SSO時のレスポンス
Clientが既にCASによってSSOセッションを確立している場合、Clientには/loginに対するるHTTPセッションcookieが与えられ、その振る舞いは本書セクション2.2.4.のようなものになります。しかし「renew」パラメータがセットされていた場合の振る舞いは本書セクション2.1.3.や2.1.4.で説明されているようなものになります。
!! 2.2. 認証承認としての「/login」
既に受け付けられている認証が「/login」に渡された場合、「/login」は認証承認として本セクションで説明されているように振る舞います。
! 2.2.1. 認証方式に共通なパラメータ
下記のHTTPリクエストパラメータを認証承認時の「/login」に渡す事ができます。これらは全て大文字小文字を意識し(case-sensitive)、「/login」によって取り扱い可能である必要があります。
::service(OPTIONAL)
:::ClientがアクセスしようとしているアプリケーションへのURL。認証承認が成功した場合CASはClientをパラメータに示されたURLへリダイレクトしなくてはなりません。詳しくは本書セクション2.2.4.を参照。
::warn(OPTIONAL)
:::このパラメータがセットされている場合、SSOは透過的であってはなりません。Clientには他のサービスへの認証を試みる前に、その旨の注意が表示されなくてはなりません。
! 2.2.2. username/password認証のパラメータ
username/password認証が行われる際は、セクション2.2.1.で記述されているパラメータに加えて、以下のHTTPリクエストパラメータが「/login」へ与えられなくてはなりません。これらは全て大文字小文字を意識します(case-sensitive)。
::username(必須)
:::ログインしようとしているclientのusername
::password(必須)
:::ログインしようとしているclientのpassword
::lt(必須)
:::ログインチケット。これはセクション2.1.3.で説明されているログインフォーム画面へ提供されているものです。ログインチケット自体の説明はセクション3.5.を参照。
! 2.2.3. Trust authenticationのパラメータ
Trust authenticationの為の必須のHTTPパラメータはありません。Trust authenticationはHTTPリクエストの様々な側面を元にしています。
! 2.2.4. レスポンス
認証承認として振る舞う「/login」は以下のうち一つのレスポンスを返さなくてはなりません。
::ログイン成功時
:::Clientを「service」パラメータで指定されたURLへ、そのサービスへの認証が行われた状態でリダイレクトします。リダイレクトはServiceへのClientのHTTP GETメソッドとして行われます。Serviceへのリクエストには正当なService ticketがHTTPリクエストパラメータ「ticket」として含まれます。詳細はAppendix Bを参照。「service」が指定されていない場合、CASはclientに対してSSOセッションの開始が成功した旨のメッセージを表示する必要があります。
::ログイン失敗時
:::認証要求としての「/login」へ戻ります。このような場合、CASはClientに対してログイン失敗の理由(パスワード間違い、アカウントがロックされている、等)を表示し、可能であればログインをやり直す機会を与える事を推奨します。
!! 2.3. /logout
「/logout」はclientに対するCASのSSOセッションを破棄します。ticket-granting cookie(セクション3.6.参照)は破棄され、後続の「/login」へのアクセスはユーザがログインするまで(そして新しいSSOセッションを開始するまで)Service ticketを持たない状態で行われます。
! 2.3.1. パラメータ
「/logout」には下記のHTTPリクエストパラメータを付ける事ができます。Case-sensitiveで、「/logout」が扱えるべきです。
::url(OPTIONAL)
:::「url」パラメータが指定されている場合、パラメータの指すURLは説明文などを伴ったログアウトページとして使われます。例えば、「ログアウトしたアプリケーションへ再度ログインする場合はここ(http://www.example.com/)をクリック」など。
! 2.3.2. レスポンス
「/logout」はユーザが既にログアウトされた旨のメッセージで始まるべきです。「url」パラメータが指定されている場合、「/logout」はセクション2.3.1.で説明されているように、指定されたURLへのリンクを表示するべきです。
! 2.4. /validate (CAS 1.0)
「/validate」はservice ticketを検証します。「/validate」はCAS 1.0の仕様の一部であり、従って代理認証(proxy authentication)をサポートしません。CASは「/validate」に対してproxy ticketが渡された場合、チケット検証失敗を返さなくてはなりません。
!! 2.4.1. パラメータ
以下のHTTPリクエストパラメータが「/validate」に対して規定されています。Case-sensitiveで、「/validate」が扱えるべきです。
::service(必須)
:::チケットが発行されたService。(セクション2.2.1.参照)
::ticket(必須)
:::「/login」によって発行されたService ticket。(セクション3.1.参照)
::renew(OPTIONAL)
:::このパラメータがセットされている場合、Service ticketがユーザのプライマリ認証(from the presentation of the user's primary credentials)から発行されている時だけ検証が成功となります。SSOセッションのチケットであった場合、検証は失敗します。
! 2.4.2. レスポンス
「/validate」は以下の2つのレスポンスのうちの1つを返します。
チケット検証成功の場合：
yes＜LF＞
username＜LF＞
チケット検証失敗の場合：
no＜LF＞
＜LF＞
! 2.4.3. /validateのURL例
チケット検証の例：
https://server/cas/validate?service=http%3A%2F%2Fwww.service.com&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7
チケットがプライマリ認証のものである事を確認する場合：
https://server/cas/validate?service=http%3A%2F%2Fwww.service.com&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&renew=true
!! 2.5. /serviceValidate (CAS 2.0)
「/serviceValidate」はXML片(XML-fragment)を返す事によってService ticketの有効性を検証する事ができます。「/serviceValidate」は要求された場合に代理許可チケット(proxy-granting tickets)を作成・発行できなくてはなりません。「/serviceValidate」はproxy ticketを受け取った場合に検証成功の応答を返してはいけません。「/serviceValidate」がproxy ticketを渡された場合、XML応答内のエラーメッセージに「/serviceValidate」が受け取ったチケットがproxy ticketだった事を説明する内容を出力する事を推奨します。
! 2.5.1. パラメータ
「/serviceValidate」には以下のHTTPリクエストパラメータをセットする事ができます。Case-sensitiveで、「/serviceValidate」が扱えるべきです。
::service(必須)
:::チケットが発行されたServiceを示す。(セクション2.2.1.を参照)
::ticket(必須)
:::「/login」によって発行されたService ticket。Service ticketの説明はセクション3.1.を参照。
::pgtUrl(OPTIONAL)
:::proxy callbackのURL。セクション2.5.4.を参照。
::renew(OPTIONAL)
:::このパラメータがセットされている場合、Service ticketがユーザのプライマリ認証(from the presentation of the user's primary credentials)から発行されている時だけ検証が成功となります。SSOセッションのチケットであった場合、検証は失敗します。
! 2.5.2. レスポンス
「/serviceValidate」はAppendix Aに記載されているXML schemaで定義されたXML片の<cas:serviceResponse>を返します。
下記に例を示します。
チケット検証成功：
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationSuccess>
<cas:user>username</cas:user>
<cas:proxyGrantingTicket>PGTIOU-84678-8a9d...
</cas:proxyGrantingTicket>
</cas:authenticationSuccess>
</cas:serviceResponse>
チケット検証失敗：
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationFailure code="INVALID_TICKET">
Ticket ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 not recognized
</cas:authenticationFailure>
</cas:serviceResponse>
! 2.5.3. エラーコード
認証(検証)失敗レスポンス内の「code」属性で下記の値が使われます。下記はCASの実装が最低限サポートしなくてはならないエラーコードのセットです。他の値を加える事もできます。
* '''INVALID_REQUEST''' --- 不足しているリクエストパラメータがある
* '''INVALID_TICKET''' --- 渡されたチケットは有効なものではない、又はチケットが初期のログイン(a initial login)からのものではなく、検証の「renew」パラメータがセットされている。レスポンスのXML片の<cas:authenticationFailure>のbodyに詳細な説明が記載されている。
* '''INVALID_SERVICE''' --- 渡されたチケットは有効だが指定された「service」がチケットに紐付けられたサービスとマッチしない。CASはチケットを無効化し、同じチケットに対する以降の検証に検証失敗を返さなくてはならない。
* '''INTERNAL_ERROR''' --- チケット検証において内部的なエラーが発生した。
全てのエラーコードについて、CASは詳細なメッセージをXMLレスポンスの<cas:authenticationFailure>ブロックに出力する事が推奨される。
! 2.5.4. proxy callback
Serviceがback-end serviceに対してclientの認証を代行させたい場合、代理許可チケット(proxy-granting tickets)が獲得されなくてはなりません。このチケットの獲得はproxy callback URLを通して行われます。この時のURLはclientの認証を代行するユニークでかつ安全なback-end Serviceを表します。Back-end Serviceは認証を受け入れるかどうかをback-end Service上の認証用callback URL上で判定する事ができます。
proxy callbackは以下のような仕組みで行われます。
+ proxy-granting ticketsをリクエストするServiceは、初期のService ticket(initial service ticket)又はproxy ticketの検証を検証する為の「/serviceValidate」(又は「proxyValidate」)のHTTPリクエストパラメータ「pgtUrl」を特定します。これはCASが検証する為に接続しようとするServiceのcallback URLです。このURLはHTTPSでなくてはならず、CASはSSL certificateが正しい事とServiceの名前がマッチする事の両方を確認しなくてはなりません。SSL certificateが失敗した場合proxy-granting ticketsは発行されず、セクション2.5.2.で示すCASのサービスレスポンスは<proxyGrantingTicket>ブロックを含みません。この時点でproxy-granting ticketsの発行作業は中断しますがService ticket検証作業は継続し、適切に「成功」「失敗」を返します。SSL certificateが成功した場合、proxy-granting ticketsの発行は次のステップに進みます。
+ CASはHTTPのGETメソッドをを使い、HTTPリクエストパラメータの「pgtId」と「pgtIou」をpgUrlに渡します。これらのパラメータについてはセクション3.3.と3.4.で説明します。
+ HTTP GETがステータスコード200(OK)を返してきた場合、CASは「/serviceValidate」(又は「proxyValidate」)にセクション2.5.2.で説明するproxy-granting ticketsIOU(セクション3.4.)を<cas:proxyGrantingTicket>ブロックに含むサービスレスポンスで応答します。HTTP GETが別のステータスコードを返してきた場合、HTTP 3xxリダイレクト以外の場合、CASは「/serviceValidate」(又は「proxyValidate」)に<cas:proxyGrantingTicket>を含まない形で応答します。CASはpgtUrlによって示されたHTTPリダイレクトに従うかもしれません。しかしながら、検証時に<proxy>ブロック内に提供された認証callback URLは、最初に「/serviceValidate」(又は「/proxyValidate」)に渡された「pgtUrl」パラメータのURLと同じでなくてはなりません。
+ CASレスポンス内にproxy-granting ticketsIOUを受け取った、そしてproxy-granting ticketsとproxy-granting ticketsIOUの両方をproxy callbackから受け取ったサービスは、proxy-granting ticketsIOUをproxy-granting ticketsと検証結果に結びつけます。Serviceはproxy ticketの獲得(セクション2.7.参照)にproxy-granting ticketsを使用します。
! 2.5.5. 「/serviceValidate」のURL例
シンプルな検証の例：
https://server/cas/serviceValidate?service=http%3A%2F%2Fwww.service.com&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7
service ticketがプライマリ認証によって発行されたものであることを確認する：
https://server/cas/serviceValidate?service=http%3A%2F%2Fwww.service.com&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&renew=true
proxyの為にcallback URLを渡す場合：
https://server/cas/serviceValidate?service=http%3A%2F%2Fwww.service.com&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&pgtUrl=https://my-server/myProxyCallback
!! 2.6. /proxyValidate (CAS 2.0)
「/proxyValidate」は「/serviceValidate」と同じ内容に加え、proxy ticketも検証します。
「/proxyValidate」はService ticketとProxy ticketの両方を検証する事ができます。
! 2.6.1. パラメータ
「/proxyValidate」は「/serviceValidate」と同じパラメータを使用できます。セクション2.5.1.を参照。
! 2.6.2. レスポンス
「/proxyValidate」はAppendix Aに記載されているXML schemaで定義されたXML片のCAS serviceResponseを返します。
下記に例を示します。
チケット検証に成功した場合：
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationSuccess>
<cas:user>username</cas:user>
<cas:proxyGrantingTicket>PGTIOU-84678-8a9d...</cas:proxyGrantingTicket>
<cas:proxies>
<cas:proxy>https://proxy2/pgtUrl</cas:proxy>
<cas:proxy>https://proxy1/pgtUrl</cas:proxy>
</cas:proxies>
</cas:authenticationSuccess>
</cas:serviceResponse>
注意する点は、複数のproxyを通して認証が行われる場合、proxyを渡り歩いた順番は<cas:proxies>ブロック内に反映されなくてはならないという事です。もっとも最近に利用したproxyは最初にリストされなくてはならず、新しいproxyが追加された場合他のproxyは順番に下げられて行かなければならない(shifted down)。上記の例の場合、「https://proxy1/pgtUrl」で示されるサービスが最初に利用され、そのサービスがさらに「https://proxy2/pgtUrl」であらわされるサービスに認証を依頼している。
チケット検証に失敗した場合：
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationFailure code="INVALID_TICKET">
ticket PT-1856376-1HMgO86Z2ZKeByc5XdYD not recognized
</cas:authenticationFailure>
</cas:serviceResponse>
! 2.6.3. 「/proxyValidate」のURL例
「/proxyValidate」のURLは「/serviceValidate」と同じパラメータを取る為、「/serviceValidate」を「/proxyValidate」に読み替えてセクション2.5.5.を参照。
!! 2.7. /proxy (CAS 2.0)
「/proxy」はproxy-granting ticketsとback-end serviceへ委譲された認証からproxy ticket提供する。
! 2.7.1. パラメータ
「/proxy」では下記の2つのパラメータが必須です。両方ともCase-sensitiveです。
::pgt(必須)
:::ServiceによりService ticketやproxy ticketの検証で発行されたproxy-granting tickets。
::targetService(必須)
:::Back-end serviceの識別子。注意するべき点は、全てのback-end serviceがWeb Serviceとは限らず、従ってtargetServiceが必ずしもURLとは限らないという事です。しかしながら、ここで指定されたサービス識別子はproxy ticketの検証である「/proxyValidate」などに指定された「service」パラメータと同じ値である必要があります。
! 2.7.2. レスポンス
「/proxy」はAppendix Aに記載されているXML schemaで定義されたXML片のCAS serviceResponseを返します。
下記に例を示します。
リクエスト成功時：
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:proxySuccess>
<cas:proxyTicket>PT-1856392-b98xZrQN4p90ASrw96c8</cas:proxyTicket>
</cas:proxySuccess>
</cas:serviceResponse>
リクエスト失敗時：
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:proxyFailure code="INVALID_REQUEST">
'pgt' and 'targetService' parameters are both required
</cas:proxyFailure>
</cas:serviceResponse>
! 2.7.3. エラーコード
下記の値が認証失敗時の「code」値としてレスポンス内で使われます。以下はCASサーバが最低限サポートするべきものです。実装では他のものも含まれるかもしれません。
* '''INVALID_REQUEST''' --- 必須のパラメータが全て揃っていない
* '''BAD_PGT''' --- 送られた「pgt」パラメータが正しくない
* '''INTERNAL_ERROR''' --- チケット検証において内部的なエラーが発生した
全てのエラーコードにおいて、XMLレスポンスの<cas:authenticationFailure>のボディー部にエラーの詳細を出力する事がCASサーバの実装に推奨されます。
! 2.7.4. 「/proxy」のURL例
単純な/proxyの要求：
https://server/cas/proxy?targetService=http%3A%2F%2Fwww.service.com&pgt=PGT-490649-W81Y9Sa2vTM7hda7xNTkezTbVge4CUsybAr
!!! 3. CASエンティティ
!! 3.1. service ticket
service ticketとは、clientによってServiceへのアクセスの認証に使われる不透明な(opaque)文字列の事です。service ticketはセクション2.2.で説明されているとおり、「/login」に対してclientが認証情報の提示とサービス識別子を与える事によってCASから発行されます。
! 3.1.1. service ticketの性質
* service ticketは、そのservice ticketが発行された「/login」時に指定されたサービス識別子に対してのみ有効です。サービス識別子はservice ticketの一部であるべきではありません。
* service ticketは只1回のチケット検証の間しか有効であってはいけません。検証の成功、失敗に関わらず、CASはその後そのservice ticketを無効としなくてはなりません。その後に試みられる同じチケットに対する検証を全て失敗とするためです。
* CASはservice ticketが発行された後適切な時間を置いて、検証されていないservice ticketを破棄(expire)するべきです。サービスに破棄されたチケットが提示された場合、CASはservice ticketの検証失敗のレスポンスを返さなくてはなりません。検証結果のレスポンスには検証失敗の説明的な理由が含まれる事が推奨されています。service ticketが破棄されるまでの有効である期間は5分以内である事が推奨されます。検証前のservice ticketの破棄までの時間はローカルなセキュリティー要件とCASの使われ方によって決めるべきです。
* service ticketは十分に推測不能で安全なランダム文字列を含まなくてはなりません。
* service ticketの文字列は必ず「ST-」から始まります。
* back-end serviceは最長32文字のservice ticketを受け入れる事ができなくてはなりません。back-end serviceは256文字までのservice ticketを受け入れられる事が勧められます。
!! 3.2. proxy ticket
proxy ticketとはclientの代わりにServiceがback-end serviceにアクセスする際に認証として使われる不透明な文字列です。proxy ticketはServiceが有効なproxy-granting tickets提示する事によってCASから得られ(セクション3.3.参照)、接続しようとするback-end serviceへのServiceの認証情報となります。
! 3.2.1. proxy ticketの性質
* proxy ticketは生成された時に指定されたサービス識別子に対してのみ有効である。サービス識別子はproxy ticketの一部であるべきではない。
* proxy ticketは只1度の検証(validation)までの間だけ有効ではければならない。検証の成功、失敗に関わらず、CASはそのチケットを無効化(invalidate)しなくてはならない。これは同じチケットに対する今後の検証を全て失敗させるためである。
* CASは未検証のチケットを発行から適切な時間経過までの間に破棄(expire)することが望ましい。Serviceが(CASに対して)破棄されたproxy ticketを検証しようとした場合、CASは検証失敗のレスポンスを返さなくてはならない。CASから返される検証失敗のレスポンスの中になぜ検証が失敗したかの叙述的説明があるのが望ましい。また、チケットが発行されてから未検証で破棄されるまでの時間は5分以内が望ましい。検証前のproxy ticketの破棄までの時間はローカルなセキュリティー要件とCASの使われ方によって決めるべきです。
* proxy ticketは十分に推測不能で安全なランダム文字列を含まなくてはなりません。
* proxy ticketは「PT-」で始まるべきです。少なくともproxy ticketは「PT-」か「ST-」で始まらなくてはなりません。
* back-end serviceは最長32文字のproxy ticketを受け入れる事ができなくてはなりません。back-end serviceは256文字までのproxy ticketを受け入れられる事が勧められます。
!! 3.3. proxy-granting ticket
proxy-granting ticketはclientに代わってback-end serviceへのアクセスをserviceが得るためのproxy ticketを得るために使用される不透明な文字列です。proxy-granting ticketはservice ticketかproxy ticketが検証(validation)される事によってCASから与えられます。proxy-granting ticketの発行については本文書のセクション2.5.4.を参照。
! 3.3.1. proxy-granting ticketの性質
* proxy-granting ticketはserviceが複数のproxy ticketを取得する為に使われます。proxy-granting ticketは使い捨て(one-time-use)のticketではありません。
* proxy-granting ticketは認証が委譲されたclientがCASからlogoutした時に破棄(expire)されなくてはなりません。
* proxy-granting ticketは十分に推測不能で安全なランダム文字列を含まなくてはなりません。
* proxy-granting ticketは「PGT-」から始まる事が推奨されます。
* serviceは最長64文字のproxy-granting ticketを受け入れる事ができなくてはなりません。serviceは256文字までのproxy-granting ticketを受け入れられる事が勧められます。
!! 3.4. proxy-granting ticket IOU
(※訳注：「IOU」とは借用書の事のようです。つまりproxy-granting ticketの借用書の事です。)
proxy-granting ticket IOUは 「/serviceValidate」と「/proxyValidate」のレスポンスによって提供される、適切なproxy-granting ticketとservice ticketやproxy ticketを結び付ける為の不透明な文字列です。詳細な説明についてはセクション2.5.4.を参照。
! 3.4.1. proxy-granting ticket IOUの性質
* proxy-granting ticket IOUは紐付けられているproxy-granting ticketのいかなる参照も含むべきではありません。proxy-granting ticket IOU文字列そのものを有意な時間内にアルゴリズム的解析によって結びつけられているproxy-granting ticketを導き出すことができてはいけません。
* proxy-granting ticket IOUは十分に推測不能で、有意な時間内にbrute-force attackで解析されないような安全なランダム文字列を含まなくてはなりません。
* proxy-granting ticket IOUは「PGTIOU-」から始まる事が推奨されます。
* serviceは最長64文字のproxy-granting ticket IOUを受け入れる事ができなくてはなりません。serviceは256文字までのproxy-granting ticket IOUを受け入れられる事が勧められます。
!! 3.5. login ticket
login ticketはusername/password認証時に、認証要求者としての「/login」によって提供され、また認証承認者としての「/login」に提供される文字列です。login ticketの目的はwebブラウザのバグによる認証の再実行に対応する事です。
! 3.5.1. login ticketの性質
* login ticketは「/login」によって提供される、確率的に非常に一意的(probabilistically unique)な文字列でなくてはなりません。
* login ticketは1度の認証の間だけ有効でなくてはなりません。認証自体の成功、失敗にかかわらず、CASはそのlogin ticketを無効化しなくてはなりません。これは同一のlogin ticketによる今後の認証を全て失敗とさせるためです。
* login ticketは「LT-」から始める事が推奨されます。
!! 3.6. ticket-granting cookie
ticket-granting cookieはSSOセッション確立時にCASによって与えられるHTTP cookieです。このcookieはclientをログイン状態を保ち、それが有効な間、clientはそれを本来の認証の代わりとしてCASに示す事ができます。Serviceはセクション2.1.1.、2.4.1.、2.5.1.で説明されている「renew」パラメータを使ってSSOから手を引く事(can opt out of)ができます。(※訳注：多分、renewによってcookieを作り直すことができるってことだと思う。)
! 3.6.1. ticket-granting cookieの性質
* ticket-granting cookieはclientのブラウザセッションの終わりに破棄されるようにセットされていなくてはならない。
* CASはcookieのpathを可能な限り限定的にセットしなくてはならない。例えば、CASが「/cas」というpathに設置されている場合、cookieのpathも「/cas」にセットされていなくてはならない。
* ticket-granting cookieの値は推測不能で有意な時間に解読できないよう、ランダムで安全なデータを含んでいなくてはならない。
* ticket-granting cookieは「TGC-」から始める事が推奨されます。
!! 3.7. ticketやticket-granting cookieの使用文字
これまでの要件に加えて、CASの全てのticketやticket-granting cookieの値は「A-Z」「a-z」「0-9」と「?-'」だけで構成されていなくてはならない。
!!! Appendix A：CAS response XML schema
<!--
The following is the schema for the Yale Central Authentication
Service (CAS) version 2.0 protocol response. This covers the responses
for the following servlets:
/serviceValidate
/proxyValidate
/proxy
This specification is subject to change.
Author: Drew Mazurek
Version: $Id: cas2.xsd,v 1.1 2005/02/14 16:19:06 dmazurek Exp $
-->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:cas="http://www.yale.edu/tp/cas"
targetNamespace="http://www.yale.edu/tp/cas"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="serviceResponse" type="cas:ServiceResponseType"/>
<xs:complexType name="ServiceResponseType">
<xs:choice>
<xs:element name="authenticationSuccess" type="cas:AuthenticationSuccessType"/>
<xs:element name="authenticationFailure" type="cas:AuthenticationFailureType"/>
<xs:element name="proxySuccess" type="cas:ProxySuccessType"/>
<xs:element name="proxyFailure" type="cas:ProxyFailureType"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="AuthenticationSuccessType">
<xs:sequence>
<xs:element name="user" type="xs:string"/>
<xs:element name="proxyGrantingTicket" type="xs:string" minOccurs="0"/>
<xs:element name="proxies" type="cas:ProxiesType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ProxiesType">
<xs:sequence>
<xs:element name="proxy" type="xs:string" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AuthenticationFailureType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="code" type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="ProxySuccessType">
<xs:sequence>
<xs:element name="proxyTicket" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ProxyFailureType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="code" type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
!!! Appendix B：安全なリダイレクト
login成功後、clientをCASから最終的な目的地(Service)まで安全にリダイレクトする為に十分注意してください。ほとんどの場合、clientはCASに認証情報を送信するのにPOSTリクエストを使用します。本仕様によると、次にCASはclientをGETリクエストでアプリケーションにフォワードします。
HTTP/1.1のRFCによってレスポンスコード「303:See other」が提供されており、POSTによってデータを受け取ったスクリプトは303によるリダイレクトによって、GETリクエストによってブラウザを他のURLにフォワードできる事を期待しています。しかしながら、全てのブラウザがこの通り正しく実装されているわけではありません。
推奨されるリダイレクトの手順はJavaScriptを通したものです。ページが「window.localtion.href」を下記のように含んでいれば十分な動作をします。
<html>
<head>
<title>Yale Central Authentication Service</title>
<script>
window.location.href="https://portal.yale.edu/Login?ticket=ST-..." mce_href="https://portal.yale.edu/Login?ticket=ST-...";
</script>
</head>
<body>
<noscript>
<p>CAS login successful.</p>
<p> Click <a xhref="https://portal.yale.edu/Login?ticket=ST-..." mce_href="https://portal.yale.edu/Login?ticket=ST-...">here</a>
to access the service you requested.<br /> </p>
</noscropt>
</body>
</html>
加えて、CASは下記のブラウザキャッシュ関係のヘッダをセットし、ブラウザのキャッシュを禁止するべきです。
* Pragma: no-cache
* Cache-Control: no-store
* Expires: (RFC 1123に定義されている、今か今以前の値)
login ticketの導入により、ブラウザによってキャッシュされ再実行された認証が再実行される可能性を取り除きました。しかし、古いバージョンのApple Safariにはバグがあり、「戻る」ボタンにより、アクセスしようとしているServiceにClientが認証情報を再送信してしまうことを強制しています。CASはこのような振る舞いをブラウザが古いバージョンのSafariだった場合に自動的にリダイレクトを停止する事によって防ぐ事ができるようにするべきです。または、CASはログインが成功した旨のメッセージページを表示し、そのページ内にServiceへのリンクを入れるようにするべきです。その場合clientは手動でリンクをクリックして先に進みます。
!!! Appendix C：脚注
(※訳注：本翻訳文章では文中の脚注を省略した為、本章も省略)
!!! Appendix D：CAS License
Copyright (c) 2000-2005 Yale University. All rights reserved.
THIS SOFTWARE IS PROVIDED "AS IS," AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ARE EXPRESSLY DISCLAIMED. IN NO EVENT SHALL YALE UNIVERSITY OR ITS EMPLOYEES BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED, THE COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH DAMAGE.
(※超訳：このソフトウェアはあくまでも「配布されているそのまま」で提供されています。保障も何もしません。このソフトウェアを使用する事によるいかなる損害とうについてイエール大学も教員も一切責任を放棄します。)
Redistribution and use of this software in source or binary forms, with or without modification, are permitted, provided that the following conditions are met:
(※超訳：再配布と利用は、ソースであろうとバイナリであろうと、改変の有無にかかわらず、許可されます。下記の条件に合致する限りにおいて。)
+ Any redistribution must include the above copyright notice and disclaimer and this list of conditions in any related documentation and, if feasible, in the redistributed software.(いかなる再配布物であっても関連するドキュメントに上記の著作権表示と免責とこの許可条件を添付する事。可能であれば再配布されるソフトウェアにも。)
+ Any redistribution must include the acknowledgment, "This product includes software developed by Yale University," in any related documentation and, if feasible, in the redistributed software.(いかなる再配布物にも関連するドキュメントに「この製品はイエール大学が作ったソフトウェアを含んでいます。」と注記すること。可能であれば再配布されるソフトウェアにも。)
+ The names "Yale" and "Yale University" must not be used to endorse or promote products derived from this software.(このソフトウェアから派生したソフトウェアを宣伝するのに「イエール(Yale)」「イエール大学(Yale University)」の名称を使用しない事。)
!!! Appendix E：このドキュメントの履歴
*2005年5月4日：v1.0 --- (原文)初版リリース
*(2010年7月1日：v1.0 --- (翻訳)初版公開)
----
'''ツッコミ：'''
::Test, just a test - XRumerTest (2012年07月09日 00時25分18秒)
::: Hello. And Bye.