摘要:是大學(xué)發(fā)起的一個(gè)企業(yè)級(jí)的開源的項(xiàng)目,旨在為應(yīng)用系統(tǒng)提供一種可靠的單點(diǎn)登錄解決方法屬于。實(shí)現(xiàn)原理是先通過的認(rèn)證,然后向申請(qǐng)一個(gè)針對(duì)于的,之后在訪問時(shí)把申請(qǐng)到的針對(duì)于的以參數(shù)傳遞過去。后面的流程與上述流程步驟及以后步驟類似
CAS( Central Authentication Service )是 Yale 大學(xué)發(fā)起的一個(gè)企業(yè)級(jí)的、開源的項(xiàng)目,旨在為 Web 應(yīng)用系統(tǒng)提供一種可靠的單點(diǎn)登錄解決方法(屬于 Web SSO )。
其流程用時(shí)序圖描述如下:
請(qǐng)求app地址http://www.app.com
app端(cas client)AuthenticationFilter中校驗(yàn)session中_const_cas_assertion_,不為空,直接放過url;否則獲取request中的ticket參數(shù),request中無ticket,302重定向到cas server地址,url中帶上service參數(shù)http://www.casserver.com/?ser...://www.app.com
cas server先判斷context中是否有service對(duì)應(yīng)的TGT
判斷沒有TGT,返回login form(客戶端跳轉(zhuǎn)至cas server登錄頁地址)
用戶輸入登錄信息,form提交至cas server
cas server驗(yàn)證登錄信息,生成TGT和ST
設(shè)置TGC至cookie,url中顯式帶上ticket(STid)參數(shù),重定向Browser至App
App中AbstractTicketValidationFilter 會(huì)向cas server請(qǐng)求校驗(yàn)ticket,帶上ticket(STid)和service(回調(diào)地址)參數(shù)
cas server通過ServiceValidateController校驗(yàn)ticket
確認(rèn)有效后返回校驗(yàn)成功
此時(shí)App中會(huì)根據(jù)成功結(jié)果,在session中設(shè)置_const_cas_assertion_屬性
重定向到app,此時(shí)url中不帶有ticket參數(shù)
這時(shí)再經(jīng)過AuthenticationFilter時(shí),session中有_const_cas_assertion_屬性,放行;再經(jīng)過AbstractTicketValidationFilter時(shí),request中沒有ticket參數(shù),放行,訪問目標(biāo)資源
返回目標(biāo)資源給browser
要點(diǎn)如下:
如若第4步中,判斷結(jié)果為有service對(duì)應(yīng)的TGT,先驗(yàn)證ticket(TGTid)、service是否合法,再根據(jù)renew參數(shù)看是否要重新創(chuàng)建service ticket,若要重新創(chuàng)建,則需要重新登錄;否則重新轉(zhuǎn)向service地址
如若app端想使用自己的自定義登錄界面,可以在第4步中不跳轉(zhuǎn)cas server的登錄頁地址,轉(zhuǎn)而跳轉(zhuǎn)至自定義登錄頁面。但需要向cas server端請(qǐng)求login ticket,在用戶填寫登錄表單后,連同login ticket一同傳參至cas server去做校驗(yàn)
第6步中,TGT和ST的生成規(guī)則(這里指TGTid和STid的生成規(guī)則,TGT和ST均為類):"TGT_XX_RandomStr" "ST_XXX_RandomStr"。XX、XXX為AtomicLong.getAndIncrement()方法自增Long類型數(shù)字(最大值時(shí),調(diào)用AtomicLong.compareAndSet()方法置0);RandomStr為隨機(jī)字符串
步驟12中再已校驗(yàn)完用戶信息的情況下,再次進(jìn)行重定向的目的,是為了隱藏第7步重定向時(shí)url中的ticket入?yún)?/p>
單點(diǎn)登錄的目的,是讓用戶登錄App1后,如有權(quán)限,可免登錄,直接訪問App2、App3等。cas的實(shí)現(xiàn)方式,是在訪問其他App時(shí),使用Cas Proxy。實(shí)現(xiàn)原理是App1先通過Cas Server的認(rèn)證,然后向Cas Server申請(qǐng)一個(gè)針對(duì)于App2的proxy ticket,之后在訪問App2時(shí)把申請(qǐng)到的針對(duì)于App2的proxy ticket以參數(shù)ticket傳遞過去。后面的流程與上述cas流程步驟8及以后步驟類似
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://systransis.cn/yun/69276.html
摘要:上一篇文章簡單介紹了在本地開發(fā)環(huán)境中搭建服務(wù)端和客戶端,對(duì)單點(diǎn)登錄過程有了一個(gè)直觀的認(rèn)識(shí)之后,本篇將探討單點(diǎn)登錄的實(shí)現(xiàn)原理。因此引入服務(wù)端作為用戶信息鑒別和傳遞中介,達(dá)到單點(diǎn)登錄的效果。為該流程的實(shí)現(xiàn)類。表示對(duì)返回結(jié)果的處理。 上一篇文章簡單介紹了 CAS 5.2.2 在本地開發(fā)環(huán)境中搭建服務(wù)端和客戶端,對(duì)單點(diǎn)登錄過程有了一個(gè)直觀的認(rèn)識(shí)之后,本篇將探討 CAS 單點(diǎn)登錄的實(shí)現(xiàn)原理。 一...
CAS Compare And Swap.比較并交換.java中的同步器就是基于CAS技術(shù)實(shí)現(xiàn)的,為什么它能保證操作的同步性呢?因?yàn)槭窃硬僮鞯囊环N,所以可以在多線程環(huán)境下來實(shí)現(xiàn)數(shù)據(jù)的交換操作不被打斷. CAS的缺陷ABA問題: 第一個(gè)線程來讀取變量A時(shí)被掛起;第二個(gè)線程過來操作A,將A賦值為B之后,并重新賦值為A;線程二完成操作;此時(shí),對(duì)于線程一來說,所看到變量A的值是沒有變化的,但是實(shí)際上變...
摘要:最終依舊使用來更新值。此時(shí)使用能更好地提升性能。適用于高并發(fā)情況下的計(jì)數(shù)操作,利用與相似的原理,以空間換時(shí)間,提高了實(shí)際的計(jì)數(shù)效率。 AtomicLong /** * Atomically increments by one the current value. * * @return the updated value */ public final long increme...
摘要:原理剖析第篇工作原理分析一大致介紹關(guān)于多線程競爭鎖方面,大家都知道有個(gè)和,也正是這兩個(gè)東西才引申出了大量的線程安全類,鎖類等功能而隨著現(xiàn)在的硬件廠商越來越高級(jí),在硬件層面提供大量并發(fā)原語給我們層面的開發(fā)帶來了莫大的利好本章節(jié)就和大家分享分 原理剖析(第 004 篇)CAS工作原理分析 - 一、大致介紹 1、關(guān)于多線程競爭鎖方面,大家都知道有個(gè)CAS和AQS,也正是這兩個(gè)東西才引申出了大...
摘要:負(fù)載均衡算法輪詢,加權(quán)輪詢。參考三負(fù)載均衡負(fù)載均衡由服務(wù)提供廠商提供。之后,集群內(nèi)再采用其他的負(fù)載均衡方案。參考五負(fù)載均衡工作在層,它會(huì)與分別建立連接,需要維護(hù)這兩個(gè)連接的狀態(tài)。 運(yùn)營研發(fā)團(tuán)隊(duì) 施洪寶 一. 基礎(chǔ)知識(shí) 1.1 基礎(chǔ) 什么是負(fù)載均衡? 當(dāng)單機(jī)提供的并發(fā)量不能滿足需求時(shí),我們需要多臺(tái)服務(wù)器同時(shí)服務(wù)。當(dāng)客戶請(qǐng)求到達(dá)時(shí),如何為客戶選擇最合適的服務(wù)器?這個(gè)問題就是負(fù)載均衡問題。...
閱讀 2699·2021-11-25 09:43
閱讀 2500·2021-09-22 15:29
閱讀 1022·2021-09-22 15:17
閱讀 3682·2021-09-03 10:36
閱讀 2257·2019-08-30 13:54
閱讀 1781·2019-08-30 11:23
閱讀 1192·2019-08-29 16:58
閱讀 1320·2019-08-29 16:14