Tìm hiểu cơ chế đăng nhập một lần (Single sign on) và thử nghiệm dựa trên thư viện PHPCAS (Đồ án tốt nghiệp)

Tìm hiểu cơ chế đăng nhập một lần (Single sign on) và thử nghiệm dựa trên thư viện PHPCASTìm hiểu cơ chế đăng nhập một lần (Single sign on) và thử nghiệm dựa trên thư viện PHPCASTìm hiểu cơ chế đăng nhập một lần (Single sign on) và thử nghiệm dựa trên thư viện PHPCASTìm hiểu cơ chế đăng nhập một lần (Single sign on) và thử nghiệm dựa trên thư viện PHPCASTìm hiểu cơ chế đăng nhập một lần (Single sign on) và thử nghiệm dựa trên thư viện PHPCASTìm hiểu cơ chế đăng nhập một lần (Single sign on) và thử nghiệm dựa trên thư viện PHPCASTìm hiểu cơ chế đăng nhập một lần (Single sign on) và thử nghiệm dựa trên thư viện PHPCASTìm hiểu cơ chế đăng nhập một lần (Single sign on) và thử nghiệm dựa trên thư viện PHPCASTìm hiểu cơ chế đăng nhập một lần (Single sign on) và thử nghiệm dựa trên thư viện PHPCAS

-o0o -ÁN T T NGHI P

NGÀNH CÔNG NGH THÔNG TIN

H I PHÒNG 2013

TÌM HI P M T L N

N PHPCAS

TÌM HI P M T L N

N PHPCAS

ng d n: Th.s Bùi Huy Hùng Sinh viên th c hi n:

NHI M V THI T K T T NGHI P

Sinh viên:

-o0o -a N i dung

Tìm hi u v CAS (Central Authentication Service).

phpCAS.

b Các yêu c u c n gi i quy t

Lý thuy t

Th c nghi

t CAS và th c nghi m v i website PHP

2 Các s li u c n thi tính toán.

m th c t p.

H và tên: Bùi Huy Hùng

H c hàm, h c v : Th

i H c Dân L p H i Phòng

Tìm hi u v Single Sign On d a trên Central Authentication Service

Tinh th c tài t t nghi p:

ng c tài t t nghi p (so v i n i dung yêu c ra trong nhi m v tài t t nghi p)

3 m c a cán b ng d n: m ghi b ng s và ch )

(Ký, ghi rõ h tên)

Cán b ch m ph n bi n

(Ký, ghi rõ h tên)

c h y giáo, cô giáo Khoa Công ngh

i h c Dân l p H i Phòng, nh y d , trang b cho chúng em nh ng ki n th n, c n thi t trong nh c v em có

tôi nh ng lúc tôi m t m ng l tôi c g ng

M t s c c g hoàn thi n báo cáo t t nghi p song do kh

n ch nên bài báo cáo v n còn nhi u thi u sót Vì v y em r t mong nh n

M t l n n a em xin chân thành c

H i Phòng, Ngày 04 tháng 11

Sinh viên

M C L C

L I C 1

M C L C 2

DANH M C HÌNH 4

DANH M C B NG 6

DANH SÁCH CH VI T T T 7

L I NÓI U 8

I THI U V P 1 L N (SINGLE SIGN ON) 9 1.1 T ng quan v SSO [1] 9

1.2 L i ích mà SSO mang l i 9

1.3 M t s v ng g p khi tri n khai SSO 10

1.4 Các gi i pháp SSO hi n nay.[2] 11

N M M NGU N M CENTRAL AUTHENTICATION SERVICE 16

2.1 Gi i thi u v ph n m m ngu n m (Opensource).[3] 16

2.2 D ch v ch ng th c trung tâm (Central Authentication Service).[4] 17

2.2.1 T ng quan v CAS 17

2.2.2 L ch s hình thành [5] 18

2.2.3 Các phiên b n c a CAS 19

2.2.4 CAS Protocol 19

2.2.5 T ng k t 27

2.2.6 CAS Entities 29

2.2.7 Nguyên t c ho ng 32

2.2.8 Ki n trúc t ng quan CAS 37

2.3 Ruby CAS.[6] 40

2.4 CAS Client 41

2.4.1 Gi i thi u ngôn ng xây d ng website phía client 41

n phpCAS.[7] 41

2.5.1 phpCAS requirements 41

2.5.2 phpCAS examples 43

2.5.3 phpCAS logout 44

2.5.4 phpCAS troubleshooting 45

2.6 V v b o m t cho SSO 46

C NGHI M .48

t h th ng 48

3.1.1 u ki n c n thi t 48

3.1.2 Gi i thi u 48

3.1.3 Cài d t CAS-server 49

3.1.4 Tích h p CAS client vào h th ng 64

3.2 Các pha trong h th p 70

K T LU N 75

TÀI LI U THAM KH O 76

PH L C 77

Ph l c A: CAS ph n h XML 77

Ph l c B: Chuy ng an toàn 79

Ph L c C: Ph n code x p SSO h th ng 1 80

Ph L c D: Ph n code x p SSO h th ng 2 83

DANH M C HÌNH

Hình 1.1: Single sign on là gì? 9

i dùng truy c p vào ng d ng th c v i CAS 33

i dùng truy c p vào ng d ng th c v i CAS server 34

Hình 2.3: Login flow 38

Hình 2.4: Proxy flow 39

Hình 2.5: logout flow 40

Hình 2.6: Nguyên t c ho ng phpCAS 43

v trí CAS trong h th ng m ng 47

Hình 3.1: T i RubyInstaller 49

c1 50

c2 50

c 3 51

c4 52

Hình 3.6: Gi i nén Development Kit 52

c 5 53

Hình 3.8: Cài d t Bunlde 53

Hình 3.9: T i mã ngu n RubyCAS 54

Hình 3.10: Tri c1 54

Hình 3.11: T i dùng cho RubyCAS xác th c 57

Hình 3.12: T i dùng cho RubyCAS xác th c 2 58

Hình 3.13: Tri c 2 58

Hình 3.14: Tri c 3 59

Hình 3.15: Tri c 4 59

Hình 3.16: Tri c 5 60

Hình 3.17: Ki m th t RubyCAS 63

Hình 3.18: C u trúc b ng casserver_lt 63

Hình 3.19: C u trúc b ng casserver_pgt 63

Hình 3.20: C u trúc b ng casserver_st 63

Hình 3.21: C u trúc b ng casserver_tgt 63

Hình 3.22: C u trúc b ng schema_migrations 64

Hình 3.23: Trang ch website 1 64

i dùng website 1 65

p h th ng website 1 65

Hình 3.26: Thêm m i bài vi t 66

Hì i dùng 66

Hình 3.28: C u trúc CSDL website 1 67

Hình 3.29: Trang ch website 2 67

i dùng website 2 68

p h th ng website 2 68

Hình 3.32:Trang upload video website 2 69

Hình 3.33: C u trúc CSDL website 2 69

Hình 3.34: Tích h p phpCAS vào website 1 70

Hình 3.35: Tích h p phpCAS website 2 70

Hình 3.36: Lu ng x lý khi client xin xác th c thông tin t CAS server 72

p khi user không t n t i CAS server 73

lu ng pha 6 74

B ng 1.1: Danh sách các gi i pháp SSO 11

B ng 2.1: T ng h p các URI 27

B ng 2.2: Danh sách tham s phpCAS 44

B ng 3.1: Thông tin table casserver_lt 60

B ng 3.2: Thông tin table casserver_pgt 61

B ng 3.3: Thông tin table casserver_st 61

B ng 3.4: Thông tin table casserver_tgt 62

DANH SÁCH CH VI T T T

CAS Central Authentication Service

URI Uniform Resource Identifier

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

PGTIOU Proxy-granting ticket IOU

TGTIOU Ticket -granting ticket IOU

TGT Ticket-granting ticket

L U

ng các d ch v cùng nhau chia s d li

ng phát tri n chung c a công ngh thông tin,m i dùng ph i qu n lý r t nhi u tài kho n, m t kh u cho các d ch v h u này s x y ra nhi u r i

i dùng ph i ghi nh các tài kho a, các ng d ng

và d ch v công ngh thông tin ngày càng nhi ng Do v y nhu c

nh p m t l n cho các ng d ng và d ch v này là không th thi u p m t

l n (Single Sign On) c nhi u t ch c, công ty trên th gi i nghiên c u và

(SINGLE SIGN ON).

v i m t tài kho n và m t kh truy c p vào nhi u ng d ng trong 1 phiên làm

vi c (session)

Hình 1.1: Single sign on là gì?

1.

p m t l n (SSO), m i s d i nh p các tài kho n và m t kh u cho t ng ng d ng m i khi h p vào các ng d ng khác nhau ho c các h th ng trong cùng m u này rõ ràng có

là ti n b i gian là lãng phí b i vì nhân viên ph p m i khi htruy c p vào m t h th ng m i t máy tính c a h

c th c hi n thông qua m t mô- c ph n m m riêng

bi t ho t c a ngõ vào t t c các ng d ng yêu c p Các

mô- i s d ng và sau qu n lý truy c p vào các ng d ng khác Nó

c a riêng mình N u h th ng SSO b t t k t n công có quy n truy

c p không gi i h n cho t t c các ng d ng ch ng th c c a các module SSO.SSO

ng là m t d án l n c n l p k ho ch c n th c khi th c hi n

1.

- Có ph i n u s d ng SSO s c i thi n v b o m t?

Xin tr l i r ng:

p m t l n ( SSO ) là m i SSO t nó không th c s

c i thi n b o m t và trên th c t , n u không tri làm gi m

th ng c a công ty nhân, v i m i m t yêu c u m t kh u riêng c a mình, SSO giúp gi m b t gánh n ng ph i dành th p vào t ng h

p vào toàn b h th ng s d ng SSO M t khác, SSO có nh ng l i ích nhi ng r i ro nó mang l i

Vì v y, m c dù SSO không ph i là thu c ch a bách b nh b o m t trong và

ti ng http://www.imprivata.com ) K t qu là, h th ng SSO có th t p trung xác

th c trên các máy ch c bi t H u này b ng cách s d ng các máy ch

c ng, m b o t t c các xác th u tiên thông qua máy ch SSO, c

và các khóa mã hóa, làm cho chúng là m t thách th i v i tin t c H th ng SSO

n m sâu trong ki n trúc IT c ng gi u m t cách an toàn sau nhi u

b ng l u này s giúp SSO an toàn h

- Các y u t c c khi tri n khai SSO là gì?

- B o m t: N u m t k xâm nh p làm t n h i tài kho n c i dùng

ho c m t kh u, k xâm nh p có th có r ng rãi và d dàng truy c p vào

Tên s n

ph m

Nhà phát tri n Lo i hình N n t ng Mô t

services/protocols

Novell Access

webSSO to browser based applications with rules, policies and methods to be complied to access-event

server/client implementation

CoSign single University of T ch c riêng SSO for

Tên s n

ph m

Nhà phát tri n Lo i hình N n t ng Mô t

Mi n phí

Facebook

connect Facebook

Facebook specific SSO

Facebook SSO

to third parties enabled by Facebook

Hewlett-i

Web and Federated Single Sign-On Solution

Tên s n

ph m

Nhà phát tri n Lo i hình N n t ng Mô t

life-management product

JanrainFedera

Social and conventional user SSO

JBoss SSO Red Hat Mi n phí Federated

Single Sign-on

JOSSO JOSSO Mi n phí

Open Source Single Sign-On Server

Kerberos M.I.T Protocol

Computernetwork authentication protocol

Microsoft

account Microsoft

Mi n phí và

i (Microsoft bây

gi thu hút các trang web m

s d ng h th ng)

Microsoft single sign-on web service

myOneLogin VMware i Cloud single

Tên s n

ph m

Nhà phát tri n Lo i hình N n t ng Mô t

OP, SAML IdP, and proprietary)

On-demand identity and access management service in the cloud

OpenAM ForgeRock Mi n phí

Yes, used in conjunction withOpenDJand

OpenIDM

Access management, entitlements and federation server platform

Tên s n

ph m

Nhà phát tri n Lo i hình N n t ng Mô t

Shibboleth Shibboleth Mi n phí

SAML-based open source access control

Ubuntu Single

Sign On

Canonical Ltd

i và

mi n phí

OpenID-based SSO for Launchpad and Ubuntu services

Reference Implementation

of TAS3 security

SERVICE.

Ph n m m ngu n m là gì?

Open source software là nh ng ph n m c vi t và cung c p m t cách t

l i chính là s mi i dùng có quy n "s h u h th ng"

Ti n ích mà opensource mang l i chính là quy n t do s d ng trình

phù h p v i nhu c u, truy c p vào mã ngu n, quy n t do phân ph i l i các phiên

khi ch c n cung c p thông tin c a h (ví d username và password) ch m t

l các ng d ng web xác th i s d ng mà không c n

ti p c n v i các thông tin b o m i dùng, ch ng h t kh u

PHP,

Giao th c CAS bao g m ít nh t ba bên: m t trình duy t web c a client, các

ng d ng web yêu c u ch ng th c, và các máy ch liên quan

n m t d ch v back-end, ch ng h t máy ch d li u, nó không có giao di n HTTP riêng c p v i m t ng d ng web

Khi client truy c p m t ng d ng mong mu xác th c v i nó, ng d ng

MYSQL/PGSQL) N u xác th c thành công, CAS tr client v ng d

thông qua 1 service ticket(ST) ng d n ticket b ng cách liên

h CAS trên m t k t n i an toàn và cung c p d ch v nh n d ng riêng c a mình và ticket.N u p cho các ng d y thông tin v vi c

thông tin tr c ti p t p c a CAS, n t qua s xác th c c a CAS

d li u ho c máy ch mail, có th tham gia trong CAS, xác nh n tính xác th c

c i dùng thông qua các thông tin nh c t các ng d ng

m t webmail và m t máy ch email tr c tuy u có th th c hi n CAS

nh v i th i gian c u hình m i dùng m trình duy t thì CAS s t ng chuy ng t i service URL i dùng mu n truy c p mà

2.2.2 hình thành.[5]

c hình thành và phát tri n b i Shawn Bayern c i

h c công ngh và k ho c duy trì b i Drew Mazurek i h c Yale CAS 1.0 th c hi - p CAS 2.0 gi i thi u xác th c y quy n

m i

thành m t d án c a Java Ki n trúc Special Interest Group, ch u trách nhi m duy trì và phát tri n c

i là i h c Yale CAS", CAS là bây gi c g i là "Jasig CAS"

gi i Yale c u tiên hàng

u khoa h c công ngh , trong s ti n $50.000, cho s phát tri n c a Yale c a CAS Vào th m i CAS s d ng t a

i h c (trong s th ng)"

Hi n nay r t nhi i h c n i ti ng trên th gi i tin dùng vào h

th p 1 l i h c Yale cung c p Chúng ta có th xem t a

ch : http://www.jasig.org/cas/deployments

r t tham s yêu c u HTTP, giá tr URL này ph i là

t n t i thì CAS nên yêu c u ch ng th c t i s d b u m t

t n t i, CAS s hi n th m t tin nh n thông báo cho client r

p

- Renew [Tùy ch n] - n u tham s c thi t l p, SSO s c b

ng h p này, CAS s yêu c

nh p hi n t n s t n t i c a session SSO v i CAS Tham s này là không t n t i song song v i tham s "gateway" Service chuy n các URI và

/login Không nên t c "renew" và "gateway" trong 1 URL Hành vi

nh n u c c thi t l p Khuy n ngh tri n khai CAS bqua các tham s "gateway" n u tham s c thi t l p Khuy n ngh khi các tham s c thi t l p thì giá tr c a nó là "true"

- Gateway [Tùy ch n] N u tham s c thi t l p thì CAS s không yêu c u client ch ng th c thông tin n a N p t c

i SSO session v i CAS hay n c thi t l p thông

i nhau(t c là xác th ng) thì CAS có thchuy ng client t c ch nh b i tham s

thêm vào 1 ST h p l (CAS có th thông báo cho client r

th c x u client không có SSO session v i CAS và

c ch nh b i tham s

nh Tham s này không cùng song hành trên 1 URL v i tham s

ng s nh n u c c set Các tham sm

Ph n h i

t GET yêu c u cho các service Yêu c u ph i bao g m

"ticket" Xem ph l c B bi t thêm thông tin N nh

Phá h y phiên làm vi c c SSO trên máy client TGC s b phá h y

và yêu c u ti p theo vào /login s n khi user thi t l p m t SSO session m i

Tham s

c hi n th trong trang logout cùng v t

2.2.4.3 /validate CAS[1.0]

Ki m tra tính h p l c a ST CAS ph i ph n h i 1 ticket validation th t b i

c thông qua URI /validate

- Renew [Tùy ch n] - N u tham s c thi t l p, ticket validation s

ch thành công n u ST c phát hành t bài trình bày c a ch ng chchính c i dùng Nó s không thành công n c phát hành t m t SSO session

Ph n h i

/validate s tr l i 1 trong hai ph n h i sau

Ticket validation thành công:

https://server/cas/validate?service=http://www.service.com&ticket=ST-1856339-Ch c ch n r c ban hành các trình bày các thông tin chính

aA5Yuvrxzpv8Tau1cYQ7&renew=true

https://server/cas/validate?service=http://www.service.com&ticket=ST-1856339-2.2.4.4 /serviceValidate [CAS 2.0]

/serviceValidate s tr v ph n h i là m t XML-fragment Khi thành công

ph n h i ch a username và proxy-granting tickets Khi th t b i, ph n h i ch a 1 mã

- INVALID_REQUEST không tìm th y tham s c n tìm tring request

- INVALID_TICKET Ticket cung c p không h p l ho c ticket không

n t c thi t l p trên validation

- INVALID_SERVICE c cung c p h p l ch v

c ch nh không kh p v i d ch v liên k t v i ticket

- INTERNAL_ERROR L i c c b trong khi ki m tra tính h p l c a ticket.

Ph n h i

/serviceValidate s tr v 1 XML- c mô t

:Xác th c Ticket thành công:

ph c x lý thông qua m t URL callback URL này s duy nh t và an toàn xác

nh d ch v back-end là proxying xác th c c a client Các d ch v back-end có th

ch p nh n các ch ng ch d a trên các d ch vback-

l ng d ch v CAS không ph i ch a 1 kh i <proxyGrantingTicket>

Ticket validation thành công:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>

<cas:authenticationSuccess>

<cas:user>username</cas:user>

N u HTTP GET tr l i 1 m t mã tr ng thái HTTP 200 (OK), CAS s ph i

ph n h i t i /serviceValidate (or /proxyValidate) yêu c u cho m t ph n h i d ch v

có ch a PGT IOU trong kh i <cas:proxyGrantingTicket> N u HTTP GET tr v

b t k mã tr ng thái khác, ngo i tr HTTP 3xx redirect, CAS ph i ph n h i /serviceValidate (or /proxyValidate) yêu c u cho 1 ph n h i d ch v mà không ph i

có m t kh i <cas:proxyGrantingTicket> CAS có th làm theo b y k HTTP

nh các callback url cung c p trên xác nh n trong kh i <proxy> ph i cùng m c thông qua vào /serviceValidate (or /proxyValidate) là than s

D ch v sau khi nh n 1 PGTIOU do CAS ph n h i và c 1 PGT, 1 PGT IOU

ph

M t PGT là 1 chu i ng u nhiên s d ng b i 1 d ch v c PT cho

vi c ti p c n d ch v back-end thay m t cho 1 client PGT có th c s d ng b i các d ch v c nhi u PT PGTs không ph i là 1 ticket th i gian s d ng

PGT ph i h t h n khi client có xác th c các b n ghi ra u nhi m c a CAS.

PGT nên b u v i các ký t "PGT-"

URL ví d c a /serviceValidate

1856339-aA5Yuvrxzpv8Tau1cYQ7

1856339-aA5Yuvrxzpv8Tau1cYQ7&renew=true

https://server/cas/serviceValidate?service=http://www.service.com&ticket=ST-t qua m https://server/cas/serviceValidate?service=http://www.service.com&ticket=ST-t callbackURL cho proxying:

1856339-aA5Yuvrxzpv8Tau1cYQ7&pgtUrl=https://my-server/myProxyCallback 2.2.4.6 /proxyValidate [CAS 2.0].

https://server/cas/serviceValidate?service=http://www.service.com&ticket=ST-Làm vi c gi i tr nó làm cho proxy ticket có

hi u l c Tham s và mã l Khi thành công, ph n h i ch a PGT và danh sách các proxy cái mà vi c xác th c th c thi Nh c vi ng

- targetService [B t bu c] - nh danh d ch v c a d ch v

back-ý r ng, không ph i t t c các service back-end là d ch v nh n

d ng d ch v này s không ph i luôn luôn là m nh

- BAD_PGT - các PGT cung c p không h p l

- INTERNAL_ERROR - m t l i n i b x y ra trong quá trình ticket validation

i v i t t c các mã l i, khuy n ngh r ng, CAS cung c p tin chi ti

trong ph n body c a kh i <cas:authenticationFailure> c a ph n h i XML

URL example of /proxy

c p m t ST(service ticket) cung c p t t

c u ki n khác nhau t c

trên máy client TGC s b phá h y và yêu c u ti p theo vào /login nh p s

n khi user thi t l p m t SSO

/validate Ki m tra tính h p l c a service ticket

/validate là 1 ph n c a giao th c CAS

lý xác th c proxy

/serviceValidate Ki m tra tính h p l c a m t ST và tr

v m n XML( XML-fragment )

/proxyValidate Th c hi n các nhi m v

/serviceValidate và b sung xác nh n PT(proxy ticket)

và s c xác th c proxy v i các d ch

v back-end

/samlValidate

/services/add.html M t ch n tr B sung thêm

/services/logout.html Thoát kh i trang qu n tr

/services/loggedOut.html Thoát kh i trang qu n tr t trang d ch

v

/services/deleteRegisteredService.ht

ml

Xóa các tham s d ch v d

trang hi n th Login URL cho nhà cung

c nh OpenID

2.2.6 CAS Entities.

Ticket-granting ticket (TGT):

thông tin cung c p s c ch ng th c thành công 1 TGT là 1 truy c p chính vào

l p d ch v c a CAS N u không có TGT thì user c a CAS s c b t

c u gì TGT là 1 chu i ng u nhiên v i ti n t - c thêm vào

1 HTTP Cookies trên s thành l p c a c SSO và b t c khi nào user truy

c p vào các ng d ng khác nhau thì cookies này s g auto-login cho user

Ticket Granting Cookie (TGC):

TGC là 1 cookies c t b i CAS trên s kh i t o phiên làm

vi c c SSO Cái Cookies này duy trì tr p cho client và

ng t i 1 ng d ng khác thì cookies s ki m tra auto-login cho

user này TGC s b phá h phá h y khi client click vào /logout Giá tr c a TGC nên b u v -

web yêu c u trong b nh cache N nó s trang v

không g i thêm yêu c n máy ch i vì các proxy hoàn toàn ch n

d t các kênh giao ti c coi là 1 công ngh

Trong CAS, proxy là 1 d ch v mu n truy c p vào các d ch v khác thay m t

c bi c t o ra t CAS trên 1 trình bày c a d ch v h p l TGT

và 1 d ch v nh danh (các giá tr c a tham s a /proxy url) cho d ch v

PT là m t chu i ng u nhiên mà m t d ch v s d t ch ng ch

c quy n truy c p vào m t d ch v back-end thay m t cho m t client

PT nên b u v i các ký t

-Proxy-granting Ticket (PGT):

c t CAS khi xác nh n c a 1 ST ho c 1 PT N u m t d ch vmong mu n y quy n ch ng th c cho client t i 1 d ch v back-end, nó ph i có

c 1 PGT S c x lý thông qua m t proxy callback URL

nh các d ch v trong back-end sau là proxy ch ng th c c a client D ch v back- quy nh có hay không ch p nh n các thông tin d a vào vi nh g i l i các URL

Proxy-Granting Ticket IOU (PGTIOU):

trong ph n c cung c p b i /serviceValidate và /proxyValidate s d

liên k m t ST ho c x c nh n PT v i 1 PGT c th Mô t c a quá trình này

yêu c u sau khi nh c 1 PGTIOU trong ph n h i CAS, c 1 PGT và 1 PGTIOU

s d ng PGT cho vi c các PT, n i yêu c u nh n di n chính xác

Ticket granting ticket IOU (TGTIOU):

Trên 1 ticket validation, 1 d ch v c a th yêu c u 1 PT Trong CAS 2, con

yêu c u Proxy callback URL này ph i trên 1 kênh an toàn Chúng ta xác mình ch ng ch c a nó Kh n callback này xác nh l i trong xác nh n ticket ph n ng TGTIOU T ph n ng, các d ch v m r ng t TGTIOU và s d tra c u

Login Ticket (LT):

i ch p nh n ch ng ch cho username/password M c

n s phát l i các thông tin do l i trong trình duy t, LT c p

b i /login ph i là duy nh t và nên b u các ký t

-T t các các CAS tickets và giá tr c a G-TC ph i bao g m d li u ng u nhiên không là 1 ticket có th c trong th i gian h p lý thông qua các

cu c t n công brute-force [http://vi.wikipedia.org/wiki/Brute_force] i

ch a các ký t t t p h p {A-Z, a-z, 0-9, and ký t c bi t ?-'} Ticket-granting ticket, service tickets, proxy tickets and login tickets ch ph i có giá tr trong 1 l

i dùng nh p username và password p các thông tin

c truy n cho CAS server thông qua giao th c HTTPS ho c HTTP (tùy theo cách

t)

th c cookie TGC này s c s d SSO v i t t c các ng d ng

Truy c p ng d ng

i dùng truy c p vào ng d ng ng th c v i CAS server

- i dùng truy xu t ng d ng thông qua trình duy t,

- ng d ng l y TGC t trình duy t và chuy n nó cho CAS server thông qua giao th c HTTPS/HTTP

- N u TGC này là h p l , CAS server tr v 1 ST cho trình duy t, trình duy t truy n ST v a nh n cho ng d ng

CAS

- CAS s tr v ID c i dùng cho ng d ng, m thông báo