此文是根據(jù)cas的原始文檔翻譯補充

1、此文是根據(jù)cas的原始文檔翻譯補充。其中，“約定和定義”中的單詞在譯文中沒有翻譯，導(dǎo)致譯文在這些地方不太通順。請參照原文理解。原文地址如下： HYPERLINK /cas/protocol /cas/protocol 。在這篇文檔后面附上英文原文，供參考。注意：不影響對協(xié)議理解的部分沒有翻譯。Author: HYPERLINK mailto:drew.mazurek Drew MazurekContributors: HYPERLINK mailto:susan.bramhall Susan Bramhall HYPERLINK mailto:howard.gilbert Howard Gil

2、bert HYPERLINK mailto:newman-andy Andy Newman HYPERLINK mailto:andrew.petro Andrew PetroVersion: 1.0Release Date: May 4, 2005Copyright 2005, Yale University1. 簡介This is the official specification of the CAS 1.0 and 2.0 protocols. It is subject to change.1.1. 約定和定義這篇文檔中的關(guān)鍵字 MUST, MUST NOT, REQUIRED,

3、SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, 和 OPTIONAL參照 RFC 2119 HYPERLINK /products/cas/protocol.html l 1 1的解釋.Client 指終端用戶，或者瀏覽器.Server 指 Central Authentication Service 的服務(wù)器.Service 指“client”嘗試訪問的應(yīng)用程序.Back-end service指“service”以”client”身份訪問的應(yīng)用程序. 或者稱之為target service. 指換行符(ASCII 碼為 0 x

4、0a).2. CAS URIsCAS 是基于 HTTP HYPERLINK /products/cas/protocol.html l 2 2, HYPERLINK /products/cas/protocol.html l 3 3協(xié)議的，要求每個組件都能夠通過特定的URI訪問。這一節(jié)將討論每一個URI。2.1. /login 作為憑證請求者時/login URI 扮演兩個角色：憑證請求者以及憑證接收者。如果Client已經(jīng)與CAS建立了一個單點登錄的session，瀏覽器將向CAS服務(wù)器提供一個安全cookie，包含確定ticket-granting ticket(TGT)的字符串。這個co

5、okie被稱為ticket-granting cookie(TGC)。如果ticket-granting cookie對應(yīng)一個合法的ticket-granting ticket，CAS會給出一個service ticket(ST)，當(dāng)其他條件都滿足的時候。關(guān)于service-granting cookies的更多信息，參見Section 3.6。2.1.1. 參數(shù)當(dāng)作為憑證請求者時，下面這些參數(shù)可以傳遞給/login URI，而且他們”MUST”被/login處理。service Optional client正在訪問的應(yīng)用的標(biāo)識。幾乎所有情況下，這會是應(yīng)用的URL.請注意，當(dāng)作為HTTP的請

6、求參數(shù)時，這個URL” MUST”被 URL-encoded，按照 Section 2.2 中提到的RFC 1738 HYPERLINK /products/cas/protocol.html l 4 4的規(guī)則. 如果沒有指定service，并且單點登錄的session不存在， CAS “SHOULD”要求用戶提供憑證上，建立單點登錄session. 如果沒有指定service并且單點登錄service已經(jīng)存在，CAS “SHOULD”顯示一個信息，提醒用戶已經(jīng)登錄了。renew Optional 如果指定了這個參數(shù)，單點登錄會被忽略。這種情況下，不論是否已經(jīng)存在單點登錄session，CAS

7、 都會要求client提供憑證。這個參數(shù)與gateway參數(shù)不兼容。訪問/login URI時，“SHOULD NOT”同時設(shè)置renew和gateway參數(shù)。同時設(shè)置這兩個參數(shù)時的行為沒有定義?！癛ECOMMENDED” 當(dāng)指定了renew參數(shù)時，CAS 在執(zhí)行時忽略gateway參數(shù)。“RECOMMENDED”當(dāng)指定renew參數(shù)時，指定其值為“true”.gateway Optional 如果指定了這個參數(shù), CAS不會要求client提供憑證.如果 client 已經(jīng)建立了單點登錄session, 或者如果單點登錄session可以通過非互動的方式建立(比如trust authenti

8、cation), CAS “MAY”重定向client到service參數(shù)指定的URL，并附帶上合法的service ticket。(CAS 同時“MAY”給client提供一個建議頁面，通知client CAS認(rèn)證已經(jīng)完成.) 如果client沒有建立單點登錄session，同時非互動認(rèn)證不能建立, CAS “MUST”重定向client到service參數(shù)指定的URL，但不會附帶ticket參數(shù). 如果沒有指定“service”參數(shù)，但是指定了gateway參數(shù)，CAS的動作未定義“RECOMMENDED” 這種情況下， 如果沒有指定其他參數(shù)，CAS要求credentials.這個參數(shù)和r

9、enew參數(shù)不兼容，兩者都指定時的動作未定義?！癛ECOMMENDED”當(dāng)指定gateway參數(shù)時，設(shè)置其值為“true”.2.1.2. 調(diào)用 /login 的URL實例簡單的登錄URL: HYPERLINK /cas/login?service=http%3A%2F%2F o /cas/login?service=http%3A%2F%2F https:/server/cas/login?service=http%3A%2F%2F不向用戶要求用戶名和密碼： HYPERLINK /cas/login?service=http%3A%2F%2F&gateway=true o /cas/login

10、?service=http%3A%2F%2F&gateway=true https:/server/cas/login?service=http%3A%2F%2F&gateway=true總是要求用戶提供用戶名和密碼： HYPERLINK /cas/login?service=http%3A%2F%2F&renew=true o /cas/login?service=http%3A%2F%2F&renew=true https:/server/cas/login?service=http%3A%2F%2F&renew=true2.1.3. 用戶名/密碼方式認(rèn)證時的服務(wù)器回應(yīng)當(dāng) /login 作

11、為憑證請求者時，服務(wù)器回應(yīng)根據(jù)請求的憑證類型的不同，差別比較大。多數(shù)情況下，CAS 會顯示出一個登錄界面，要求輸入用戶名和密碼。這個頁面“MUST”包含一個表單，單單中有參數(shù)： username, password, 和 lt。這個表單“MAY”包含warn參數(shù). 如果指定了service參數(shù)，則service MUST出現(xiàn)在表單中，其值應(yīng)該是最初傳遞給/login的值。 這些參數(shù)會在Section 2.2.1中詳細(xì)說明. 表單MUST通過HTTP POST的方式提交到/login，此時/login作為憑證接收者，將在Section 2.2中詳細(xì)討論。2.1.4. “trust”認(rèn)證時的服務(wù)器

12、回應(yīng)“Trust”認(rèn)證采用客戶端瀏覽器的request作為認(rèn)證的基礎(chǔ)?？紤]到本地策略以及執(zhí)行的特定認(rèn)證機制的邏輯，“Trust”認(rèn)證的用戶體驗與特定的部署高度相關(guān)，當(dāng) /login 作為憑證請求者時，它的行為取決于它收到的憑證類型。如果憑證是合法的， CAS MAY 直接重定向用戶到應(yīng)用?；蛘逤AS MAY顯示一條信息，說明憑證已提供，并讓client確認(rèn)它愿意使用這些憑證。RECOMMENDED CAS 執(zhí)行時允許部署者選擇最佳的行為。如果憑證不合法或不存在，“RECOMMENDED” CAS顯示給client認(rèn)證失敗的原因，或者讓用戶選擇另一種認(rèn)證方式(例如用戶名/密碼認(rèn)證).2.1.5.

13、 單點登錄認(rèn)證時的回應(yīng)如果client已經(jīng)建立單點登錄session，client會向 /login提供 TGC，服務(wù)器的行為如Section 2.2.4所述?？墒侨绻O(shè)置了renew參數(shù)，服務(wù)器的行為將如Section 2.1.3或2.1.4所述。2.2. /login作為憑證接收者當(dāng)可接受的憑證提供給/login，/login將作為憑證接收者，它的行為將在下面討論。2.2.1. 所有類型的認(rèn)證都適用的參數(shù)下列HTTP請求參數(shù)“MAY”傳遞給 /login，當(dāng)它作為憑證接收者時。 他們都是大小寫敏感的，而且“MUST”被/login處理。service Optional client的URL

14、。認(rèn)證成功后，CAS MUST 重定向client到這個URL。在Section 2.2.4中將詳細(xì)討論。warn Optional 如果設(shè)置了這個參數(shù)，單點MUST NOT是透明的。當(dāng)認(rèn)證到另一個服務(wù)的時候，client MUST被顯式提示，。2.2.2. 用戶名/密碼認(rèn)證時的參數(shù)除了Section 2.2.1中介紹的Optional參數(shù),當(dāng)作為用戶名/密碼方式認(rèn)證的憑證接收者時，下面的這些HTTP請求參數(shù)MUST傳遞給/login。都是大小寫敏感的。username REQUIRED 用戶名password REQUIRED 密碼lt REQUIRED a login ticket. 這要

15、作為login表單的一部分，在Section 2.1.3中討論過。關(guān)于login ticket，將在Section 3.5中討論。2.2.3. trust方式認(rèn)證的參數(shù)Trust認(rèn)證方式下，沒有REQUIRED HTTP 請求參數(shù). Trust 認(rèn)證可以基于HTTP請求的任何方面。2.2.4. 回應(yīng)當(dāng)作為憑證接收者時，/login提供的回應(yīng)必須是下列之一：.成功登錄: 重定向client到service參數(shù)指定的 URL但是client的憑證不能轉(zhuǎn)發(fā)給service。重定向 MUST讓client執(zhí)行一個GET請求到service,這個請求MUST包含一個合法的service ticket,作

16、為HTTP請求參數(shù)ticket傳遞過去. 更多信息參閱 Appendix B。如果service參數(shù)沒有指定, CAS MUST顯示一條信息，提醒client已經(jīng)建立了單點登錄session。登錄失敗:返回 /login，這里/login成為憑證請求者。RECOMMENDED 這種情況下，CAS顯示一條錯誤信息，告訴用戶失敗的原因(比如：錯誤的密碼，賬號被鎖定等)，如果允許，同時提給用戶再次嘗試登錄的機會。2.3. /logout/logout 銷毀client的單點登錄session. ticket-granting cookie (Section 3.6)被銷毀,后續(xù)的對/login的請求

17、不再獲得service ticket，除非用戶重新登錄成功并建立了新的單點登錄session。2.3.1. 參數(shù)下面的HTTP請求參數(shù)MAY傳遞給/logout，他們是大小寫敏感的，SHOULD 被/logout處理。url OPTIONAL 如果指定了url, url 指定的URL SHOULD顯示在logout頁面上，并且要有文字說明。例如：The application you just logged out of has provided a link it would like you to follow. Please click here to access HYPERLINK

18、o 2.3.2. 回應(yīng)/logout MUST 顯示一個頁面，告訴用戶已經(jīng)登出了。如果指定了請求參數(shù)url。 /logout SHOULD 提供一個鏈接，指向Section 2.3.1中提到的URL.2.4. /validate CAS 1.0/validate 檢查service ticket的合法性。/validate是 CAS 1.0協(xié)議的一部分，因此不會處理代理認(rèn)證。 當(dāng)proxy ticket傳遞給/validate時，CAS MUST 給出驗證失敗的回應(yīng)。2.4.1. 參數(shù)下面這些HTTP請求參數(shù)MAY指定給/validate. 他們是大小寫敏感的，而且MUST被/validate

19、處理。service REQUIRED 應(yīng)用服務(wù)的標(biāo)識，在Section 2.2.1中討論過.ticket REQUIRED - /login提供的service ticket.在Section 3.1中詳細(xì)討論.renew OPTIONAL 如果指定這個參數(shù)，只有在提供用戶主憑證的情況下，ticket驗證才會成功。如果ticket是從一個單點登錄session提供的，驗證會失敗。(注：也就是說這次驗證的service ticket是用戶提供憑證產(chǎn)生的，例如輸入了用戶名和密碼。如果用戶以前已經(jīng)單點登錄，這樣產(chǎn)生的service ticket無效)2.4.2. 回應(yīng)/validate 將返回下列

20、兩個回應(yīng)之一：Ticket驗證成功時:yesusername驗證失敗時:no2.4.3. /validate的例子簡單驗證嘗試: HYPERLINK /cas/validate?service=http%3A%2F%2F&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 o /cas/validate?service=http%3A%2F%2F&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 https:/server/cas/validate?service=http%3A%2F%2F&ticket=.確保ticket是用戶提供主憑證

21、產(chǎn)生的: HYPERLINK /cas/validate?service=http%3A%2F%2F&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&renew=true o /cas/validate?service=http%3A%2F%2F&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&renew=true https:/server/cas/validate?service=http%3A%2F%2F&ticket=.2.5. /serviceValidate CAS 2.0/serviceValidate 檢查servic

22、e ticket的合法性，返回XML格式的回應(yīng)。在必要的情況下，/serviceValidate MUST 產(chǎn)生和執(zhí)行proxy-granting tickets. 當(dāng)收到proxy ticket時，/serviceValidate MUST NOT 返回成功驗證。 RECOMMENDED 當(dāng)/serviceValidate收到proxy ticket時, XML回應(yīng)里的錯誤信息SHOULD 說明驗證失敗是因為提供了一個proxy ticket到/serviceValidate.2.5.1. 參數(shù)下面這些HTTP請求參數(shù)MAY指定給/serviceValidate. 他們都是大小寫敏感的而且

23、MUST被/serviceValidate處理。service REQUIRED 提供ticket的service的標(biāo)識，在Section 2.2.1中討論過.ticket REQUIRED - /login提供的service ticket. Service tickets在Section 3.1中詳細(xì)討論.pgtUrl OPTIONAL 代理的callback(回調(diào))的URL. 在Section 2.5.4中討論.renew OPTIONAL -如果指定這個參數(shù)，只有在提供用戶主憑證的情況下，ticket驗證才會成功。如果ticket是從一個單點登錄session提供的，驗證會失敗。(注：

24、也就是說這次驗證的service ticket是用戶提供憑證產(chǎn)生的，例如輸入了用戶名和密碼。如果用戶以前已經(jīng)單點登錄，這樣產(chǎn)生的service ticket無效)。2.5.2. 回應(yīng)/serviceValidate 將返回 XML格式的CAS serviceResponse，在附錄A的XML schema中詳細(xì)說明.下面是一些例子:Ticket驗證成功時: username PGTIOU-84678-8a9d. Ticket驗證失敗時: Ticket ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 not recognized 2.5.3. 錯誤代碼認(rèn)證失敗的回應(yīng)中MAY包括下

25、面這些代碼。下面是所有CAS服務(wù)器MUST實現(xiàn)的最小錯誤代碼集合，實際實現(xiàn)中MAY包括更多其他代碼。INVALID_REQUEST 沒有提供所有必須參數(shù)INVALID_TICKET ticket不合法，或者當(dāng)驗證時指定了”renew”時，ticket不是由用戶提供登錄憑證生成(比如來自于已有的session)?；貞?yīng)的XML 消息的部分SHOULD說明細(xì)節(jié)。INVALID_SERVICE 提供的ticket是正確的，但是指定的service與ticket關(guān)系的service不一致。CAS MUST 判斷ticket不合法，并且不允許進(jìn)一步的驗證這個ticket。INTERNAL_ERROR 在驗

26、證ticket時發(fā)生內(nèi)部錯誤。所有錯誤代碼， it is RECOMMENDED that CAS 在XML回應(yīng)消息的部分提供詳細(xì)信息。2.5.4. proxy callback如果一個service希望代理客戶端認(rèn)證到另一個后端service，它必須獲取一個proxy-granting ticket。這個ticket的獲取是通知一個proxy callback URL實現(xiàn)的。這個URL唯一并安全地標(biāo)識正在代理登錄的后端service.后端service 必須通過后端服務(wù)識別callback URL決定是否接受憑證。 proxy callback 機制工作原理如下：申請proxy-granti

27、ng ticket的service，在驗證service ticket或proxy ticket時，傳遞給/serviceValidate或/proxyValidate的HTTP請求是加上參數(shù)”pgtUrl”。這是一個callback URL，CAS將連接這個URL確認(rèn)service的身份。這個URL MUST be HTTPS, CAS MUST驗證SSL證書的合法性，并且證書的名稱與service匹配。 如果證書驗證失敗，就不會有proxy-granting ticket 生成，并且 CAS service 回應(yīng)Section 2.5.2中描述的消息，MUST NOT包含節(jié).這時， pro

28、xy-granting ticket 被中止， service ticket 驗證會繼續(xù),返回成功或失敗。如果證書驗證成功，確保如如第2步中那樣處理proxy-granting ticket。CAS使用HTTP GET 請求，傳遞 HTTP請求參數(shù)pgtId和pgtIou到pgtUrl.它們在Sections 3.3 and 3.4中討論過.如果HTTP GET 返回HTTP 狀態(tài)代碼200(OK), CAS MUST對/serviceValidate (or /proxyValidate)的請求作出回應(yīng) (Section 2.5.2) ，在節(jié)中包含proxy-granting ticket

29、IOU (Section 3.4). 如果HTTP GET 返回其他狀態(tài)代碼，除了HTTP 3xx重客向，CAS MUST對/serviceValidate (or /proxyValidate) 的請求作出回應(yīng)， MUST NOT包含 節(jié). CAS MAY 跟蹤任何pgtUrl給出的HTTP 重定向. 可是,在驗證時節(jié)中的標(biāo)識callback URL MUST和最初作為”pgtUrl提供給/serviceValidate (or /proxyValidate)相同.申請proxy-granting ticket的service，在CAS的回應(yīng)中收到proxy-granting ticket

30、IOU，在proxy callback的URL中接收到proxy-granting ticket和a proxy-granting ticket IOU，然后用proxy-granting ticket IOU關(guān)聯(lián)proxy-granting ticket。接下來service 使用proxy-granting ticket 獲取proxy ticket，在Section 2.7中有詳細(xì)討論.2.5.5. /serviceValidate 的例子簡單認(rèn)證嘗試: HYPERLINK /cas/serviceValidate?service=http%3A%2F%2F&ticket=ST-1856

31、339-aA5Yuvrxzpv8Tau1cYQ7 o /cas/serviceValidate?service=http%3A%2F%2F&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 https:/server/cas/serviceValidate?service=http%3A%2F%2F&.確保service ticket是用戶提供主憑證獲取(如通過輸入用戶名和密碼，而非通過ticket granting cookie)的: HYPERLINK /cas/serviceValidate?service=http%3A%2F%2F&ticket= o /c

32、as/serviceValidate?service=http%3A%2F%2F&ticket= https:/server/cas/serviceValidate?service=http%3A%2F%2F&. ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&renew=true傳入callback URL，獲取proxy-granting ticket: HYPERLINK /cas/serviceValidate?service=http%3A%2F%2F&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&pgtUrl=https:/my-se

33、rver/myProxyCallback o /cas/serviceValidate?service=http%3A%2F%2F&ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7&pgtUrl=https:/my-server/myProxyCallback https:/server/cas/serviceValidate?service=http%3A%2F%2F&.2.6. /proxyValidate CAS 2.0/proxyValidate MUST 執(zhí)行與/serviceValidate相同的驗證任務(wù)，并且要增加對proxy tickets的驗證。/

34、proxyValidate MUST 有能力處理service ticket和proxy ticket。2.6.1. 參數(shù)/proxyValidate 與/serviceValidate對參數(shù)的要求相同. 見Section .6.2. 回應(yīng)/proxyValidate會返回一個XML格式的CAS serviceResponse，在附錄A的 XML schema 中有詳細(xì)說明.下面是一些例子:Ticket驗證成功時: username PGTIOU-84678-8a9d. https:/proxy2/pgtUrl https:/proxy1/pgtUrl 注意，當(dāng)認(rèn)證是通過多個代理

35、完成的，這些代理的順序MUST在 節(jié)中反映.最近的代理MUST是列表中的第一條,所有其他代理MUST按順序列出。在上面的例子中， HYPERLINK /pgtUrl o /pgtUrl https:/proxy1/pgtUrl 是最早的代理，它代理了 HYPERLINK /pgtUrl o /pgtUrl https:/proxy2/pgtUrl.Ticket驗證失敗時： ticket PT-1856376-1HMgO86Z2ZKeByc5XdYD not recognized 2.6.3 /proxyValidate的例子/proxyValidate 接收與 /serviceValidate

36、相同的參數(shù). 見 Section 2.5.5 中的例子，用 proxyValidate 代替 serviceValidate。2.7. /proxy CAS 2.0已經(jīng)獲取proxy-granting ticket的service在代理后端service登錄時，/proxy為它提供proxy ticket。2.7.1. 參數(shù)下面這里HTTP請求參數(shù)MUST指定給/proxy，他們都是大小寫敏感的。pgt REQUIRED service 在service ticket或proxy ticket驗證期間獲取的proxy-granting ticket.targetService REQUIRED

37、 后端服務(wù)的標(biāo)識。注意，并非所有后端服務(wù)都是基于web的，所以這里的服務(wù)標(biāo)識并非都是URL?？墒牵@里的服務(wù)標(biāo)識MUST與后面進(jìn)行proxy ticket的驗證時傳遞給/proxyValidate的service參數(shù)一致。2.7.2. 回應(yīng)/proxy會返回一個XML格式的CAS serviceResponse，在附錄A的 XML schema 中有詳細(xì)說明.下面是一些例子:請求成功: PT-1856392-b98xZrQN4p90ASrw96c8 請求失敗: pgt and targetService parameters are both required 2.7.3. 錯誤代碼認(rèn)證失敗的

38、回應(yīng)消息中，下面這些值MAY出現(xiàn)在code屬性里。下面是所有CAS服務(wù)器MUST實現(xiàn)的最小代碼集合。實際實現(xiàn)中MAY包含其他代碼。INVALID_REQUEST - 沒有提供所有必須的請求參數(shù)BAD_PGT 提供的pgt不合法INTERNAL_ERROR ticket驗證過程中出現(xiàn)內(nèi)部錯誤對所有錯誤代碼, it is RECOMMENDED that CAS在XML回應(yīng)消息的節(jié)中提供更加詳細(xì)的說明。2.7.4. /proxy的例子簡單的proxy請求: HYPERLINK /cas/proxy?targetService=http%3A%2F%2F&pgt=PGT-490649-W81Y9Sa

39、2vTM7hda7xNTkezTbVge4CUsybAr o /cas/proxy?targetService=http%3A%2F%2F&pgt=PGT-490649-W81Y9Sa2vTM7hda7xNTkezTbVge4CUsybAr https:/server/cas/proxy?targetService=http%3A%2F%2F&pgt=.3. CAS 對象3.1. service ticketService ticket是一個字符串，client使用這個字符串作為訪問service的憑證。Service ticket，是client通過提供身份憑證和服務(wù)標(biāo)識到CAS的/logi

40、n(Section 2.2中有說明)，從CAS獲取的。3.1.1. service ticket的特性Service tickets僅對生成它時在/login中指定的service標(biāo)識有效。Service標(biāo)識SHOULD NOT是service ticket的一部分。Service ticketss MUST僅對一次驗證嘗試有效，不論驗證成功與否。CAS MUST注銷ticket，讓所有后續(xù)對同一個ticket的嘗試失效。CAS SHOULD 在生成service ticket，經(jīng)過一段合適的時間過后，讓service ticket過期。如果service申請驗證過期的service tick

41、et， CAS MUST給出驗證失敗的回應(yīng)。It is RECOMMENDED that 驗證回應(yīng)消息包含為什么驗證失敗的說明信息。It is RECOMMENDED that service ticket過期之前的有效時間不超過5分鐘。本地安全策略和CAS應(yīng)用的綜合考慮MAY決定未驗證的service ticket的最優(yōu)生命周期。Service tickets MUST 包含充足的安全的隨機數(shù)據(jù)，以使它不能被猜出。Service tickets MUST 以字符串 ST-開始.Services MUST 接受多至32個字符的service ticket. It is RECOMMENDED

42、that services支持多至256個字符長度的service tickets.3.2. proxy ticketProxy ticket是一個字符串，services用它作為訪問后端service的憑證。Service向CAS提供合法的proxy-granting ticket(Section 3.3)和它希望連接的后端服務(wù)的服務(wù)標(biāo)識，從CAS獲取proxy tickets。3.2.1. proxy ticket 特性Proxy tickets 僅對生成它時在/proxy中指定的service標(biāo)識有效。Service標(biāo)識SHOULD NOT是proxy ticket的一部分。Proxy

43、tickets MUST 僅對一次驗證嘗試有效，不論驗證是否成功。然后，CAS MUST注銷這個ticket，使后來對同一個ticket的驗證嘗試失效。CAS SHOULD 在生成proxy tickets，經(jīng)過一段合適的時間以后，讓proxy tockets過期。如果service提供了過期的proxy ticket，CAS MUST給出驗證失敗的回應(yīng)消息。It is RECOMMENDED that 驗證回應(yīng)消息中包含驗證失敗的說明。It is RECOMMENDED that proxy ticket過期之前的有效時間不超過5分鐘。本地安全策略和CAS使用的綜合考慮， MAY 決定未驗證

44、的proxy tickets最優(yōu)的生命周期。Proxy tickets MUST 包含足夠安全的隨機數(shù)據(jù)，以使它不能被猜出。Proxy tickets SHOULD 以字符串PT-開頭. Proxy tickets MUST 以字符串ST-或PT-開頭。后端services MUST能夠接受多至32個字符長度的proxy tickets。 It is RECOMMENDED that 后端services支持多至256個字符長度的proxy tickets。3.3. proxy-granting ticketproxy-granting ticket是一個字符串，service用它獲取prox

45、y tickets，然后用proxy tickets訪問后端服務(wù)。Proxy-granting tickets 從CAS獲取，獲取時需通過service ticket或proxy ticket的驗證。Proxy-granting ticket 在Section 2.5.4中充分說明.3.3.1. proxy-granting ticket 特性Proxy-granting tickets MAY 被services用于獲取多個proxy tickets。Proxy-granting tickets不是一次性的tickets.Proxy-granting tickets MUST 失效，在被代理

46、的client登出CAS時。Proxy-granting tickets MUST 包含足夠安全的隨機數(shù)據(jù)，使ticket在遭遇暴力破解時，在合理的一段時間內(nèi)不被猜出。Proxy-granting tickets SHOULD 以字符串PGT-開頭.Services MUST有能力接受多至64個字符長度的proxy-granting tickets。It is RECOMMENDED that services 支持多至256個字符長度的proxy-granting tickets。3.4. proxy-granting ticket IOUA proxy-granting ticket IO

47、U 是一個字符串，出現(xiàn)在/serviceValidate和/proxyValidate的回應(yīng)消息里，通過它把service ticket或proxy ticket的驗證與某個特定的proxy-granting ticket關(guān)聯(lián)起來。這個過程的詳細(xì)說明見 Section .1. proxy-granting ticket IOU特性Proxy-granting ticket IOUs SHOULD NOT 包含與他們關(guān)聯(lián)的proxy-granting ticket相關(guān)的任何內(nèi)容。給出一個PGTIOU, 通過一定算法在一段合適的時間內(nèi)，it MUST NOT 可能計算出它相關(guān)的PG

48、T，Proxy-granting ticket IOUs MUST 包含足夠安全的隨機數(shù)據(jù)，使ticket在合適的時間段內(nèi)通過暴力破解的方法不能猜出。Proxy-granting ticket IOUs SHOULD以字符串PGTIOU-開頭.Services MUST 有能力處理多至64個字符長度的PGTIOUs。It is RECOMMENDED that services 支持多至256個字符長度的PGTIOUs.3.5. login ticketlogin ticket是一個字符串，在用戶名/密碼形式的認(rèn)證中，由/login作為憑證請求者時提供，傳遞給作為憑證接收者的/login. 它

49、的目的是保護(hù)因為瀏覽器的BUG引起的重復(fù)提交。3.5.1. login ticket 特性Login tickets 由/login生成， MUST在概率上是唯一的。Login tickets MUST 僅對一次認(rèn)證嘗試有效，不論認(rèn)證是否成功，然后CAS MUST 使login ticket失效，讓后來的使用這個login ticket的認(rèn)證嘗試失敗。Login tickets SHOULD 以字符串 LT-開頭.3.6. ticket-granting cookieticket-granting cookie 是一個HTTP cookie HYPERLINK /products/cas/pr

50、otocol.html l 5 5 ，由CAS在建立起單點登錄session時設(shè)置。在它生效期間，這個cookie為client維持登錄狀態(tài), client可以把它提供給CAS 代替主憑證。Services退出單點登錄，通過設(shè)置”renew”參數(shù)(在 Sections 2.1.1, 2.4.1,和 2.5.1中有說明)。3.6.1. ticket-granting cookie 特性Ticket-granting cookies MUST 在client的瀏覽器session結(jié)束時失效。CAS MUST盡可能嚴(yán)格地設(shè)置cookie的路徑。例如：如果CAS server設(shè)置在/cas路徑, co

51、okie的路徑 MUST設(shè)置為/cas.ticket-granting cookies的值 MUST包含足夠安全的隨機數(shù)據(jù)，使ticket-granting cookie在一段合理的時間內(nèi)不被猜出。ticket-granting cookies SHOULD以字符串TGC-開頭.3.7. ticket and ticket-granting cookie 字符集除上面的要求以外，所有CAS tickets以及ticket-granting cookie 的值MUST僅包含這些字符：A-Z, a-z, 0-9, and the hyphen character ?-.Appendix A: CA

52、S response XML schema Appendix B: Safe redirectionAfter a successful login, safely redirecting the client from CAS to its final destination must be handled with care. In most cases, the client has sent credentials to the CAS server over a POST request. By this specification, the CAS server must then

53、 forward the user to the application with a GET request.The HTTP/1.1 RFC HYPERLINK /products/cas/protocol.html l 3 3 provides a response code of 303: See Other, which provides for the desired behavior: a script that receives data through a POST request can, through a 303 redirection, forward the bro

54、wser to another URL through a GET request. However, not all browsers have implemented this behavior correctly.The recommended method of redirection is thus JavaScript. A page containing a window.location.href in the following manner performs adequately: Yale Central Authentication Service window.loc

55、ation.href=/Login?ticket=ST-. mce_href=/Login?ticket=ST-.; CAS login successful. Click here to access the service you requested. Additionally, CAS should disable browser caching by setting all of the various cache-related headers:Pragma: no-cacheCache-Control: no-storeExpires: RFC 1123 HYPERLINK /pr

56、oducts/cas/protocol.html l 6 6 date equal to or before nowThe introduction of the login ticket removed the possibility of CAS accepting credentials that were cached and replayed by a browser. However, early versions of Apples Safari browser contained a bug where through usage of the Back button, Saf

57、ari could be coerced into presenting the clients credentials to the service it is trying to access. CAS can prevent this behavior by not automatically redirecting if it detects that the remote browser is one of these early versions of Safari. Instead, CAS should display a page that states login was

58、successful, and provide a link to the requested service. The client must then manually click to proceed.Appendix C: References1 Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, Harvard University, March 1997.2 Berners-Lee, T., Fielding, R., Frystyk, H., Hypertext Tran

59、sfer Protocol - HTTP/1.0, RFC 1945, MIT/LCS, UC Irvine, MIT/LCS, May 1996.3 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Hypertext Transfer Protocol - HTTP/1.1, RFC 2068, UC Irvine, Compaq/W3C, Compaq, W3C/MIT, Xerox, Microsoft, W3C/MIT, June 1999.4 Ber

60、ners-Lee, T., Masinter, L., and MaCahill, M., Uniform Resource Locators (URL), RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994.5 Kristol, D., Montulli, L., HTTP State Management Mechanism, RFC 2965, Bell Laboratories/Lucent Technologies, E, Inc., October 2000.6 Braden, R.,