!!!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片のを返します。 下記に例を示します。 チケット検証成功： username PGTIOU-84678-8a9d... チケット検証失敗： Ticket ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 not recognized ! 2.5.3. エラーコード 認証(検証)失敗レスポンス内の「code」属性で下記の値が使われます。下記はCASの実装が最低限サポートしなくてはならないエラーコードのセットです。他の値を加える事もできます。 * '''INVALID_REQUEST''' --- 不足しているリクエストパラメータがある * '''INVALID_TICKET''' --- 渡されたチケットは有効なものではない、又はチケットが初期のログイン(a initial login)からのものではなく、検証の「renew」パラメータがセットされている。レスポンスのXML片ののbodyに詳細な説明が記載されている。 * '''INVALID_SERVICE''' --- 渡されたチケットは有効だが指定された「service」がチケットに紐付けられたサービスとマッチしない。CASはチケットを無効化し、同じチケットに対する以降の検証に検証失敗を返さなくてはならない。 * '''INTERNAL_ERROR''' --- チケット検証において内部的なエラーが発生した。 全てのエラーコードについて、CASは詳細なメッセージをXMLレスポンスのブロックに出力する事が推奨される。 ! 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のサービスレスポンスはブロックを含みません。この時点で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.)をブロックに含むサービスレスポンスで応答します。HTTP GETが別のステータスコードを返してきた場合、HTTP 3xxリダイレクト以外の場合、CASは「/serviceValidate」(又は「proxyValidate」)にを含まない形で応答します。CASはpgtUrlによって示されたHTTPリダイレクトに従うかもしれません。しかしながら、検証時にブロック内に提供された認証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を返します。 下記に例を示します。 チケット検証に成功した場合： username PGTIOU-84678-8a9d... https://proxy2/pgtUrl https://proxy1/pgtUrl 注意する点は、複数のproxyを通して認証が行われる場合、proxyを渡り歩いた順番はブロック内に反映されなくてはならないという事です。もっとも最近に利用したproxyは最初にリストされなくてはならず、新しいproxyが追加された場合他のproxyは順番に下げられて行かなければならない(shifted down)。上記の例の場合、「https://proxy1/pgtUrl」で示されるサービスが最初に利用され、そのサービスがさらに「https://proxy2/pgtUrl」であらわされるサービスに認証を依頼している。 チケット検証に失敗した場合： ticket PT-1856376-1HMgO86Z2ZKeByc5XdYD not recognized ! 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を返します。 下記に例を示します。 リクエスト成功時： PT-1856392-b98xZrQN4p90ASrw96c8 リクエスト失敗時： 'pgt' and 'targetService' parameters are both required ! 2.7.3. エラーコード 下記の値が認証失敗時の「code」値としてレスポンス内で使われます。以下はCASサーバが最低限サポートするべきものです。実装では他のものも含まれるかもしれません。 * '''INVALID_REQUEST''' --- 必須のパラメータが全て揃っていない * '''BAD_PGT''' --- 送られた「pgt」パラメータが正しくない * '''INTERNAL_ERROR''' --- チケット検証において内部的なエラーが発生した 全てのエラーコードにおいて、XMLレスポンスののボディー部にエラーの詳細を出力する事が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 !!! 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」を下記のように含んでいれば十分な動作をします。 Yale Central Authentication Service