tìm hiểu hệ thống đăng nhập một lần sso

ĐỒ ÁN TỐT NGHIỆP Tìm hiểu hệ thống đăng nhập một lần SSO - Single Sign On

MỤC LỤCMỤC LỤC.............................................................................................................1

DANH MỤC CÁC TỪ VIẾT TẮT.....................................................................4

LỜI NÓI ĐẦU......................................................................................................7

CHƯƠNG I :TỔNG QUAN VỀ SINGLE SIGN ON.......................................9

1.1. Tìm hiểu Single Sign On.....................................................................................9

1.1.1. Tại sao Single Sign On?...................................................................................9

1.1.2. Khái niệm......................................................................................................10

1.1.3. Các khái niệm quan trọng của Single Sign On.............................................10

1.1.4. Ý nghĩa SSO.................................................................................................12

1.3. SSO trên các ứng dụng không trên nền tảng web.......................................15

Chương II : CÁC VẤN ĐỀ AN TOÀN CỦA SSO..........................................17

2.1. Kiến trúc SSO....................................................................................................17

2.1.1. Kiến trúc SSO cho các ứng dụng Internet....................................................17

2.1.2. Kiến trúc SSO cho mạng nội bộ...................................................................18

2.2. Các vấn đề an toàn với SSO.............................................................................21

2.2.1. Lỗ hổng an ninh............................................................................................21

2.2.2. Các kiểu tấn công vào hệ thống SSO............................................................22

2.2.3. Tăng cường an toàn bằng các chính sách.....................................................24

2.3. Tăng khả năng an toàn với giao thức SAML Single Sign On.......................25

2.3.1. Giới thiệu SAML..........................................................................................25

2.3.2. Bí mật,Toàn vẹn............................................................................................26

2.3.3. Bảo mật kênh truyền:....................................................................................27

2.3.4. Theo dõi người sử dụng................................................................................28

2.4. Lược đồ giao thức..............................................................................................29

2.4.1. Liên hệ các trang web nguồn........................................................................29

2.4.2. Chuyển đến trang đích..................................................................................30

2.4.3. SAML Request.............................................................................................30

2.4.4. SAML Response...........................................................................................31

2.4.5. Đáp ứng yêu cầu từ trình duyệt...................................................................32

2.5. Một số lỗ hổng có thể lợi dụng để thực hiện tấn công....................................32

2.5.1. Hijacking / Replay Attack............................................................................32

2.5.2. Tấn công xen giữa (Man-in-the-Middle)......................................................33

Trang 1


2.5.3. HTTP Referrer Attack..................................................................................35

2.5.4. Khai thác lỗ hổng của SSL/TSL...................................................................35

2.6. Bảng đánh giá các sản phẩm SSO (open source)............................................35

2.6.1. Tổng quan.....................................................................................................35

2.6.2. CAS (Central Authentication Service).........................................................35

2.6.3. Open source được phát triển bời đại học Stanford.......................................38

2.6.4. Cosign...........................................................................................................39

Chương III : CENTER AUTHENCATION SERVICE.................................42

3.1 Khái niệm Center Authencation Service (CAS).............................................42

3.2. CAS Protocol.....................................................................................................43

3.2.1. URI -/login đăng nhập..................................................................................43

3.2.2. Các thông số.................................................................................................43

3.2.3. Các ví dụ về tham số đăng nhập:..................................................................44

3.2.4. Chứng thực Username/Password..................................................................44

3.2.5. Chứng thực tin cậy:.......................................................................................44

3.2.6. Phổ biến các thông số:..................................................................................44

3.2.7. Các thông số xác thực tên người dùng,mật khẩu:.........................................44

3.2.8. Logout:..........................................................................................................45

3.3. /Proxy..................................................................................................................46

3.4. CAS Tickets........................................................................................................48

3.5. Nguyên tăc hoạt động cua CAS........................................................................49

3.5.1. Chứng thực người dùng với CAS server......................................................49

3.5.2. Truy cập vào ứng dụng.................................................................................50

3.6. Chức năng proxy...............................................................................................55

3.6.1. Proxy CAS....................................................................................................55

3.6.2. Cơ chế Proxy:...............................................................................................55

3.6.3. Hoạt động......................................................................................................57

3.7. Kiến trúc CAS....................................................................................................58

3.7.1. Sơ đồ tổng quát.............................................................................................58

3.7.2. Login Flow....................................................................................................60

3.7.3. Proxy Flow....................................................................................................62

3.7.4. Logout Flow..................................................................................................62

3.8. Xác thực trong CAS..........................................................................................63

Trang 2


3.8.1. Xác thực CAS dựa trên cơ sở dữ liệu...........................................................63

3.8.2. Chứng chỉ x509.............................................................................................63

3.8.3. Giao thức Kerberos.......................................................................................64

3.8.4. Một tập tin.....................................................................................................64

3.9. Triển khai ứng dụng CAS:...............................................................................65

KẾT LUẬN.........................................................................................................67

TÀI LIỆU THAM KHẢO.................................................................................69

PHỤ LỤC.............................................................................................................70

Trang 3


DANH MỤC CÁC TỪ VIẾT TẮT

SSO Single Sign On

OpenSSO Open Single Sign On

LDAP Lightweight Directory Acess Protocol

CAS Central Athentication Service

URI Uniform Resource Identifier

URL Uniform Resource Locator

ESSO Enterprise Single Sign On

CRM Customer Relationship Management

Trang 4


DANH MỤC CÁC BẢNG

Bảng 2.1: CAS(Central Authentication service)..................................................37

Bảng 2.2: Open source được phát triển bởi đại học Stanford..............................39

Bảng 2.3: Cosign..................................................................................................41

Bảng 3.1: /SAMLValidate:..................................................................................47

Trang 5


DANH MỤC CÁC HÌNH VẼHình 1.1: Người dùng sử dụng Single Sign On.............................................................10

Hình 1.2: Ứng dụng single sign on sử dụng OpenID..........................................................13

Hình 1.3: Single Sign On trên windows........................................................................15

Hình 2.1:Kiến trúc SSO cho ứng dụng Internet.............................................................17

Hình 2.2: Kiến trúc SSO cho mạng nội bộ....................................................................18

Hình 2.3: Kiến trúc SSO cho nhiều miền.......................................................................19

Hình 2.4: Kiến trúc SSO chéo........................................................................................20

Hình 2.5: Tấn công Session Hijacking...........................................................................23

Hình 2.6: Tấn công Man in the Middle..........................................................................24

Hình 2.7: Giả mạo DNS.................................................................................................24

Hình 2.8: SAML Single Sign On...................................................................................26

Hình 3.1 : Đăng nhập CAS............................................................................................50

Hình 3.2 : Chứng thực một trình duyệt đển máy chủ CAS...........................................50

Hình 3.3 : Truy cập vào ứng dụng.................................................................................51

Hình 3.4: Trình duyệt truyền ST cho ứng dụng.............................................................51

Hình 3.5 : Ứng dụng truyền ST cho CAS......................................................................52

Hình 3.6 : Người dùng truy cập vào ứng dụng khi đa chứng thực với CAS.................52

Hình 3.8: CAS trả về cho trình duyệt đồng thời TGC và ST.........................................53

Hình 3.9 : Truyền ST cho ứng dụng..............................................................................54

Hình 3.10:Người dùng truy cập vào ứng dụng mà chưa chứng thực với CAS..............54

Hình 3.11: Cơ chế Proxy................................................................................................55

Hình 3.12: Thu hồi TMP của một proxy CAS từ máy chủ CAS..................................57

Hình 3.13: Xác Nhận của PT người dùng CAS truy cập bởi một proxy CAS..............58

Hình 3.14: Sơ đồ CAS...................................................................................................58

Hình 3.15 : Login Flow..................................................................................................60

Hình 3.16 : Proxy Flow..................................................................................................62

Hình 3.17 : Logout Flow................................................................................................62

Hình 3.18: Mô hình triển khai ứng dụng........................................................................65

Trang 6


LỜI NÓI ĐẦU

Ngày nay, với sự phát triển nhảy vọt của khoa học công nghệ nói chung của

ngành tin học nói riêng, với những tính năng ưu việt, sự tiện dụng và được ứng

dụng rộng rai, tin học ngày nay là một phần không thể thiếu được của nhiều

ngành trong cuộc sống xây dựng và phát triển xa hội. Khi xa hội càng phát triển

con người càng cần đến sự quan tâm và chia sẻ thông tin. Chính điều này đa tạo

cơ hội cho mạng máy tính phát huy hết những tiện ích vốn có của mình.

Hiểu rõ được tầm quan trọng và những ưu điểm vượt trội của việc bảo mật,

trao đổi thông tin của hệ thống mạng máy tính mà số lượng các công ty, doanh

nghiệp thiết lập, sử dụng hệ thống mạng ngày càng nhiều. Từ những công ty có

quy mô nhỏ, vừa đến các doanh nghiệp, tập đoàn tầm cỡ, không nơi nào không

có sự xuất hiện của hệ thống mạng trong khâu quản lý công việc của nhân viên,

trong công tác quản lý, bảo mật và lưu trữ dữ liệu của công ty hay các thông báo,

thông tin giữa các cá nhân trong cùng một tổ chức.

Khi sử dụng càng nhiều các dịch vụ người dùng phải đối mặt với vấn đề khi

sử dụng các dịch vụ riêng biệt cần có một tài khoản và mật khẩu riêng, mỗi lần

sử dụng một dịch vụ khác nhau người dùng phải đăng nhập lại điều này dẫn đến

các nguy cơ mất an toàn trên mạng, người dùng dễ bị ăn cắp tài khoản hay quên

mật khẩu. Thấy được tầm quan trọng của vấn đề em đa tìm hiểu và nghiên cứu

đề tài :”Tìm hiểu Single Sign On”. Đề tài tập trung tìm hiểu và triển khai giải

pháp đăng nhập một lần giúp người sử dụng chỉ cần dùng một tài khoản và mật

khẩu đăng nhập một lần duy nhất có thể sử dụng được tất cả các ứng dụng tin

cậy.

Thấy được tầm quan trọng và ý nghĩa thực tiễn của đề tài, qua ba tháng tìm

hiểu nghiên cứu thực hiện đề tài. Em đa hoàn thành đề tài với những nội dung:

Tìm hiểu tổng quan về Single Sign On, độ an toàn hệ thống và triển khai sản

phẩm Central Authentication Service (CAS) ứng dụng vào thực tế.

Chương I: Tổng quan về Single Sign On

Trình bài khái quát về Single Sign On.

Ý nghĩa thực tiễn của Single Sign On.

Trang 7


Chương II: Các vấn đề an toàn cua Single Sign On

Tìm hiểu các kiến trúc Single Sign On

Các lỗ hổng an ninh khi sử dụng Single Sign On.

Giao thức SAML Single Sign On.

Các phương pháp tấn công và giải pháp an toàn khi sử dụng SAML

Single Sign On.

Chương III: Central Authentication Service

Tổng quan chung về phần mềm CAS.

Giao thức CAS.

Kiến trúc CAS.

Triển khai ứng dụng.

Do nội dung đồ án rộng và bao gồm nhiều kiến thức mới, thời gian và kiến

thức còn hạn chế, việc nghiên cứu chủ yếu dựa trên tài liệu nước ngoài thuyết

nên chắc chắn đề tài không tránh khỏi những thiếu sót. Em rất mong nhận được

sự đóng góp ý kiến của thầy cô giáo và bạn bè.

Với lòng biết ơn sâu sắc, em xin chân thành cảm ơn Th.s Nguyễn Anh

Tuấn,Th.s Nguyễn Quốc Toàn các anh chị trong công ty Cổ phần phần mềm

Việt, các thầy cô giáo trong khoa An Toàn Thông Tin Học Viện Kỹ Thuật

Mật Mã đa nhiệt tình hướng dẫn giúp đỡ em hoàn thành đồ án này.

Cuối cùng tôi xin cảm ơn bạn bè, người thân đa luôn bên, kịp thời động viên

và giúp đỡ tôi trong thời gian vừa qua.

Em xin chân thành cảm ơn !

Hà Nội, Tháng 6 năm 2011

Sinh viên

Bùi Đăng Tân

Trang 8


Chương ITỔNG QUAN VỀ SINGLE SIGN ON

1.1. Tìm hiểu Single Sign On

1.1.1. Tại sao Single Sign On?

Hệ thống CNTT ngày càng phát triển rộng khắp và ứng dụng vào tất cả các

lĩnh vực.Người sử dụng phải đối mặt với vấn đề ngày càng phức tạp là phải nhớ

nhiều tài khoản và mật khải để thực hiện công việc của họ.

Người dùng thường phải đăng nhập vào nhiều hệ thống, cần phải có một

lượng tương đương số lần đăng nhập, mỗi dịch vụ trong các hệ thống đó có thể

bao gồm tài khoản và mật khẩu khác nhau. Điều này dẫn đến người dùng phải

đối mặt với các vấn đề:

Quên tài khoản: do sử dụng nhiều tài khoản và mật khẩu để đăng nhập các

ứng dụng.

Dùng một tài khoản và mật khẩu cho các hệ thống dẫn đến nguy cơ mất an

toàn.

Sử dụng Single Sign On:

Sử dụng nhiều phương pháp xác thực: Là cần thiết để nhập thông tin đăng

nhập của mình ngoài phương pháp nhập tài khoản và mật khẩu khi truy

cập vào mỗi ứng dụng.

Đa phương diện: Tài khoản người dùng là duy nhất trong tổ chức này và

nó sẽ được mong muốn sử dụng nó truy cập vào tài nguyên máy tính từ

các tổ chức khác có thể được sử dụng cùng một tài khoản.(sử dụng tài

khoản yahoo, gmail, facebook …sử dụng OpenId).

Quyền: Xác thực quyền hạn truy cập các tài nguyên của người dùng khi

truy cập các ứng dụng khác nhau.

Xác thực tập trung: Trên một máy chủ duy nhất để xác thực tài khoản

người dùng thông qua giao thức đa được ma hóa.

Trang 9


Trình duyệt sử dụng http chuyển hướng trình duyệt của người dùng giữa

các ứng dụng mà không cần đăng nhập tài khoản và mật khẩu.

1.1.2. Khái niệm

Single Sign On: Người sử dụng dùng tài khoản đăng nhập chỉ một lần và có

thể sử dụng nhiều ứng dụng trong cùng một tổ chức một cách liên tục mà không

cần phải nhập lại thông tin cho mỗi ứng dụng.

L oginuser2/pasw

o rd2

Loginuser3/ pasword3

application 1 application 2 application 3 application 1 application 2 application 3

Loginuser/ pasword

Trình duyet nguoi dùng Trình duyet nguoi dùng

Hình 1.1: Người dùng sử dụng Single Sign On

Ví dụ: Người dùng sử dụng nhiều dịch vụ: Email,forum,web…khi chưa có

Single Sign On thì với mỗi dịch vụ ta phải nhập thông tin để xác thực.Khi một tổ

chức đa thống nhất sử dụng Single Sign On cho hệ thống của họ thì người dùng

chỉ phải đăng nhập một lần vào bất kì ứng dụng nào trong hệ thống thì khi dùng

các ứng dụng khác người dùng không phải đăng nhập lại.

1.1.3. Các khái niệm quan trọng cua Single Sign On

Xác thực: Quá trình xác minh danh tính của người dùng, làm cho chắc

chắn rằng người dùng là họ. Chúng ta có thể sử dụng các phương pháp xác thực

như: username, password, thẻ thông minh, hay dùng sinh trắc học…

Ủy quyền: Là một quy trình nhằm xác minh rằng một người dùng biết

trước, có quyền lực để thao tác một quá trình hoạt động nào đó hay không.

Trang 10


Giấy chứng nhận: Là các chi tiết được cung cấp bởi một người dùng trong

quá trình xác thực vào ứng dụng.

Domain: Là sự nhận dạng vị trí của một máy tính trên mạng Internet nói

cách khác tên miền là tên của các mạng lưới, tên của các máy chủ trên mạng

Internet.

Bảo vệ dữ liệu: Dữ liệu của hệ thống không thể cho tất cả mọi người có

thể truy cập. Người dùng cần phải thông qua xác thực và ủy quyền trước khi truy

cập vào một nguồn tài nguyên bảo vệ.

Cookie: Giao thức HTTP là một chuẩn giao thức không hỗ trợ lưu trạng

thái. Điều này có nghĩa là sau khi trình duyệt kết nối tới máy chủ và lấy xong dữ

liệu thông qua HTTP, máy chủ liền tắt ngay kết nối mà không buồn quan tâm tới

việc dữ liệu đó sẽ được xử lý, lưu trữ ra sao trên máy khách. Chính vì sự “vô

tình” này đa dẫn đến những tình huống phát sinh, chẳng hạn như trong một phiên

làm việc, làm thế nào để biết được người sử dụng đó vừa mới truy cập lên máy

chủ, hay người sử dụng đa lựa chọn những gì ở những lần truy cập trước đó? Để

giải quyết vấn đề này, các nhà phát triển ứng dụng Web đa phải khai sinh một

công cụ khác, gọi là cookie.

Cookie là một (hoặc một số) thông tin được những nhà thiết kế web ấn định

yêu cầu trình duyệt phải ghi lại ở đâu đó trên máy khách. Mỗi khi trình duyệt kết

nối tới máy chủ, các thông tin lưu trong cookie sẽ được gửi cùng lên máy chủ.

Nhờ những thông tin này, các nhà thiết kế web sẽ theo dõi được những hành vi

của người sử dụng thông qua cookie.

Trước đây rất nhiều người nhầm tưởng cookie là các đoạn ma độc hại, nhưng

thực tế thì không phải như vậy. Về bản chất, cookie chỉ là các bản ghi lưu trữ dữ

liệu chứ không hề có chứa bất kỳ một đoạn ma chương trình nào cả. Tuy nhiên,

nhiều nhà phát triển ứng dụng Web thiếu kinh nghiệm đa lựa chọn cookie để lưu

trữ những thông tin mang tính chất nhạy cảm (mật khẩu, số tài khoản cá nhân...).

Vì vậy chúng rất dễ bị các chương trình gián điệp chạy trên máy khách thu thập

và đem ra sử dụng một cách mờ ám, gây hại cho người dùng. Nếu bạn là người

lập trình Web chuyên nghiệp, hay cẩn thận với những tình huống này.

Một cookie thường có những thông tin sau đây:

Trang 11


Tên cookie (name): do người lập trình website thiết lập để phân biệt giữa

các cookie.

Domain: xác định tên miền sẽ được sử dụng để gửi cookie đi.

Đường dẫn: xác định đường dẫn ở trên Website

Thời điểm hết hạn (expires): xác định thời điểm cookie sẽ bị hết hiệu lực

trên trình duyệt.

Bảo mật: nếu giá trị này đựơc thiết lập bên trong cookie, thông tin sẽ đựơc

ma hoá trong quá trình truyền giữa server và browser.

Giá trị (value): xác định dữ liệu được lưu trong cookie. Giá trị này sẽ được

chuyển tới máy chủ có địa chỉ xác định trong đường dẫn hoặc tên miền.

Các giá trị này ko chứa các khoảng trắng, dấu chấm, phẩy và bị giới hạn

trong khoảng 4k.

Cookie có thể được sử dụng để lưu một số thông tin như: tài khoản (tên truy

cập và mật khẩu) của người sử dụng trên website, các thông tin lựa chọn giỏ

hàng (trên các website mua bán trực tuyến), các mục chọn hay những thông tin

khác do nhà thiết kế web chỉ định.

Sau khi có một cookie, nếu người dùng duyệt để một ứng dụng khác nhau đó

là một phần của Single Sign On, thông tin được lưu trong cookie sẽ được trình

duyệt sử dụng để trực tiếp đăng nhập vào ứng dụng khác, nếu người sử dụng

được phép truy nhập vào.

1.1.4. Ý nghĩa SSO

Tránh việc nhớ nhiều thông tin đăng nhập (username & password) khi

dùng nhiều dịch vụ.

Tiết kiệm thời gian khi tái lập lại mật khẩu cho một người dùng (identity

user).

Bảo mật tất cả các cấp độ của việc thoát hay truy xuất vào hệ thống.

Người phát triển ứng dụng không cần phải hiểu và thực hiện nhận dạng

bảo mật trong ứng dụng của họ.

1.2. Các loại Single Sign On

Hầu hết các sản phẩm SSO trên thế giới có thể được phân loại thành hai loại

dựa trên kiến trúc:

Trang 12


1.2.1. Trên web (Enterprise SSO)

SSO trên web được sử dụng dưới các dạng:

Single Domain: Khi xác thực thành công vào domain.com, người dùng

đồng thời được xác thực vào các sub-domain.domain.com tồn tại.

Multi Domain: khi xác thực thành công vào facebook.com, người dùng

đồng thời được xác thực vào example.com.

Các SSO được sử dụng phổ biến trên web hiện nay:

OpenID: hệ thống đăng nhập một lần không có tính tập trung. Đối với

những trang web có sử dụng OpenID thì người sử dụng không cần phải nhớ các

thông tin về username và password cho riêng trang đó nữa. Thay vào đó họ chỉ

cần đăng ký trước 1 tài khoản OpenID tại một trong những nhà cung cấp

OpenID, hay thường gọi là i-broker. Do OpenID không mang tính tập trung nên

bất kỳ trang web nào cũng có thể sử dụng được OpenID như là một cách đăng

nhập cho người dùng. Các hệ thống lớn đang sử dụng là : yahoo, google,

facebook…

Hình 1.2:Ứng dụng single sign on sử dụng OpenID

Open Single Sign-On (OpenSSO) hoạt đông dựa trên Token: Là một sản

phẩm open source của SUN. Nó là một sản phẩm đơn lẻ, kết hợp các tính năng

của Sun Java System. Access Manager, Sun Java System Fedearation Manager

và Sun System SAML v2 Java Plugin.

Java Open Single Sign On ( JOSSO).

Central Authenticate Service (CAS) hoạt đông dựa trên Ticket.

Trang 13


1.2.2. Đặc điểm cua SSO trên web (Enterprise SSO)

Một WebSSO đúng nghĩa phải là một dịch vụ chứng thực tập trung đáp ứng

đồng thời các yêu cầu sau:

Đăng nhập một lần với một tài khoản duy nhất để chứng thực vào các ứng

dụng web khác nhau sử dụng dịch vụ WebSSO. Các ứng dụng web có thể chạy

trên nhiều domain khác nhau. Ví dụ: khi bạn đăng nhập vào hotmail.com thì bạn

sẽ không cần đăng nhập một lần nữa khi vào msn.com.

Web SSO yêu cầu một hệ thống network ổn định và đảm bảo vận hành

xuyên suốt.

Phải sử dụng SSL và các phương thức ma hóa bất đối xứng. Nếu một dịch

vụ chứng thực mà không dùng SSL cho các phiên chứng thực thì đều bị coi là

không an toàn. Và đây cũng là một mục tiêu quan trọng của một ứng dụng web

khi dùng dịch vụ chứng thực tập trung.

Đăng xuất toàn bộ hệ thống SSO khi click vào button [Sign Out] hoặc tự

động SignOut khi tắt trình duyệt.

Trong SSO cũng như chứng thực thông thường, đều cần database để lưu trữ

thông tin người dùng. Còn SSO hoàn toàn không dùng database để lưu vết

session. SSO phải đảm nhiệm một nhiệm vụ rất lớn trong việc chứng thực toàn

bộ người dùng cho các ứng dụng web. Do vậy vấn đề bảo mật luôn đặt lên hàng

đầu, nếu SSO gặp một sự cố nào đó thì toàn bộ các partners (ứng dụng web dùng

SSO) sẽ không thể đăng nhập được.

1.2.3. Nguyên lí hoạt động cua web SSO

Bước 1 : Người dùng đăng nhập vào tài khoản tại url của dịch vụ SSO

Authentication Service.Sau khi đăng nhập thành công -> bước 2

Bước 2 : Authentication Service sẽ thực hiện việc sinh ra Authentication

Token. Đây là một chuỗi chứa thông tin chứng thực (không chứa password) và

thông thường được ma hóa bằng DES hoặc RSA.

Bước 3 : Authentication Token sẽ được truyền tải trên http (không ma hóa

SSL) giữa ứng dụng web (partner) và Authentication Service. Trên mỗi ứng

dụng web sẽ có một SSOAgent, có nhiệm vụ xử lý Authentication Token và

kiểm tra việc chứng thực. Trong quá trình này session cookie sẽ được tạo tại

Trang 14


trình duyệt của người dùng đăng nhập nếu SSOAgent kiểm tra Authentication

Token thành công.

Bước 4 : [Sign Out]: Khi chứng thực tự động vào một partner,

Authentication Service sẽ lưu lại thông tin partner này, khi người dùng click

[Sign Out] thì dịch vụ xác thực sẽ lần lượt Sign Out (xóa toàn bộ session cookie

của ứng dụng sử dụng SSO).

1.3. SSO trên các ứng dụng không trên nền tảng web

Các doanh nghiệp trong những ngày này thường có Microsoft Windows ®

người sử dụng máy tính để bàn truy cập các ứng dụng doanh nghiệp đa dạng,

ứng dụng thường có yêu cầu an ninh khác nhau và phải đăng nhập cho các ứng

dụng khác nhau. SSO giữa Oracle Access Manager và IBM WebSphere

Application Server. Phổ biến nhất hiện nay là hệ thống của Microsoft sử dụng

cho windows, Microsoft Office SharePoint Server.

Hình 1.3: Single Sign On trên windows

Microsoft cung cấp một giải pháp xác thực cho phép người dùng Windows sử

dụng Microsoft Internet Explorer (IE) để truy cập tài nguyên trên Microsoft

Internet Information Server (IIS) mà không cần phải xác thực lại. Đơn đăng ký

giải pháp dựa trên cơ chế xác thực bản quyền Microsoft HTTP.

Người dùng đăng ký và nền tảng hỗ trợ: WebSEAL SPNEGO hỗ trợ cung

cấp đăng ký từ Internet Explorer chạy trên Windows máy trạm cấu hình vào

miền Active Directory để WebSEAL.

Single sign on trong SharePoint: Cung cấp lưu trữ và lập bản đồ của các

thông tin như tên tài khoản và mật khẩu để các ứng dụng dựa trên cổng thông tin

trang web có thể lấy thông tin từ các bên thứ ba ứng dụng và hệ thống back-end.

Trang 15


Ví dụ, Enterprise Resource Planning (ERP) và hệ thống quản lý quan hệ khách

hàng (CRM) .

Kết chương I:

Nội dung của chương đa trình bày tổng quát các khái niệm quan trọng về

single sign on , các dạng SSO đang được sử dụng trên thế giới . Đăng nhập một

lần đang được các hang công nghệ sử dụng rộng rai trong các ứng dụng phần

mềm và đặc biệt trong các dịch vụ ứng dụng web. Bên cạnh tính thuận tiện, đơn

giản tiện lợi cho người dùng cũng có những nhược điểm về mặt an toàn. Chương

sau của đồ án sẽ trình bày rõ hơn về vấn đề an toàn của Single sign on.

Trang 16


Chương II

CÁC VẤN ĐỀ AN TOÀN CỦA SSO

2.1. Kiến trúc SSO

2.1.1. Kiến trúc SSO cho các ứng dụng Internet

Hình 2.1:Kiến trúc SSO cho ứng dụng Internet

Mô tả các vị trí thành phần khác nhau trong một đơn vị sử dụng các ứng dụng

SSO. Ứng dụng ra ngoài Internet phải đối mặt với rất nhiều cuộc tấn công và do

đó bảo vệ theo chiều sâu được sử như một nguyên tắc trong kiến trúc SSO để

bảo đảm an ninh tối đa cho các ứng dụng. Các web server và ứng dụng cho phép

Trang 17


truy cập vào Internet nên được đặt trong phân vùng riêng (DMZ). Các công cụ

truy cập, quản lý máy chủ và lưu trữ dữ liệu đặt trong mạng nội bộ.

Các giao tiếp giữa người dùng và máy chủ web có thể được bảo mật bằng

cách sử dụng SSL(Secure Socket Layer) tránh bị ăn cắp user đăng nhập và mật

khẩu được truyền đi dưới dạng văn bản rõ.

Sử dụng tường lửa chỉ cho phép các máy chủ ứng dụng giao tiếp với nhau tại

các cổng được chỉ định và từ chối tất cả các truy cập khác. Điều này làm giảm cơ

hội của chương trình độc hại như Trojan gửi các lưu lượng giả vào các máy chủ

ứng dụng từ mạng Internet.

Thường xuyên cập nhật các bản vá cho các máy chủ một cách sớm nhất ngay

khi các bản vá được phát hành.

Cập nhập các bản vá cho máy trạm trong mạng LAN, đặc biệt là nâng cấp

trình duyệt không cho phép các trình duyệt đa quá cũ trên máy trạm được truy

cập vào server. Điều này giúp ngăn chặn được kẻ tấn công lợi dụng các lỗ hổng

trình duyệt cũ để tấn công vào hệ thống.

2.1.2. Kiến trúc SSO cho mạng nội bộ

Hình 2.2: Kiến trúc SSO cho mạng nội bộ

Trang 18


Tương tự như kiến trúc SSO cho các ứng dụng ra Internet, nhưng tất cả các

thành phần của kiến trúc được đặt trong mạng nội bộ. Các giải pháp an toàn cho

kiến trúc internet được sử dụng theo chiều sâu.

Kiến trúc SSO cho nhiều miền

Hình 2.3: Kiến trúc SSO cho nhiều miền

Sử dụng một miền chính và các miền phụ trợ, người dùng sẽ được xác thực

chung nhưng sẽ chỉ truy cập được đến tài nguyên mà các miền ấn định chính

sách riêng cho từng người dùng, nhóm người dùng cụ thể. Nếu người dùng truy

cập vào các dữ liệu không được phép thì sẽ diễn ra theo các bước:

Người dùng sử dụng trình duyệt của mình để truy cập vào một

nguồn tài nguyên được bảo vệ bởi một chính sách truy cập trong các

miền phụ.

Miền phụ gửi một phản ứng để người dùng trình duyệt để chuyển

hướng đến miền chính để xác thực.

Truy cập miền chính qua thành phần xác thực người dùng, quyền

các truy cập để kiểm tra và cấp phép.

Gửi thông tin xác thực và ủy quyền trở lại trình duyệt của người sử

dụng, sau khi nhận được thông tin từ các công cụ truy cập, cookie

được thiết lập trên trình duyệt của người dùng cho các tên miền

chính.

Trang 19


Khi người dùng nhấp vào nút đăng xuất trên một trang web trong miền phụ

các máy chủ web trong miền phụ sẽ hủy các cookie đặt cho người sử dụng và

chuyển hướng người dùng đến miền chính với các thông hủy cookie người dùng.

Các máy chủ web trong tên miền chính hủy các cookie của nó lưu cho người

sử dụng và người sử dụng thoát khỏi ứng dụng.

Kiến trúc SSO chéo

Hình 2.4: Kiến trúc SSO chéo

Cũng được tổ chức như các SSO thông thường nhưng có thêm phần xác thực

giữa các hệ thống SSO với nhau. Các bước xác thực như sau:

Người dùng truy cập một ứng dụng trên các trang web của ứng

dụng trên hệ thống SSO của mình.

Người sử dụng được xác thực và ủy quyền để truy cập ứng dụng

và được thiết lập một cookie trên trình duyệt của người dùng.

Người dùng sau đó nhấp chuột vào liên kết đưa người sử dụng

một ứng dụng duy trì trên một trang web đối tác (hệ thống SSO

khác)

Các công cụ kết nối sử dụng cookie của trình duyệt người dùng để

đóng gói nó như là một SAML(Security Assertion Markup

Language khẳng định, các ký hiệu nó và sau đó chuyển hướng nó

vào thành phần kết nối trong mạng SSO đối tác.

Trang 20


Hệ thống kết nối bên SSO đối tác xác nhận SAML được gửi từ đối

tác SSO đa được tin cậy, sau đó kiểm tra và cấp phép cho phép

người dùng truy cập vào ứng dụng.

2.2. Các vấn đề an toàn với SSO

2.2.1. Lỗ hổng an ninh

Khi đề cập đến lỗ hổng bảo mật và rủi ro, mối quan tâm chủ yếu quan tâm

đến tính an toàn của hệ thống là các thuộc tính quan trọng của an toàn thông tin:

Tính bí mật, tính toàn vẹn, tính xác thực, tính sẵn sàng. Sự tồn tại của các lỗ

hổng cho thấy hệ thống có nguy cơ bị các hacker lợi dụng lỗ hổng này có thể

được khai thác các thông tin người dùng trong cuộc tấn công. Các cuộc tấn công

có tính chất khác nhau tùy thuộc vào mức độ nghiêm trọng của các lỗ hổng này

đang được khai thác.

Các rủi ro

Rủi ro mật khẩu yếu: Sử dụng mật khẩu là phương pháp xác thực được sử

dụng phổ biến nhất hiện nay. Một mật khẩu được sử dụng nhiều lần và không

được thay đổi trong thời gian dài để truy cập vào các ứng dụng. Một phương

pháp thông thường dùng để tấn công các mật khẩu yếu là đoán mật khẩu bằng

cách sử dụng phương pháp tấn công từ điển. Việc sử dụng mật khẩu có ý nghĩa

quan trọng khi cho phép người dùng đăng nhập vào các ứng dụng. Có thể khắc

phục bằng cách thiết lập các chính sách mật khẩu mạnh.

Rủi ro của hình thức nhúng đăng nhập: Mô tả một kịch bản triển khai hợp

định danh nhà cung cấp mẫu đăng nhập được nhúng vào trong một trang trình

bày của một nhà cung cấp dịch vụ. Mặc dù người dùng có thể giống đăng nhập

bình thường nhưng trong quá trình đó thông tin của người dùng sẽ đưa trở lại

cho nhà cung cấp dịch vụ nhận dạng. Hình thức nhúng mang hiểm họa của việc

đào tạo người sử dụng làm điều sai trái.

Rủi ro của việc triển khai ra mạng Internet: Nếu một người sử dụng sử

dụng một trình duyệt để đăng nhập tài khoản dịch vụ SSO ở sân bay, bỗng dưng

hệ thống bị treo làm người dùng không thể thoát ra được. Người dùng bỏ đi và

sau khi hệ thống máy tính hoạt động bình thường trở lại bất kì ai tiếp xúc vật lí

với máy tính đó có thể truy cập trái phép vào các thông tin của người dùng và

Trang 21


điều này càng đặc biệt nguy hiểm khi sử dụng cho các mục đích bất hợp pháp.

Có thể tránh nó bằng cách đặt thời gian kết thúc phiên đăng nhập.

Rủi ro của mật ma yếu: Một trong những vấn đề gây nhiều tranh cai nhất

trong việc đảm bảo an toàn các dịch vụ web là các máy tính hiện đang cài đặt

trình duyệt nhưng nhiều trình duyệt chỉ hỗ trợ mật ma 40-bit. Mật ma 40-bit

được coi là yếu và có thể bị tấn công. Điều này đặt ra một nguy cơ từ thông tin

liên lạc ma hóa của người sử dụng có thể dễ dàng thu thông tin không được ma

hóa.

2.2.2. Các kiểu tấn công vào hệ thống SSO

Tràn bộ đệm

Một lỗi lập trình có thể gây ra một ngoại lệ truy nhập bộ nhớ máy tính và

chương trình bị kết thúc, hoặc khi người dùng có ý phá hoại, họ có thể lợi dụng

lỗi này để phá vỡ an ninh hệ thống. Các lỗi tràn bộ đệm có thể làm cho một tiến

trình đổ vỡ hoặc cho ra các kết quả sai. Các lỗi này có thể được kích hoạt bởi các

dữ liệu vào được thiết kế đặc biệt để thực thi các đoạn ma phá hoại hoặc để làm

cho chương trình hoạt động một cách không như mong đợi. Bằng cách đó, các

lỗi tràn bộ đệm gây ra nhiều lỗ hổng bảo mật (vulnerability) đối với phần mềm

và tạo cơ sở cho nhiều thủ thuật khai thác (exploit).

Session Hijacking

Session Hijacking là quá trình chiếm lấy một session đang hoạt động, nhằm

mục đích vượt qua quá trình chứng thực truy cập bất hợp lệ vào thông tin hoặc

dịch vụ của một hệ thống máy tính..

Khi một user thực hiện kết nối tới server qua quá trình xác thực, bằng cách

cung cấp ID người dùng và mật khẩu của mình. Sau khi người dùng xác thực, họ

có quyền truy cập đến máy chủ và hoạt động bình thường. Trong quá trình hoạt

động, người dùng không cần phải chứng thực lại. Kẻ tấn công lợi dụng điều này

để cướp session đang hoạt động của người dùng và làm cho người dùng không

kết nối được với hệ thống. Sau đó kẻ tấn công mạo danh người dùng bằng

session vừa cướp được, truy cập đến máy chủ mà không cần phải đăng nhập vào

hệ thống.

Trang 22


Khi cướp được session của người dùng, kẻ tấn công có thể vượt qua quá trình

chứng thực dùng, có thể ghi lại phiên làm việc và xem lại mọi thứ đa diễn ra. Đối

với cơ quan pháp lý, có thể dùng làm bằng chứng để truy tố, đối với kẻ tấn công,

có thể dùng thu thập thông tin như ID người dùng và mật khẩu. Điều này gây

nhiều nguy hại đến người dùng.

Vấn đề này càng đặc biệt nghiêm trọng với hệ thống SSO vì khi chiếm được

phiên kẻ tấn công có thể truy cập vào được các ứng dụng khác để khai thác

thông tin.

Hình 2.5: Tấn công Session Hijacking

Man in the Middle

Hoạt động bằng cách thiết lập các kết nối đến máy tính nạn nhân và relay

các message giữa chúng. Trong trường hợp bị tấn công, nạn nhân cứ tin tưởng là

họ đang truyền thông một cách trực tiếp với nạn nhân kia, trong khi đó sự thực

thì các luồng truyền thông lại bị thông qua host của kẻ tấn công. Và kết quả là

các host này không chỉ có thể thông dịch dữ liệu nhạy cảm mà nó còn có thể gửi

xen vào cũng như thay đổi luồng dữ liệu để kiểm soát sâu hơn những nạn nhân

của nó.

Một số kiểu tấn công Man in the Middle hay được sử dụng : ARP Cache,

DNS Spoofing, chiếm quyền điều khiển (hijacking) HTTP session...

Trang 23


Hình 2.6: Tấn công Man in the Middle

Giả mạo DNS

Giả mạo DNS là một kỹ thuật MITM được sử dụng nhằm cung cấp thông tin

DNS sai cho một host để khi người dùng duyệt đến một địa chỉ nào đó.

Giả mạo DNS ID: Mỗi truy vấn DNS được gửi qua mạng đều có chứa một số

nhận dạng duy nhất, mục đích của số nhận dạng này là để phân biệt các truy vấn

và đáp trả chúng. Điều này có nghĩa rằng nếu một máy tính đang tấn công của

chúng ta có thể chặn một truy vấn DNS nào đó được gửi đi từ một thiết bị cụ thể,

thì tất cả những gì chúng ta cần thực hiện là tạo một gói giả mạo có chứa số nhận

dạng đó để gói dữ liệu đó được chấp nhận bởi mục tiêu.

Hình 2.7: Giả mạo DNS

2.2.3. Tăng cường an toàn bằng các chính sách

Các sản phẩm SSO có nhiều tính năng tăng cường tính bảo mật cho hạ tầng

của các đơn vị. Tuy nhiên các sản phẩm SSO không thể đảm bảo tất cả tính an

toàn cho một tổ chức nếu thực hiện không cẩn thận SSO còn làm xuất hiện thêm

Trang 24


các lỗ hổng bảo mật mới. Do vậy một hệ thống SSO cần được tăng cường bởi

các chính sách:

Không để người sử dụng tránh cách quên mật khẩu bằng cách viết ra giấy

dán trên máy tính, lưu vào một file văn bản .

Quản lí tập trung các thông tin ứng dụng được SSO trên một máy chủ

trung tâm.

Thi hành các chính sách về mật khẩu như: Độ dài mật khẩu tối thiểu,

không đặt các mật khẩu phổ biến, không đặt là tên, ngày sinh, sử dụng kết

hợp cả chữ hoa chữ thường và các kí tự đặc biệt…

Cơ chế phục hồi mật khẩu để phục hồi trong trường hợp người dùng quên

mật khẩu.

Khóa phiên đăng nhập sau một số lần đăng nhập không thành công liên

tiếp.

Thi hành chính sách đổi mật khẩu lần đầu truy nhập và sau một thời gian

sử dụng nhất định với các quản trị .

Lưu giữ các mật khẩu đa được sử dụng và đảm bảo mật khẩu mới không

trùng với mật khẩu đa được sử dụng.

Hết hạn mật khẩu sau một thời gian nhất định.

Phiên làm việc kết thúc sau một thời gian không sử dụng ứng dụng liên

tục.

Tăng cường hệ thống giám sát và báo cáo.

2.3. Tăng khả năng an toàn với giao thức SAML Single Sign On

2.3.1. Giới thiệu SAML

SAML là một tiêu chuẩn ma hóa xác nhận các thông điệp giao thức dạng

XML, sử dụng thẻ an toàn(security tokens) để xác nhận thông dựa trên các thông

tin chứa trong nó : Thông tin về người dùng, trung tâm xác thực và dịch vụ yêu

cầu, hỗ trợ việc xác thực trên web và được sử dụng là một tiêu chuẩn phổ biến

của đăng nhập một lần.

SAML Single Sign On mô tả việc sử dụng thông điệp để thực hiện hoạt động

đăng nhập giữa ba bên: Người dùng U sử dụng một trình duyệt tiêu chuẩn B, một

web nguồn S và web đích D.

Trang 25


Hình 2.8: SAML Single Sign On

Giả sử người sử dụng U đa chứng thực đăng nhập với web site S, trình tự xác

nhận của giao thức SAML Single Sign On:

1. Người dùng truy cập vào web site D.

2. Do người dùng U đa xác nhận đăng nhập với S nên trình duyệt chuyển

hướng từ web site D về site nguồn S để xác nhận thông tin chứng thực.

3. Hoàn thành việc chuyển hướng xác nhận người dùng về site S.

4. Site S xác nhận việc chứng thực của người dung.

5. Chuyển hướng người dùng về site D cùng với một số thông tin dữ liệu xác

nhận cho D khẳng định việc xác thực U đa thực hiện và đang được lưu giữ.

2.3.2. Bí mật,Toàn vẹn

SAML Single Sign On giao thức truyền thông điệp đảm bảo tính toàn vẹn, bí

mật. Thông điệp được chuyển qua kênh truyền thông thường hoặc sử dụng

SSL/TLS, nhưng ở lớp này của giao thức dễ bị tấn công man-in-the-middle nên

SAML SSO sẽ loại bỏ kênh truyền thông thường vì mức an toàn thấp.

S cid R:adr-msg

S: Bên gửi

R: Bên nhận

Adr: Tên máy

Msg: Thông điệp,tham số

Trang 26


Ngay cả khi gửi thông điệp không sử dụng các kênh truyền SAML SSO sử

dụng một kênh nhận dạng dạng cid được viết như chỉ số đại diện đầu mũi tên.

Trong thực hiện không có kênh truyền chỉ định cid sẽ là kênh đại diện tiếp nhận

các kết nối mạng cơ bản. Các kênh thông điệp được định nghĩa trong thông điệp

đầu tiên được gửi. Nó có thể thêm vào đầu vào cho các hoạt động gửi, thực tế tất

cả thông điệp được truyền qua cùng một kết nối.

Khi SAML SSO không sử dụng giao thức xác thực trong các loại hình truyền

thông điệp, giao thức sẽ không diện được mức an toàn và thấy kiểm tra thấy

thiếu sự nhận dạng và các nhân tố đảm bảo an toàn do vậy không phù hợp.

Các nhân tố đảm bảo bảo mật và toàn vẹn và chống chối bỏ:

Bí mật: Ngoài người gửi ban đầu,chỉ có một bên có thể giải ma thông

điệp msg. Điều này thường được chỉ định bởi các ADR.

Toàn vẹn: Kiểm chứng được bên đọc được msg ở trạng thái nguyên

vẹn chưa bị sửa chữa

2.3.3. Bảo mật kênh truyền

SAML SSO xác nhận thông tin người dùng lần hai sau lần người dùng đa

được chứng thực. Nó đảm bảo tính bí mật, toàn vẹn và xác thực hai bên. Tất cả

các thông tin được truyền qua một kênh an toàn. Có thể thực hiện với SSL/TLS

có chứng chỉ xác thực hai bên người dùng và máy chủ:

S(snd _id) cid R(rcv_id):adr-msg

Hai bên giao tiếp: Bên gửi S và bên nhận R trong đó S có đặc trưng snd_id và

bên R có định danh rcv_id . Tên máy tính được đặt trong lần đầu tiên gửi thông

điệp và bỏ qua nó trong lần tiếp theo nếu cùng sử dụng kênh truyền cid. Việc

thiết lập kênh truyền giữa S và R sử dụng thông điệp msg để gửi nhận thông qua

một kênh được thành lập:

Xác thực hai bên: Hai bên gửi (S) và nhận(R) xác nhận mình với snd_id

và rcv_id, cả hai bên kiểm tra chứng chỉ tương ứng và chỉ tiến hành quá

trình bắt tay nếu chứng chỉ hợp lệ.

Bí mật: Chỉ có S với định danh snd_id và người nhận R với rcv_id mới có

thể đọc được nội dung thông điệp msg

Trang 27


Toàn vẹn: Bên nhận R có thể xác minh nội dung thông điệp msg được gửi

từ từ S có định danh snd_id. Nếu R nhận được thông điệp msg từ bên khác

S gửi đến nó sẽ trả về một thông báo lỗi.

2.3.4. Theo dõi người sử dụng

Là một thành phần quan trọng trong giao thức SAML Single Sign On, trang

web nguồn S không yêu cầu người dùng U đăng nhập lại nhưng phải xác thực U

tự động. Toàn bộ quá trình tương tác trong suốt với người dùng được gọi là quá

trình xác thực và theo dõi người dùng đăng nhập.

Giả sử người dùng U đa đăng nhập trước đó và phiên đăng nhập của U chưa

hết hạn, người dùng sử dụng trình duyệt B trở lại web nguồn S trong bước 1 của

giao thức, website S có thể liên kết các trình duyệt vẫn còn đăng nhập hợp lệ.

Site S định danh người dùng U từ liên kết này. Các thông tin đăng nhập được

xây dựng:

a): S cid B U :Yêu cầu đăng nhập

b): U B cidB :Đăng nhập lU,S

c): S cidB : Xác minh thông tin vi

Bước (a): Đăng nhập asite nguồn S được xác thực người dùng bằng một kênh

truyền được định danh bởi các cid, trình duyệt B yêu cầu người dùng U đăng

nhập.

Bước (b): Trong bước này người dùng U đăng nhập thông tin của mình(lU,S)

vào trình duyệt S. Thông tin đăng nhập của người dùng có thể là user/password,

trình duyệt B chuyển tiếp vào site nguồn S thông qua kênh định danh bởi cid.

Site nguồn S kiểm tra thông tin đăng nhập, sau khi quá trình đăng nhập hoàn

thành site S gửi lại một xác minh đăng nhập thành công cho trình duyệt B. Trình

duyệt xem thông tin và xác định thông tin đăng nhập người dùng U.

Người dùng có thể tiếp tục theo dõi các hoạt động mà không cần tương tác

với giao diện người dùng:

d): S cid’B yêu cầu vi

c): B cid’S Kiểm chứng vi

Trang 28


Site nguồn S theo dõi người dùng và yêu cầu xác minh v i thông qua một kênh

được định danh cid’. Trình duyệt B căn cứ vào các thông tin xác minh để đưa ra

phản ứng với S. Sau khi xác minh được các thông tin với trình duyệt người dùng,

site nguồn chấp nhận các thông tin đăng nhập.

2.4. Lược đồ giao thức

2.4.1. Liên hệ các trang web nguồn

Trong bước đầu tiên của giao thức trình duyệt B thiết lập quan hệ với site

nguồn S.

a): B bs_cidS :ist_host – GET <IST-URL>s? TARGET=target . . .

<HTTP-Version>

b) S: Kiểm tra các yêu cầu

(a): Trình duyệt B kết nối với các trang web liên kết:Chuyển

URL<IST-URL>s. của S. B và S chuyển thông điệp với các thuộc

tính bí mật, toàn vẹn như đa mô tả trước đó tới trang nguồn S.

(b): S phân tích, kiểm tra các yêu cầu và bắt đầu một phiên làm việc

mới. S cố gắng xác định các thông tin yêu cầu từ chuỗi thông tin truy

vấn người dùng yêu cầu.

Sự thiếu xác thực: Kết nối này không cung cấp xác thực một bên do đó trình

duyệt B có thể không nhất thiết xác minh S bằng cách kiểm tra chứng chỉ của S

và xác nhận của nhà cung cấp chứng chỉ tin cậy. Việc thiếu xác thực này có thể

dẫn đến tấn công xen giữa (man-in-the-middle) việc truyền thông giữa trình

duyệt và web nguồn (B A S). Kẻ tấn công xen giữa chỉ cần phá vỡ quá trình

theo dõi người dùng ở bước tiếp theo là có thể thành công.

Định dạng thông điệp: Thông điệp gửi tới S là một HTTP GET yêu cầu

đường dẫn của <IST-URL>s nó chứa thông tin tài nguyên mà người dùng U

muốn truy cập trên trang web đích D. Các giao thức SAML SSO không quy định

cụ thể các yếu tố thêm vào các URL cũng như không ngăn cấm bao gồm các yếu

tố khác. Giao thức đa không mô tả rõ cách đặt tên rõ ràng dẫn đến cản trở việc

điều phối các thông điệp để sử dụng các module giao thức khác nhau.

Chuyển hướng đến trang web đích:

Trang 29


Sau khi xác nhận thành công người dùng U,trang nguồn S tạo ra nhiều kiến

trúc SAML. Nó chuyển hướng đến trình duyệt B tạo các URL <AR-URL>D của

web đích D và với các thành phần của SAML.

(a) S: Xác định các trang web đích tương ứng D đối với mục tiêu Bước 1

trong <AR-URL>D trong bảng kiến trúc gửi.

(b) S: Tạo ra một hoặc nhiều kiến trúc SAML<SAMLart> i có chứa

SourceIDS của nó.

(c) S: Tạo ra một searchpart SAML SAM LSP

(d)S →bs cid B : <HTTP-Version> 302 <Reason Phrase> Location <AR-

URL>D ? SAM Lsp

Trong bước (b), site nguồn nhận được URL <AR-URL>D. Giao thức SAML

Single Sign On không xác định thủ tục này. Chúng ta giả định rằng nó tìm kiếm

cho một URL có tên máy ngang bằng với nguồn đích. Site nguồn này sinh ra một

số của SAML artifacts và lưu trữ nó các thông tin artifacts đa được ban hành tới

site đích D. Site đích cũng như site nguồn không có chứng chỉ hoặc định danh

của D, nó có thể sử dụng tên máy site S hoặc tham chiếu của nó. Ở bước này

chúng ta trải qua cùng một vấn đề định dạng thông điệp ở bước 1. Hơn nữa,

chúng ta không dựa vào xác thực thì tấn công man in the middle có thể xảy ra.

2.4.2. Chuyển đến trang đích

Ở bước 3, trình duyệt B kết nối với D <AR-URL>D.

(a) B: Extracts the URL <AR-URL>D ? SAM Lsp

(b) B →bd cid D: ar host – GET <AR-URL>D ? SAM Lsp <HTTP-

Version>

2.4.3. SAML Request

Trong bước 4 web đích D thiết lập một kênh an toàn để web nguồn S sử dụng

các sourceID của các SAML artifacts nhận được để tìm ra tương ứng các SAML

trả lời tương ứng cho các yêu cầu .

(a) D: Kiểm tra artifact <SAMLart>i the SAM Lsp chứa SourceID.

(b) D: Xem <SR-URL>S tương ứng với SourceID.

(c) Tạo RequestID.

Trang 30


(d) D(idD ) ds_cid S(idS ): sr_host – SAML yêu cầu <SR-URL>S chứa

artifacts<SAMLart>i.

Trong bước 4a, site đích tạo ra một phiên để phân tích các URL yêu cầu. Site

đích này hủy bỏ chạy nếu yêu cầu không dành cho <AR-URL>D. Nếu D không

thể phân tích cú pháp searchpart SAML, hoặc nếu yêu cầu không bao gồm

SAML artifacts. Site đích kiểm tra giá trị của artifacts<SAMLart>i trong

searchpart. Tất cả artifacts phải được định dạng,có id version hợp lệ, và không

bao gồm các bản với SourceID. Site đích D sử dụng SourceID để tìm kiếm <SR-

URL>S của site S( bước 4b).

Bước 4d, site nguồn sẽ thiết lập kênh truyền bảo mật ds_cid tới site S với

xác thực hai bên. Nó gửi SAML request với received artifacts qua kênh truyền

này.

Đặc điểm kỹ thuật của trang web nguồn: Bước này của giao thức không xác

định đầy đủ thông tin của site S. SAML Single sign on chỉ trạng thái site D <SR-

URL>S.Vì vậy chúng ta có thể giả định rằng D không biết định danh ids của S.

Một yêu cầu sở hữu của SAML Artifact: Trong giao thức Sigle sign on,

SAML artifacts chỉ được sử dụng một lần, nó được quy định ở bước 5, trong khi

site D không lưu trữ artifacts received. Vì vậy, nếu việc chuyển của SAML khác

D thì SAML đòi hỏi định danh của U idU.

Nhiều dịch vụ trên một host: Một site nguồn S có thể chỉ cần xác minh với

máy gửi ở bước 4. Nếu có nhiều dịch vụ trên web đích D, một số dịch vụ nhưng

bảo mật kém được sử dụng mạo danh người dùng U để thao tác với các dịch vụ

có mức bảo mật cao hơn, ví dụ tại dịch vụ ngân hàng dịch vụ phân tích chứng

khoán,thị trường chạy cùng với các dịch vụ nghiệp vụ của ngân hàng trên cùng

một máy chủ và sử dụng SAML Single Sign On cho các dịch vụ. Một ma độc

được thực thi chuyển hướng từ phân tích thi trường sang sử dụng các quyền của

người dùng U có quyền thực hiện các giao dịch điện tử ngân hàng(<AR-

URL>DBank ,stock đến <AR-URL>DBank ,ebank).

2.4.4. SAML Response

Trong bước 5 site nguồn phân tích yêu cầu SAML và tạo ra phản hổi. Nó gửi

phản hồi trở lại thông qua kênh truyền với id ds_cid tạo ra ở bước 4.

Trang 31


(a) S: Kiểm tra các đích

(b) S: Thực thi việc thực hiện một lần các artifact.

(c) S: Xem hoặc tạo ra các xác nhận SAML tương ứng với các artifacts

<SAMLart>i .

(d) S: Tạo các ID phản hồi .

(e) S(idS ) ds_cidD(idD ): Phản hồi SAML <SR-URL>S chứa các xác

nhận về SSO hoặc ma lỗi ,đáp ứng tham chiếu các yêu cầu của bước 4 .

(f) D: Xác minh tính hợp lệ của các SAML.

Trong bước 5a site nguồn S kiểm tra thông tin phản hồi lại từ các site yêu cầu

thông tin, giao thức SAML SSO lưu thông tin các yêu cầu thông tin từ các site

đích để site nguồn không xác định và không cấp yêu cầu đó cho các site đích yêu

cầu khác. Các site nguồn có thể chỉ lưu trữ tên máy hoặc <AR-URL> cho các

yêu cầu. Nó sẽ so sánh tên máy của site đích hoặc AR-URL trong bảng lưu trữ

mà nó đa phát hành để đưa ra các phản hồi. Nếu trong bước 5b các thông tin

phản hồi được tìm thấy site nguồn S sẽ đưa ra phản hồi với các tài nguyên được

yêu cầu. Đây là tài nguyên được yêu cầu một lần, mỗi lần yêu cầu sử dụng lại

site nguồn sẽ xác nhận và gửi phản hồi sử dụng cho các lần tiếp theo. Nếu thông

tin yêu cầu không xác định tên máy đích, AR-URL site nguồn S sẽ phản hồi yêu

cầu lại bước 4.

2.4.5. Đáp ứng yêu cầu từ trình duyệt

Trong bước 6 web đích D đáp ứng các yêu cầu của trình duyệt B, nếu D xác

định được các thông tin của người dùng U qua các bước trên nó sẽ cho phép truy

cập các tài nguyên yêu cầu. Nếu không nó sẽ trả về một thông báo lỗi

D bd_cidB: thông điệp lỗi

Đặc điểm kỹ thuật của bước này: Giao thức SAML SSO không xác định

được đúng các thông tin yêu cầu nó sẽ bỏ qua các bước yêu cầu bảo mật cho kết

nỗi này.

2.5. Một số lỗ hổng có thể lợi dụng để thực hiện tấn công

2.5.1. Hijacking / Replay Attack

Một kẻ tấn công có thể cướp kết nối của SAML SSO sử dụng lại và chuyển

hướng. Các điều kiện để có thể thực hiện được:

Trang 32


Điều kiện tiên quyết: Kẻ tấn công A có thể chặn các kết nối và có thể quan

sát các kết nối từ trình duyệt B để thu được các URL<AR-URL >Dcủa bước 3.

Ngoài ra phải hoàn toàn sở hữu thông điệp msg và không có ràng buộc toàn vẹn

cho bên gửi phòng ngừa bị sử dụng phát lại.

Kẻ tấn công chặn kết nối từ bước 3 đến site đích D và sử dụng lại thông điệp

đa được ma hóa.

B → D: Chuyển đến <AR-URL>D

Kẻ tấn công A: Chặn quá trình chuyển hướng từ B đến D và chấm dứt

kết nối từ B đến D.

AB → D: Phát lại các thông tin chuyển cho D <AR-URL>D và mạo

danh trình duyệt B nó sử dụng một giao thức phụ để sửa đổi thông

điệp ma hóa cho phép gửi trực tiếp. Đích D không thể phân biệt được

B và A do thiếu xác thực.

D → S: SAML yêu cầu q cho SAML artifacts của thông điệp p

S → D: SAML đưa ra phản ứng r với yêu cầu xác nhận

D→ AB: Đáp ứng cho bước 3,D sẽ đáp ứng cho AB và cấp quyền truy

cập tương tự trình duyệt B và người sử dụng U.

Kết luận: Vì có tính toàn vẹn và bí mật ở bước 3 nên kẻ tấn công A không thể

xem hoặc chỉnh sửa được tin nhắn p. Nhưng đặc tính này không đủ mạnh đển

chống lại tấn công phát lại. Kẻ tấn công A đóng giả trình duyệt B gửi yêu cầu tới

Site D.

Do thiếu xác thực trong bước này và thiếu định danh trong chuyển hướng, D

không phân biệt được bên B và AB. Ngoài địa chỉ IP của các bên, thì quan điểm

của D là như nhau trong giao tiếp với B và AB.

Giải pháp: Site S có thể nhập địa chỉ IP của trình duyệt B như các chuỗi truy

vấn trong khi chuyển hướng. Site đích D sẽ kiểm tra địa chỉ IP của thông báo

nhận được với địa chỉ IP của trình duyệt B . Nếu kiểm tra thấy không trùng nhau

D sẽ không thực hiên các bước sau.

2.5.2. Tấn công xen giữa (Man-in-the-Middle)

Giả mạo DNS là một kỹ thuật Man-in-the-Middle được sử dụng nhằm cung

cấp thông tin DNS sai cho một host để khi người dùng duyệt đến một địa chỉ nào

Trang 33


đó. Lúc này kẻ tấn công đóng vai trò là một proxy đứng giữa trình duyệt B và

web nguồn S: B A S

Điều kiện tấn công: Cần giả mạo ARP cache thiết bị mục tiêu để định tuyến

lại lưu lượng của nó qua host đang tấn công của mình, từ đó có thể chặn yêu cầu

DNS và gửi đi gói dữ liệu giả mạo. Mục đích của kịch bản này là lừa người dùng

trong mạng mục tiêu truy cập vào website của kẻ tấn công thay vì website mà họ

đang cố gắng truy cập.

AS: Đóng vai trò giả mạo nguồn web S <IST-URL>S đến trình duyệt B

<IST-URL>sB =<IST-URL>A.

B As Kết thúc quá trình chuyển hướng. Quá trình này không yêu cầu

xác thực.

AB S Kết thúc việc chuyển hướng từ trình duyệt giả mạo AB đến web

S. A thực hiện đứng giữa B và S, vì hệ thống theo dõi người dùng của

S không chống lại được tấn công Man in the Middle nên A có thể

chuyển tiếp được tất cả giao tiếp giữa B và S trong quá trình theo dõi

người dùng.

AB D Kết thúc quá trình chuyển hướng đến <AR-URL>D. AB đóng

vai trò của B để chuyển hướng các AML artifacts và cho phép AB có

quyền truy cập của người dùng U.

A B: Chuyển hướng yêu cầu <IST-URL>S một người ban đầu sử

dụng trình duyệt B giả định người dùng đa được xác thực với site S.

Khi đó không cần các tương tác ở bước 1,2, A lúc này có thể sử dụng

giao thức của B để sử dụng một phiên kết nối với quyền người dùng

mà không bị thông báo thiết lập lại trạng thái của giao thức.

Do các bên không yêu cầu chứng thực ở bước 1,2 nên trình duyệt B có thể

không phân biệt <IST-URL >A của kẻ tấn công và <IST-URL>S của nguồn thật

website.

Các giải pháp: Xác thực một bên trong tất cả các bước của giao thức có thể

ngăn chặn giả mạo site S, để website nguồn S theo dõi trình duyệt B được chỉ

định trong giao thức SAML single sign on. Được sử dụng trong các sản phẩm

single sign on ứng dụng web như CAS, openID…

Trang 34


2.5.3. HTTP Referrer Attack

Cuộc tấn công cho phép người dùng thu thập được các thông tin rò rỉ về

SAML artifacts. Nó sử dụng các referen TAG để không sử dụng các SAML

artifacts.

Điều kiện tấn công: Kẻ tấn công có thể khai thác các kênh truyền và chặn các

kết nối. Ngoài ra, để cho B là một trình duyệt đa đưa ra HTTP Referrer Tag theo

mặc định.

Kẻ tấn công làm gián đoạn sự kết nối trang web D và web site nguồn S để thu

thập thông tin của SAML artifacts.

2.5.4. Khai thác lỗ hổng cua SSL/TSL

SOAP trên HTTP là một trong những thành phần quan trọng nhất các ràng

buộc của giao thức SAML Single Sign On. Nó sử dụng SSL 3.0 hoặc TLS 1.0 là

kênh truyền thông cho các kết nối yêu cầu tính bí mật và tính toàn vẹn. Khi liên

kết này vượt quá các yêu cầu an ninh của các giao thức riêng của mình, các cuộc

tấn công sẽ có nhiều khó khăn thực hiện. Tấn công Hijacking / Replay Attack

không còn thực hiện được.

2.6. Bảng đánh giá các sản phẩm SSO (open source)

2.6.1. Tổng quan

Qua tìm hiểu thực trạng hiện tại của các trường đại học trên thế giới, có các

open source single sign on authentication tool sau được sử dụng:

CAS(Central Authentication Service ): Yale, Berkerley, Princeton

University

Stanford WebAuth: Stanford , Oxford University

Cosign: Michigan , Edinburgh University.

Và còn nhiều tool khác như Pubcookie , KX.509, A-Select. Ở đây trong

survey này sẽ giới thiệu về CAS , Stanford WebAuth, Cosign , nêu lên các ưu

nhược điểm, và đánh giá thông qua 1 số các tiêu chí về các tool trên qua đó xem

xét tool nào là thích hợp nhất cho hệ thống xác thực của trường đại học.

2.6.2. CAS (Central Authentication Service)

Open source được phát triển bời đại học Yale.

CAS server được viết bằng Java và chạy trên nền J2EE.

Trang 35


Dưa trên mô hình cookie-Based Model.

Sử dụng giao thức Kerberos, việc authentication sẽ được dựa vào session

ID cookie ( hay là Ticket Granting ticket).

Khả năng tích hợp Shibboleth: có

Khả năng hỗ trợ LDAP : có

Tiêu chí Mức độ Đánh giá

Tính mềm dẻo Tốt CAS được thiết kế theo kiểu kết

nối chặt nên rất khó mà các thành

phần hệ thống có thể thay đổi uyển

chuyển. Chủ yếu tính mềm dẻo của

CAS được thừa kế từ J2EE application

server.

Tính hiệu quả Tốt Code thì rõ ràng và có sử dụng in-

memory ticket cache.

Độ đảm bảo khi gặp

lỗi

Rất tốt Java có khả năng bắt lỗi tốt . CAS

đa vận dụng nó để phát hiện và xử lý

lỗi 1 cách hiểu quả và thích hợp

Throughput

(Số lượng transaction

của application có thể

đáp ứng)

Tốt CAS thừa hưởng các đặc tính tốt

về Throughput từ J2EE application

server.

Total Cost of

Ownership

Tốt CAS có thể có mức chi phí cao

dựa vào sự triển khai của J2EE

application server.Nhưng nhìn

chung,chi phí cho CAS ở mức thấp

Khả năng mở rộng Tuyệt vời Khả năng mở rộng của CAS thì

phụ thuộc nhiều vào khả năng tạo

nhóm mà J2EE application server

cung cấp. Dựa vào tải ,mà J2EE

application server có thể triển khai

Trang 36


thêm Servlets để có thể đáp ứng

Supportability(Mức độ

tích hợp ứng dụng có

thể được hỗ trợ)

Rất tốt Hầu hết J2EE application servers

cung cấp rất tốt các tool để giám sát

các thánh phần của J2EE mà triển khai

trên nó. Tiếc rằng các tool này ko

được mờ rộng . Application server

cung cấp cơ chế logging tập trung.

Ko có 1 trang dành cho người

quản trị để có thể thấy logged-on users

Khả năng bảo trì Tốt Ứng dụng có thể dễ dàng được sửa

chữa vào bảo trì, Nhưng nó sẽ đòi hỏi

phải triển khai trên tất cả các J2EE

application server và cập nhật cho các

client đang sử dụng trên Web servers.

Bảng 2.1:CAS(Central Authentication service)

Nhận xét về CAS :

An toàn.

Hỗ trợ N-tier installations mà ko cần phải truyền password.

Việc thiết kế tốt Service ticket là một trong những điểm mạnh của

CAS.

Hỗ trợ rất lớn về thư viên bên client như : Java, Perl, JSP, ASP, PHP,

PL/SQL, Apache, PAM module.

Được rất nhiều trường đại học tin dùng.

Dễ bị tổn hại khi network và server bị lỗi.

Một trong những điểm bất lợi của CAS là CAS sử dụng Java. Java có

một điểm bất lợi về tốc độ đáp ứng là một trong những điều quan trọng

của hệ thống.

Nhưng vấn đề này có thể giải quyết bằng cách viết code tốt và triển khai

được một kiến trúc tốt . Nếu được như vậy thì tốc độ của hệ thống sẽ hiệu quả

giống như những hệ thống được viết bằng các ngôn ngữ khác.

Trang 37


2.6.3. Open source được phát triển bời đại học Stanford


Tính mềm dẻo Hợp lý WebAuth đưa ra thiết kế kết nối chặt :

WebKDC xử lý mọi thứ. Dù vậy, theo

thiết kế, WebKDC ko xử lý việc xác nhận

các token (điều này được thực hiện bởi

Web server trong khi giải ma các Token).

Tính hiệu quả Tốt Code WebAuth được viết bằng Perl,

mà Perl thì rất hiệu quả (mặc dù là ngôn

ngữ dạng thông dịch). Một vấn đề lớn

của Perl là có khuynh hướng sử dụng

nhiều bộ nhớ hơn 1 ứng dụng C tương

đương

Độ đảm bảo khi

gặp lỗi

Rất tốt Perl cung cấp việc xử lý lỗi tốt và

WebAuth sử dụng khả năng này của Perl

Throughput(Số

lượng transaction

của ứng dụng có

thể đáp ứng)

Rất tốt Bởi vì WebKDC không làm việc

kiểm định các token cho nên performance

không bị ảnh hưởng bởi việc token bị sai.

Và cũng bởi vị bản chất tự nhiên của

WebKDC là không trạng thái, nên sẽ có

throughput cao hơn.Duy chỉ có 1 điểu trở

ngại lớn là sử dụng ngôn ngữ dạng thông

dịch.

Total Cost of

Ownership

Kém Chi phí triển khai cho WebAuth có lẽ

khá cao so với việc client hỗ trợ .Mặc dù

là chi phí dành cho WebAuth sẽ nhỏ

nhưng chi phí dành cho Perl sẽ lớn hơn

Java.

Khả năng mở Rất tốt Bởi vì WebKDC là không trạng thái

Trang 38


rộng (tất cả trạng thái được lưu vào trong

cookies trong browser), nên WebAuth thì

có tính mở rộng cao. Multiple servers có

thể được vận hành với WebKDC

Supportability

(Mức độ dễ dàng

mà ứng dụng có

thể được hỗ trợ)

Kém Có rất ít ghi chép để có thể hỗ trợ

Ko có 1 trang dành cho người quản trị

để có thể thấy logged-on users

Khả năng bảo

trì

Tốt Ứng dụng có thể dễ dàng được sửa

chữa vào bảo trì, Nhưng nó sẽ đòi hỏi

phải triển khai trên tất cả các J2EE

application server và cập nhật cho các

client đang sử dụng trên Web servers

Bảng 2.2: Open source được phát triển bởi đại học Stanford

2.6.4. Cosign


Tính mềm dẻo Rất tốt Nếu các thành phần của hệ thống

được phân bố 1 cách hợp lý, hệ thống sẽ

có tính mềm dẻo. Cosign đưa ra kết nối

thấp , vì vậy , những mô hình có thể

triển khai là rất phong phú và đa dạng.

Bởi vì CoSign server có khả năng sao

lặp dữ liệu cho các server khác ,nên dữ

có thể dẽ dáng được phân bố và làm

tăng tính mềm dẻo và nâng cao

throughput

Tính hiệu quả Tốt Tất cả những authentication cookie

và service cookie thì được lưu thành

dạng file ở trên đĩa Điều này tạo ra sự

Trang 39


hiệu quả trong các trường hợp high-

load .

Độ đảm bảo khi

gặp lỗi

Tốt Một khi ừng dụng được chạy,

Cosign có khả năng xử lý lỗi 1 cách hợp

lý

Throughput(Số

lượng transaction

của application có

thể đáp ứng)

Rất tốt Đại học Michigan đang sử dụng

CoSign trên 3 máy dual 2.8Ghz với 4GB

RAM và phục vụ xấp xỉ đăng ký

255000 ST và 180000 login request /

ngày.

Total Cost of

Ownership

Tốt CoSign có thể có mức chi phí cao về

việc triển khai và thay đổi code để phù

hợp vời yêu cầu.Nhưng nhìn chung, chí

phí cho Cosign là nhỏ

Khả năng mở rộng Rất tốt Tất cả authentication cookies và

service cookies thì được lưu dưới dạng

file trên đa cứng. Điều này ảnh hưởng

nhiều đến khả năng mở rộng, như là có

một số lượng tối đa các object mà hệ

điều hành cho phép trong một thư mục

Có 1 quá trình lớn phục vụ cho việc

nhân rộng các TGT và ST tới các dịch

vụ cosignd khác đang chạy trên các

host

Mối quan hệ giữa CoSign CGI và

cosignd /monster services không cần

thiết phải là quan hệ 1 -1

Trang 40


Supportability(Mức

độ dễ dàng mà ứng

dụng có thể được

hỗ trợ)

Kém Có rất ít ghi chép để có thể hỗ trợ

Ko có 1 trang dành cho người quản

trị để có thể thấy logged-on users

Khả năng bảo trì Tốt Phần lõi cùa ứng dụng dễ dàng được

bảo trì.

Bảo trì , sửa chữa client và các hàm

API của client thì sẽ khó khăn hơn 1

chút bởi vì bản chất phân tán của chúng

Bảng 2.3: Cosign

Thông qua tìm hiểu và xem xét thì ta thấy, mỗi giải pháp đều có điểm mạnh

và điểm yếu riêng. CoSign là 1 giải pháp tốt cho việc hiện thực hệ thống single

sign on, thế nhưng với tài liệu ít ỏi mà CoSign đưa ra việc hiện thực CoSign là

rất khó khăn( hầu như không có hỗ trợ nào về tài liệu cho dù đây là 1 open

source). StanfordWebAuth cũng vậy, cũng rất ít có tài liệu, hơn nữa TCO dành

cho hệ thống để hiện thực là khá cao cộng với lại mô hình WebAuth khá là phức

tạp, chính vì vậy rất ít người sử dụng Stanford WebAuth cho hệ thống xác thực.

CAS mặc dù không phải là sản phẩm tốt nhất, nhưng chính vì được nhiều trường

đại học sử dụng nên nguồn tài liệu là không ít . Hơn nữa CAS là mô hình xác

thực đơn giản nhưng rất hiệu quả cho nên có thể chọn CAS để xây dựng hệ

thống Single Sign On.

Kết chương II:

An toàn là vấn đề cốt lõi quan trọng nhất trong các sản phẩm single sign on.

Trong chương đa trình bày để nổi bật kiến trúc của hệ thống SSO, giao thức

SSO, các hiểm họa và cách phòng chống, đưa ra bảng đánh giá các sản phẩm

SSO ma nguồn mở phổ biến trên thế giới từ đó đi sâu tìm hiểu phần mềm CAS

của đại học Yale viết trên nền tảng java.

Trang 41


Chương III

CENTER AUTHENCATION SERVICE

3.1 Khái niệm Center Authencation Service (CAS)

CAS: Là một giải pháp Single Sign On ma nguồn mở được phát triển bởi đại

hoc Yale. Hỗ trợ nhiều thư viện phía client được viết bởi nhiều ngôn ngữ: PHP,

Java, PL/SQL, …

CAS lấy thông tin Single Sign On thông qua Cookie. Cookie này sẽ bị hủy

khi user đăng xuất khỏi CAS hoặc đóng trình duyệt. Cookie được sinh ra bởi

CAS, còn được gọi là TGT Cookie (Ticket Granting Cookie) chứa một id duy

nhất và thời gian hết hạn. Thời gian hết hạn là 8 giờ.

CAS cung cấp nhiều trình quản lý xác thực (authenticate handler) khác nhau.

CAS xác thực nhiều loại thông tin người dùng như username/password, X509

Certificate....để xác thực những thông tin người dùng khác nhau này, CAS sử

dụng những trình quản lý xác thực tương ứng.

CAS còn cung cấp tính năng “Remember Me”. Developer có thể cấu hình

tính năng này trong nhiều file cấu hình khác nhau và khi người dùng chọn

“Remember me” trên khung đăng nhập, thì thông tin đăng nhập sẽ được ghi nhớ

với thời gian được cấu hình (mặc định là 3 tháng) và khi người dùng mở trình

duyệt thì CAS sẽ chuyển đế service url tương ứng mà không cần hiển thị khung

đăng nhập.

Các phiên bản của CAS

CAS 1.0: Được tạo bởi Yale University, khởi đầu từ năm 1999. Là một

web single sign on, dễ sử dụng.

CAS 2.0: Được tạo ra bởi Yale University. Giới thiệu thêm tính năng

mới là Proxy Authentication.

Trang 42


JA-SIG CAS 3.0: Trở thành JA-SIG project vào 2004. Mục đích làm

cho CAS tương thích cao hơn, mềm dẻo hơn.Tương thích hoàn toàn

với CAS 2.0.

3.2. CAS Protocol

Thực hiện single sign on qua giao thức http nhưng sử dụng những URI cụ thể

để truy cập và sinh ra những ticket khác nhau. Các URI cụ thể:

3.2.1. URI -/login đăng nhập

Các /login URI hoạt động với hai hành vi: Như một người yêu cầu chứng

nhận, và như một người khả năng có khả năng chấp nhận.

Nếu người dùng đa đăng nhập một lần vào CAS, nó sẽ truyền cho trình

duyệt người dùng một Cookie an toàn có chứa một chuỗi xác định là một ticket.

Nếu Cookie lưu trữ một ticket hợp lệ được cấp phát, CAS có thể phát hành một

Ticket dịch vụ cung cấp tất cả các điều kiện trong các đặc tả sau được đáp ứng.

3.2.2. Các thông số

Các thông số sau đây có thể yêu cầu HTTP được thông qua vào /login trong

khi nó đang hoạt động như một người yêu cầu chứng nhận. Đây đều là những

trường hợp nhạy cảm, và tất cả đều phải được xử lý bởi /login:

Service (dịch vụ): Các định danh của ứng dụng người dùng đang cố gắng

truy cập.Trong hầu hết các trường hợp, đây sẽ là URL của ứng dụng. Nếu một

dịch vụ không được chỉ định và đăng nhập một lần chưa tồn tại, CAS sẽ yêu cầu

thông tin từ người sử dụng khởi đăng nhập. Nếu một dịch vụ không được chỉ

định và đăng nhập đa được thực hiện, CAS hiển thị một thông báo cho các người

dùng đa đăng nhập.

Renew(Làm mới): Nếu tham số này được thiết lập, phiên đăng nhập một

lần đa thực hiện sẽ được bỏ qua. rong trường hợp này, CAS sẽ yêu cầu người

dùng nhập lại thông tin kể cả trong trường hợp đa từng đăng nhập rồi.

Gateway: Nếu tham số này được thiết lập, CAS sẽ không yêu cầu người

dùng đăng nhập lại các thông tin. Nếu người dùng trước đó đa đăng nhập xác

thực với CAS,CAS sẽ cấp một Ticket dịch vụ hợp lệ.

Trang 43


3.2.3. Các ví dụ về tham số đăng nhập

Đăng nhập: https://server/cas/login?service=http%3A%2F%2Fwww.service.com

Không nhắc tên đăng nhập/mật khẩu:

https://server/cas/login?service=http%3A%2F

%2Fwww.service.com&gateway=true

Luôn nhắc tên đăng nhập/mật khẩu:

https://server/cas/login?service=http%3A%2F

%2Fwww.service.com&renew=true

3.2.4. Chứng thực Username/Password

Trong hầu hết trường hợp, CAS sẽ phản ứng bằng cách hiển thị một màn

hình đăng nhập yêu cầu một tên người dùng và mật khẩu. Trang này phải bao

gồm một khung đăng nhập với các tham số: "Tên người dùng", "mật khẩu", có

thể thêm các thông báo cảnh báo. Nếu "dịch vụ" đa được quy định vào /login,

"dịch vụ" cũng phải là một tham số của biểu mẫu, có giá trị ban đầu thông qua

vào /login.

3.2.5. Chứng thực tin cậy

Khi /login phản ứng một người dùng yêu cầu chứng nhận để chứng thực sự

tin tưởng, hành vi của nó sẽ được xác định bởi các loại thông tin nó sẽ được tiếp

nhận. Nếu các thông tin có giá trị, CAS có thể chuyển hướng người sử dụng dịch

vụ. Cách khác, CAS có thể hiển thị một cảnh báo rằng các thông tin đa được

trình bày và cho phép người dùng xác nhận rằng họ muốn sử dụng những thông

tin quan trọng.

3.2.6. Phổ biến các thông số

Các thông số yêu cầu HTTP có thể được thêm vào /login trong khi nó đang

hoạt động để chấp nhận khả năng chứng thực. Tất cả đều là những trường hợp

nhạy cảm và tất cả đều phải được xử lý bởi /login.

3.2.7. Các thông số xác thực tên người dùng,mật khẩu

Các thông số HTTP yêu cầu sau đây phải được thông qua vào /login trong

khi nó đang hoạt động để chấp nhận chứng nhận để xác thực username /

password.

Tên người dùng: Tên người dùng của khách hàng để đăng nhập.

Trang 44


Mật khẩu: Mật khẩu của khách hàng để đăng nhập.

Vé đăng nhập: Vé đăng nhập CAS cấp cho trình duyệt người dùng.

3.2.8. Logout

Hủy Single Sign On session và ticket granting cookie.

Hiển thị một trang trạng thái để báo với user đa đăng xuất.

Tham số “url” có thể được chỉ định đến /logout và nếu được chỉ định, “url”

sẽ được hiển thị trong trang logout cùng với thông báo đăng xuất.

Validate: Kiểm tra tính hợp lệ của service. CAS làm service ticket có hiệu

lực, service ticket được sinh ra từ thông tin xác thực lấy từ request.

Những tham số sau có thể chỉ định đến /validate URI:

Service (bắt buộc)

Ticket (bắt buộc) – service ticket được sinh ra bởi /login.

Renew (không bắt buộc) – nếu tham số này được thiết lập.

Ptgurl – url của proxy callback.

/ServiceValidate: Trả về một xml-formatted response. Khi thành công,

response chứa username và proxy-granting ticket. Khi thất bại, response chứa

một ma lỗi với thông điệp thất bại tương ứng. Sau đây là một số ma lỗi được trả

về response nếu /serviceValidate thất bại:

INVALID_REQUEST: Không tìm thấy tham số cần tìm trong request.

INVALID_TICKET: Ticket được cung cấp không hợp lệ hoặc ticket

không đến từ login và “renew” được thiết lập trên validation.

INVALID_SERVICE: Ticket được cung cấp không hợp lệ nhưng

service được chỉ định không khớp với service mà liên kết với ticket.

INTERNAL_ERROR: Lỗi cục bộ xuất hiện trong khi kiểm tra tinh hợp

lệ của ticket.

/ProxyValidate làm việc giống như /serviceValidate, ngoại trừ nó làm cho

proxy ticket có hiệu lực. Những tham số và ma lỗi giống tương tự. Khi thành

công, respone chứa PGT và danh sách các proxy cái mà việc xác thực được thực

thi. Những proxy được viếng thăm gần nhất sẽ nằm trên đỉnh, và ngược lại.

Trang 45


3.3. /Proxy

Cung cấp proxy ticket đến những service, lấy PTG thông qua /proxyValidate

hoặc /serviceValidate.

Những tham số sau được yêu cầu cho /proxy URI:

PGT – Proxy granting ticket

TargetService - service identifier của back-end service. Service identifier

phải khớp với service identifier được chỉ định đến /proxyValidate nhờ vào sự

hợp lệ của proxy ticket.

/proxy sẽ trả về xml-formatted service response. Thành công, response sẽ

chứa đựng proxy ticket. Thất bại, response chứa đựng ma lỗi với thông điệp

tương ứng. Các ma lỗi sẽ được trả về trong /proxy: INVALID_REQUEST,

BAD_PGT, INTERNAL_ERROR. BAD_PGT có nghĩa là PGT không hợp lệ.

Xác nhận ticket thành công:

<cas:serviceResponse

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

<cas:authenticationSuccess>

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

<cas:proxyGrantingTicket>PGTIOU-84678-8a9d...</c

as:proxyGrantingTicket>

<cas:proxies>

<cas:proxy>https://proxy2/pgtUrl</cas:proxy>

<cas:proxy>https://proxy1/pgtUrl</cas:proxy>

</cas:proxies>

</cas:authenticationSuccess>

</cas:serviceResponse>

Xác thực Ticket lỗi:<cas:serviceResponse


<cas:authenticationFailure code="INVALID_TICKET">

ticket PT-1856376-1HMgO86Z2ZKeByc5XdYD not

recognized

</cas:authenticationFailure>

Trang 46


/SAMLValidate:

URI Mô tả

/login Hiển thị khung đăng nhập yêu cầu người

dùng xác thực

/logout Hủy Single Sign On session và ticket

granting cookie

/validate Kiểm tra tính hợp lệ của Service Ticket.

Nếu nó không sử dụng proxy authentication

/serviceValidate Kiểm tra tính hợp lệ của Service Ticket

và trả vể một XML-fragment và sinh ra

proxy-granting ticket khi được yêu cầu

/proxyValidate Thực thi giống như /serviceValidate và

ngoài ra còn kiểm tra tính hợp của proxy

ticket

/proxy Cung cấp Proxy Ticket đến service

/samlValidate

/services/add.html Một tính năng admin. Thêm những

service đến danh sách Registered Services.

/services/edit.html Chỉnh sửa những service đa đăng ký

/services/manage.html Quản lý những service đa đăng ký như:

thêm, xóa, sửa.

/services/logout.html Đăng xuất từ trang admin service

/services

/

deleteRegisteredService.ht

ml

Xóa service bởi tham số “id” được cung

cấp

Bảng 3.1: /SAMLValidate

Trang 47


3.4. CAS Tickets

Ticket: Là một chuỗi ký tự ngẫu nhiên và bắt đầu với một tiền tố như

(ST-,TGC-,…) và nó là id duy nhất cho một thao tác nào đó. Trong quá trình xác

thực của CAS, một số ticket được tạo ra với mục đích lưu trữ thông tin và bảo

mật. Sau đây là khái niệm một số ticket được sử dụng trong CAS.

Ticket-Granting Ticket (TGT)

Là một chuỗi ký tự chứa dữ liệu bảo mật ngẫu nhiên và bắt đầu bằng

“TGT”, chứa id duy nhất và thời gian hết hạn.

TGT được tạo ra CAS Server xác thực thành công.

Không có TGT, user của CAS không thể Single Sign On

TGT sẽ được thêm vào HTTP Cookie (cở sở để Single Sign On) và nó sẽ

được kiểm tra khi truy cập ứng dụng.

Ví dụ: TGT sẽ được lưu xuống browser là TGC (Ticket Granting Cookie) là

một HTTP Cookie của CAS. Cookie này duy trì trạng thái đăng nhập cho client.

Khi client chuyển đến các ứng dụng khác, cookie này sẽ được kiểm tra đế tự

động đăng nhập cho user. TGC sẽ bị hủy khi đóng trình duyệt hay client chọn

logout từ ứng dụng. Giá trị của TGC bắt đầu bằng “TGC-“.

Service Ticket (ST).

Service Ticket sẽ được tạo ra khi CAS Url có chứa tham số service và

thông tin xác thực được truyền đến và xác thực thành công.

Ví dụ: https://server/CAS/login?service=http%3A%2F%2Fwww.service.com

Mỗi Service chỉ có một service ticket duy nhất và được sử dụng một lần

duy nhất.

ST là một chuỗi ký tự, được sử dụng bởi client như là thông tin xác thực

để truy cập đến dịch vụ.

Service ticket phải bắt đầu với ký tự “ST-“.

Ví dụ: ticket=ST-1856339-aA5Yuvrxzpv8Tau1cYQ7

Proxy Ticket (PT).

CAS Proxy là một service muốn truy xuất những service khác thay mặt

cho một user riêng biệt. Proxy Ticket (PT) được sinh ra từ CAS nhờ vào một

Trang 48

https://server/cas/login?service=http%3A%2F%2Fwww.service.com


service thể hiện của một Proxy Granting Ticket hợp lệ và một service identifier

(giá trị của tham số “url” của /proxy url) cho back-end service đến cái nó kết nối.

Proxy Ticket là một chuỗi ký tự ngẫu nhiên mà một service sử dụng như

thông tin đăng nhập để truy cập vào một back-end service thay mặt cho client.

Proxy ticket chỉ hợp lệ cho service identifier được chỉ định đến /proxy url

khi chúng được sinh ra.

Proxy ticket bắt đầu bằng “PT”.

Proxy-Granting Ticket (PGT).

PGT được lấy từ CAS nhờ vào sự hợp lệ của service ticket hoặc proxy

ticket. Nếu một service mong muốn proxy xác thực client đến một back-end

service, nó yêu cầu một proxy-granting ticket.

Proxy-Granting Ticket IOU.

Trên một ticket hợp lệ, một service có thể yêu cầu một proxy ticket. Trong

CAS 2.0, cách chúng ta xác thực service được yêu cầu để gởi PGT, PGTIOU đến

proxy callback url được chỉ định như một request parameter. Proxy callback url

phải chạy thông qua kênh bảo mật. Chúng ta xác minh certificate của nó. Sau đó,

trả về trong ticket hợp lệ, phản hồi TGTIOU. Từ response này, service sẽ rút

TGTIOU và sử dụng nó để tìm TGT từ bộ nhớ.

Login Ticket.

Là một chuỗi ký tự, được sinh ra bởi /login, là một thông tin đăng nhập và

được đưa đến /login.

Mục đích là ngăn cản sử phản hồi lại thông tin xác thực.

Login ticket được sinh ra bởi /login, phải là duy nhất và bắt đầu với “LT-”.

3.5. Nguyên tăc hoạt động cua CAS

3.5.1. Chứng thực người dùng với CAS server

Người dùng nhập UserId / Password vào khung đăng nhập. Các thông tin này

được truyền cho CAS server thông qua giao thức HTTPS là một giao thức bảo

đảm dữ liệu được ma hóa trước truyền đi.

Trang 49


Hình 3.1 : Đăng nhập CAS

Xác thực thành công, TGC được sinh ra và thêm vào trình duyệt dưới hình

thức là Cookie. TGC này sẽ được sử dụng để Single Sign On với tất cả các ứng

dụng

Hình 3.2 : Chứng thực một trình duyệt đển máy chủ CAS

3.5.2. Truy cập vào ứng dụng.

Người dùng truy cập vào ứng dụng khi đa chứng thực với CAS server.

Ngườ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.

Trang 50


Hình 3.3 : Truy cập vào ứng dụng

Nếu TGC này là hợp lệ, CAS server trả về một Service Ticket cho trình

duyệt, trình duyệt truyền ST vừa nhận cho ứng dụng.

Hình 3.4: Trình duyệt truyền ST cho ứng dụng

Trang 51


Ứng dụng sử dụng ST nhận được từ trình duyệt và sau đó chuyển nó cho

CAS server.

Hình 3.5 : Ứng dụng truyền ST cho CAS

CAS server sẽ trả về ID của người dùng cho ứng dụng, mục đích là để

thông báo với ứng dụng người dùng này đa được chứng thực bởi CAS server.

Ứng dụng đăng nhập cho người dùng và bắt đầu phục vụ người dùng.

Hình 3.6 : Người dùng truy cập vào ứng dụng khi đa chứng thực với CAS

Trang 52


Người dùng truy cập vào ứng dụng mà chưa chứng thực với CAS server.

Người dùng truy xuất ứng dụng thông qua trình duyệt.Vì chưa nhận được

TGC nên ứng dụng sẽ chuyển hướng người dùng cho CAS server.

Hình 3.7 : Người dùng truy cập vào ứng dụng

Người dùng cung cấp UserId/Password của mình thông qua khung đăng

nhập để CAS xác thực. Thông tin được truyền đi thông qua giao thức HTTPS.

Xác thực thành công, CAS server sẽ trả về cho trình duyệt đồng thời TGC

và ST.

Hình 3.8: CAS trả về cho trình duyệt đồng thời TGC và ST

Trình duyệt sẽ giữ lại TGC để sử dụng cho các ứng dụng khác (nếu có) và

truyền ST cho ứng dụng.

Trang 53


Hình 3.9 : Truyền ST cho ứng dụng

Ứng dụng chuyển ST cho CAS server và nhận về ID của người dùng.

Ứng dụng đăng nhập cho người dùng và bắt đầu phục vụ người dùng.

Hình 3.10:Người dùng truy cập vào ứng dụng mà chưa chứng thực với CAS

Trang 54


3.6. Chức năng proxy

3.6.1. Proxy CAS

Trong hoạt động cơ bản, người sử dụng CAS luôn giao tiếp trực tiếp trình

duyệt.Trong một hoạt động n-tier, trình duyệt sẽ truy cập CAS thông qua một

proxy CAS. Các cơ chế chuyển hướng nhìn thấy trong các hoạt động cơ bản

không còn áp dụng

3.6.2. Cơ chế Proxy

Hình 3.11: Cơ chế Proxy

Mức phổ biến ngày càng tăng của XML, CAS 2.0 bổ sung giao thức này

trong phiên bản hiện tại, và tùy chọn có sẵn. Các định dạng của các yêu cầu

tương tự như CAS 1.0, nhưng phản ứng có định dạng sau:CAS phản ứng với một tài liệu XML mà các phần tử gốc là <cas:serviceResponse>. Nếu

thất bại, nút tài liệu có chứa một subelement duy nhất:



<cas:authenticationFailure code="...">

<cas:authenticationFailure code="...">

Optional authentication failure message Tùy chọn xác

thực thông điệp thất bại

</cas:authenticationFailure> </ Cas:

authenticationFailure>

</cas:serviceResponse> </ Cas: serviceResponse>

Trang 55


Nếu thành công, các nút tài liệu có chứa một subelement với nội dung của nó được đánh

dấu riêng



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



<cas:user> NetID </cas:user> <cas:user> NetID </ cas:

user>

</cas:authenticationSuccess> </ Cas:

authenticationSuccess>

</cas:serviceResponse> </ Cas: serviceResponse>

Ngoài ra giao thức xác thực chính, CAS 2.0 cung cấp một giao thức bổ sung

có sẵn cho bất kỳ ứng dụng web có nhu cầu sử dụng nó. Như trước đây, định dạng

của yêu cầu là như nhau, nhưng phản ứng có một yếu tố phụ cung cấp thông tin mới:

<cas:serviceResponse> <cas:serviceResponse>

<cas:authenticationSuccess> <cas:authenticationSuccess>

<cas:user> NetID </cas:user> <cas:user> NetID </ cas:

users>

<cas:proxyGrantingTicket> PGT IOU

</cas:proxyGrantingTicket> <cas:proxyGrantingTicket> PGT IOU

</ cas: proxyGrantingTicket>

</cas:authenticationSuccess> </ Cas:

authenticationSuccess>

Các phần tử proxyGrantingTicket chứa nội dung thông tin của nó xác định

các PGT được gửi đến các ứng dụng web, thực chất là PGT "IOU". Giá trị này

không phải là điển hình để nhận diện cho các PGT thực tế, nó chỉ đơn giản là

một giá trị duy nhất mà chỉ số này PGT. Đồng bộ, CAS phải gửi PGT là giá trị

thực tế như một tham số yêu cầu tới một URL thuộc sở hữu của ứng dụng (và

được xác định bởi các proxyCallbackUrl tham số yêu cầu trong yêu cầu xác nhận

để CAS). Các yêu cầu gọi lại có hai thông số truy vấn: pgtId, có giá trị thực tế

đại diện cho PGT, và pgtIou, có chứa các PGTIOU chứa trong câu trả lời của

CAS để web của ứng dụng yêu cầu.

Trang 56


3.6.3. Hoạt động

Một proxy CAS, khi một Ticket (vé) dịch vụ hợp lệ để xác thực người dùng,

thực hiện cùng một lúc yêu cầu PGT (Proxy Cấp vé)

Hình 3.12: Thu hồi TMP của một proxy CAS từ máy chủ CAS

TMP là mờ, lặp lại, và thu được bằng các máy chủ CAS một kênh được ma

hóa . Như CDO, nó được giới hạn thời gian tồn tại (thường là vài giờ).

Các dụng Proxy (PT) được dùng như vé dịch vụ, xác nhận bởi các máy chủ

CAS để cung cấp truy cập đến các tài nguyên được bảo vệ

Trang 57


Hình 3.13: Xác Nhận của PT người dùng CAS truy cập bởi một proxy CAS

3.7. Kiến trúc CAS

3.7.1. Sơ đồ tổng quát

Trung tâm xác thực CAS được thiết kế như một ứng dụng web độc lập được

chạy trên máy chủ sử dụng https. Nó được truy cập thông qua ba URL mô tả:

URL đăng nhập, URL xác nhận , URL đăng xuất và các lựa chọn.

Hình 3.14: Sơ đồ CAS

Trang 58


Để sử dụng trung tâm chứng thực dịch vụ (CAS) ứng dụng chuyển hướng

người dùng hoặc đơn giản là chỉ tạo ra các siêu liên kết , người dùng cũng có thể

truy cập bằng cách gõ địa chỉ nếu họ muốn xác thực trước phiên đăng nhập.

URL đăng nhập xử lí bằng cách đưa ra một khung đăng nhập yêu cầu người

dùng nhập ID/Password để xác nhận nó với dịch vụ chứng thực.

Để xác thực lại sau đó mà không cần đăng nhập lại CAS gửi một tickket được

lưu giữa trên cookie của trình duyệt xác nhận người dùng đa đăng nhập thành

công. Cookie là thành phần bắt buộc của cơ chế xác thực CAS. Nếu không có

Cookie người dùng sẽ phải đăng nhập lại ID/Password mỗi khi ứng dụng chuyển

hướng tới CAS.

URL xác nhận: Ngoài việc xác thực chính CAS cũng yêu cầu nhận dạng các

dịch vụ mà người dùng đa liên kết hoặc chuyển hướng đến. Nếu xác nhận thành

công CAS sẽ tạo ra một day số có độ dài ngẫu nhiên (Ticket), sẽ sử dụng vé này

với xác nhận người dùng thành công để thực hiện việc cho phép người dùng truy

cập vào một ứng dụng khác.

Trang 59


3.7.2. Login Flow

Hình 3.15 : Login Flow

Trang 60


Người dùng có thể truy xuất thông qua nhiều URI khác nhau. URI chủ yếu

là /login. Khi người dùng nhập địa chỉ http://server/CAS/login từ trình duyệt,

CAS sẽ kiểm tra Ticket granting cookie (TGC) đa tồn tại chưa. Nếu TGC đa tồn

tại, thì nó sẽ kiểm tra thời gian hết hạn của cookie và nếu còn thời hạn thì

Service Ticket (ST) sẽ được sinh ra. Nếu TGC không tồn tại hay đa hết hạn thì

CAS sẽ buộc người dùng nhập thông tin đăng nhập vào khung đăng nhập.

Người dùng nhập thông tin đăng nhập và chọn Submit, CAS sẽ lấy danh

sách AuthenticationHanders từ deployerConfigContext.xml và kiểm tra xem nó

hỗ trợ AuthenticationHander nào. Nó sẽ đưa thông tin đăng nhập cho

AuthenticationHander mà nó hỗ trợ và kiểm tra thông tin đăng nhập của người

dùng. Nếu người dùng xác thực không hợp lệ sẽ được chuyển đến khung đăng

nhập để đăng nhập lại. Nếu người dùng hợp lệ thì một Ticket-granting Ticket

(TGT) sẽ được sinh ra và thêm vào cookie.

CAS tạo ra một Service Ticket (ST) và thêm Service Ticket này đến

Ticket Registry. CAS kiểm tra có hay không service parameter thông qua /login

URL.

Ví dụ:https://server/CAS/login?service=http://www.findtechies.com/auth.jsp

CAS gọi Service Identifier với ticket là tham số, giá trị là service ticket

(st). Các client có trách nhiệm gọi /serviceValidate URI của CAS để kiểm tra

service và service ticket. /serviceValidate sẽ được gọi bởi filter của client

Service param name: service

Service Identifier value: https://www.servertechies.com/auth.jsp

Ticket param name: ticket

Service Ticket value: ST-1856339-aA5Yuvrxzpv8Tau1cYQ7

Proxy param name: pgtUrl

Proxy-granting Url value: https://server/test.jsp

Trang 61

https://server/test.jsp

https://www.servertechies.com/auth.jsp

https://server/cas/login?service=http://www.findtechies.com/auth.jsp

http://server/cas/login


3.7.3. Proxy Flow

Hình 3.16 : Proxy Flow

3.7.4. Logout Flow

Hình 3.17 : Logout Flow

Trang 62


Khi người dùng muốn đăng xuất khỏi một service, người dùng phải gọi

logout URI. CAS sẽ hủy Ticket-Granting Cookie và kiểm tra /logout URI có

chứa tham số url hay không. Nếu tham số “url” có giá trị, một thông báo đăng

xuất thành công sẽ được hiển thị với một liên kết đến giá trị url, ngược lại thì chỉ

có thông báo đăng xuất thành công.

3.8. Xác thực trong CAS

Trong bản cài đặt của CAS không xác định một phương pháp xác thực cố

định nào mà sẽ do các quản trị của từng hệ thống khi xây dựng thêm vào dùng

cho phù hợp với mô mình tổ chức đang sử dụng. Hiện CAS đang hỗ trợ các

phương pháp xác thực LDAP, X509, Kerberos, NIS, AD …

3.8.1. Xác thực CAS dựa trên cơ sở dữ liệu

Phương pháp này được thiết kế chủ yếu cho các tổ chức với người dùng nhất

định, vì lý do kỹ thuật, tổ chức không sử dụng LDAP của họ trong một cơ sở dữ

liệu. Đối với LDAP xác thực, khả năng chịu lỗi được đảm bảo bởi các dữ liệu dự

phòng máy chủ, và hai chế độ được cung cấp:

Đối với "người sử dụng" kết nối (database_bind) dùng để xác thực người

dùng cũng phải được báo cáo cho cơ sở dữ liệu. Xác thực thành công nếu các

thông tin đăng nhập được cung cấp bởi người sử dụng có thể kết nối với cơ sở dữ

liệu.

Hình thức “database_search”sử dụng một kết nối đặc quyền cho cơ sở dữ

liệu và thông tin đăng nhập của người sử dụng được lưu trữ trong một bảng. Xác

thực là thành công khi kết hợp được thực hiện giữa các thông tin được cung cấp

bởi người sử dụng và những người có trong cơ sở dữ liệu.

3.8.2. Chứng chỉ x509

X509 thường được sử dụng để chứng thực của các ứng dụng web.Khi chứng

chỉ được gửi qua trình duyệt đến máy chủ CAS, nó có thể phục vụ người dùng

của nó để xác thực. Khi người dùng sử dụng một chứng chỉ x509, máy chủ CAS:

Kiểm tra tính hợp lệ của chứng chỉ (PKI).

Nhận dạng người sử dụng,dựa trên LDAP hoặc cơ sở dữ liệu.

Trang 63


3.8.3. Giao thức Kerberos

Hình thức này không thực hiện trong phiên bản hiện hành của Generic

Handler nhưng xác thực Kerberos được sử dụng tại một số trường đại học Mỹ.

3.8.4. Một tập tin

Generic Handler cuối cùng cung cấp (ban đầu cho mục đích thử nghiệm,

nhưng phương pháp này xác thực có thể được sử dụng cho những trường hợp rất

đặc biệt) có khả năng xác thực người dùng về một loại file Unix passwd người

sử dụng (được tạo ra htpasswd).

Trang 64


3.9. Triển khai ứng dụng CAS:

Mô hình triển khai

Hình 3.18: Mô hình triển khai ứng dụng

Các bước triển khai:

Sử dụng hệ điều hành máy chỉ linux: Centos 5

Cài đặt java

Cài đặt tomcat

Cấu hình CAS kết nối với LDAP

Cài đặt Zimbra, joomla, liferay, phpBB, vtigercrm.

Tích hợp các dịch vụ với CAS.

Cấu hình CAS.

Build CAS và LDAP.

Thực hiện kết nối Zimbra với CAS.

Cài đặt mod kết nối joomla với CAS.

Cấu hình code để them chức năng CAS cho phpbb.

Thực hiện đăng nhập vào CAS và kiểm tra Single Sign On giữa các ứng

dụng.

Trang 65


Kết chương III:

Trình bày tổng quát về sản phẩm CAS của đại học Yale sử dụng công nghệ

java, tìm hiểu về kiến trúc, cách thức hoạt động của giao thức, triển khai CAS

thành trung tâm xác thực tập trung và cấu hình các dịch vụ xác thực qua CAS.

Trang 66


KẾT LUẬNSau thời gian ba tháng tìm hiểu, nghiên cứu và thực hiện đồ án em đa tìm

hiểu được các vấn đề sau:

Kết quả đạt được

1. Nghiên cứu và tìm hiểu về đăng nhập một lần – single sign on, hiểu rõ

được các khái niệm, công nghệ single sign on đang được sử dụng trên thế giới.

2. Tìm hiểu về vấn đề an toàn trong single sign on, các kiến trúc, giao thức

và các nguy cơ, rủi ro, lỗ hổng an ninh có thể lợi dụng để tấn công. Từ đó đề ra

các chính sách, giải pháp để tăng cường bảo mật cho hệ thống sử dụng single

sign on cả ở phía server lẫn người sử dụng.

3. Tìm hiểu sản phẩm ứng dụng thực tế là Central Authentication Service

(CAS). Hiểu rõ được các khái niệm, công nghệ , cách thức hoạt động và cách

triển khai sản phẩm để ứng dụng vào hệ thống.

4. Ứng dụng CAS vào hệ thống:

Biên dịch và triển khai CAS trên hệ điều hành Linux.

Kết nối CAS với cơ sở dữ liệu Openldap.

Thay đổi giao diện đăng nhập CAS, việt hóa.

Cài đặt, cấu hình hệ thống cộng tác mail server Zimbra cho tên

miền nội bộ kma.vn, thực hiện gửi và nhận thư.

Cài đặt cấu hình web site bằng joomla.

Cài đặt diễn đàn bằng sản phẩm ma nguồn mở phpBB.

Cài đặt hệ thống quan hệ khách hàng vtigercrm kết nối với LDAP

zimbra

Thực hiện cấu hình signle sign on tất cả các ứng dụng, chỉ cần đăng

nhập vào CAS hoặc ứng dụng bất kì người dùng không phải đăng

nhập lại khi sử dụng ứng dụng khác.

Sinh chứng chỉ và cấu hình SSL.

5. Thực hiện kiểm tra độ an toàn hệ thống

Thực hiện Sniff bằng wireshark khi đăng nhập CAS sử dụng

http,thực hiện tấn công chiếm phiên đăng nhập bằng các thông

Trang 67


tin cookie thu được. Kết quả kẻ tấn công có thể cướp phiên đăng

nhập của người dùng.

Thực hiện lấy cookie trên máy tính người dùng để sử dụng phiên

đăng nhập CAS.

Scan web bằng công cụ kiểm tra bảo mật acunetix web

vulnerability scanner.

6. Triển khai thực tế

Triển khai trên hệ thống cá nhân với tên miền nội bộ kma.vn. Hệ

thống gồm máy chủ CAS, cài đặt hệ thống mail Zimbra, cổng thông

tin, diễn đàn. Hệ thống hoạt động tốt người dùng có thể sử dụng

chức năng đăng nhập một lần khi sử dụng các ứng dụng.

Triển khai thực tế trên cổng thông tin điện tử tỉnh Cao Bằng, Điện

Biên.

Các vấn đề chưa làm được

Chưa thực hiện Single Sign Out cho tất cả các ứng dụng.

Khả năng mở rộng CAS cho các ứng dụng khác còn hạn chế.

Chỉnh sửa code CAS chỉ cho phép đăng nhập CAS từ các trình duyệt

hỗ trợ ma hóa cao. Không cho đăng nhập từ các trình duyệt quá cũ độ

an toàn kém.

Biên dịch CAS để người dùng có thể sử dụng chứng chỉ X 509 đăng

nhập và các ứng dụng thay cho user/password.

Hướng Phát triển

Nghiên cứu tích hợp thêm các ứng dụng để có thể single sign on: Các

sản phẩm HRM, CRM.

Tăng cường bảo mật an toàn hệ thống single sign on.

Cho phép người dùng sử dụng các chứng chỉ có thể đăng nhập.

Thực hiện chứng thực chéo cho các CAS server khác nhau.

Xây dựng web site quản lí CAS tập trung, người dùng có thể tự đăng kí

người dùng, đổi mật khẩu để sử dụng hệ thống.

Trang 68


TÀI LIỆU THAM KHẢO1. http://www.jasig.org/cas

2. http://wiki.zimbra.com/wiki/CASifying_Zimbra_6.0

3. http://www.liferay.com/community/wiki/-/wiki/Main/

CAS+Liferay+6+Integration;jsessionid=28B0944BB677F79735BD

EBA91BA97B08.node-1

4. http://joomlacode.org/gf/project/auth_manager/

5. https://sourcesup.cru.fr/projects/casldapauthbb/

6. SANS Institute , Secure implementation of Enterprise single sign-on

product in an organization.

7. Thomas Groß ,Security Analysis of the SAML Single Sign-on

Browser/Artifact Profile.

8. Đồ án: Tìm hiểu công nghệ portal Liferay, tiến hành xây dựng cổng

thông tin cho khoa Công Nghệ Thông Tin – Đại Học Nông Lâm

Tp.HCM.

Trang 69

https://sourcesup.cru.fr/projects/casldapauthbb/

http://joomlacode.org/gf/project/auth_manager/

http://www.liferay.com/community/wiki/-/wiki/Main/CAS+Liferay+6+Integration;jsessionid=28B0944BB677F79735BDEBA91BA97B08.node-1



http://wiki.zimbra.com/wiki/CASifying_Zimbra_6.0

http://www.jasig.org/cas


PHỤ LỤC

Hướng dẫn cấu hình SSO(Hệ thống đăng nhập một lần)

sử dụng CAS cho Zimbra, liferay, Joomla, phpbbCác bước triển khai:

Cài đặt java

Cài đặt tomcat

Cài đặt Zimbra

Download Cas-server 3.4, cấu hình kết nối LDAP Zimbra

Cài đặt Liferay kết nối tới LDAP của Zimbra

Tích hợp CAS

1. Install & Configure Java Download Package jdk-xxx-linux-i586.bin

Copy to /usr/local/src

[root@casserver src]# chmod a+x jdk-xxx-linux-i586.bin

[root@casserver src]# ./jdk-xxx-linux-i586.bin

mv jdk1.5.0_11 /usr/local/java

Sửa etc/profile :export JAVA_HOME=/usr/local/java

export PATH=$PATH:$JAVA_HOME/bin

[root@casserver src]# source profile

2. Install & Configure TomCat Download package apache-tomcat-xxx.tar.gz

Copy vào : /usr/local/src

[root@casserver src]# tar -xzf apache-tomcat-5.5.20.tar.gz

[root@casserver src]# mv apache-tomcat-5.5.20 /usr/local/tomcat

Khởi động Tomcat

[root@casserver src]# cd /usr/local/tomcat/bin

[root@casserver src]# ./startup.sh

Mở trình duyệt gõ http://localhost:8080/ để test

3. Build CAS và LDAP

Trang 70

http://localhost:8080/

mailto:root@CAS

mailto:root@CAS

mailto:root@CAS

mailto:root@CAS

mailto:root@CAS

mailto:root@CAS

mailto:root@CAS


Download package cas-server-xxx.tar.gz

Sau khi tải CAS Server về, bung ra một thự mục CAS-server-3.3.2

Mở pom.xml trong %CAS_HOME%/CAS-server-webapp, thêm phần sau:<dependency>

<groupId>${project.groupId}</groupId>

<artifactId>cas-server-support-ldap</artifactId>

<version>${project.version}</version>

</dependency>

Mở deployerConfigContext.xml trong thư mục CAS_home/CAS-server-

webapp/src/main/webapp/WEB-INF và sửa lại nội dung như sau:

Trong thẻ <beans>…</beans> thay thế AuthenticatedLDAPContextSource

bằng nội dung như sau:

Xóa bỏ khối :<bean

class="org.jasig.cas.authentication.handler.support.SimpleTestU

sernamePasswordAuthenticationHandler" />

Thêm vào các khối sau:<bean

class="org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandle

r">

<property name="filter"

value="uid=%u" />

<property name="searchBase"

value="dc=asianux,dc=org,dc=vn" />

<property

name="contex

tSource"

ref="context

Source" />

</bean>

</list>

</property>

</bean>

Trang 71

<bean id="contextSource"

class="org.springframework.ldap.core.support.LdapContextSource">

<property name="anonymousReadOnly" value="false" />

<property name="password" value="admin123" />

<property name="pooled" value="true" />

<property name="urls">

<list>

<list>

<value>ldap://192.168.1.11:389/</value>

</list>

</property>

<property name="userDn"

value="uid=admin,ou=people,dc=asianux,dc=org,dc=vn" />

<property name="baseEnvironmentProperties">



<map>

<entry>

<key><value>java.naming.sec

urity.authentication</value></key>

<value>simple</value>

</entry>

</map>

Trang 72

</property>

</bean>

Build lại CAS-server với lệnh: mvn package install (đa cài đặt maven).Sau

build thành công chép CAS.war trong thư mục %CAS_HOME%/CAS-server-

webppp/target vào thư mục webapp của tomcat.

4. CASify Zimbra 6.0 Import the Java CAS Client :

Download http://www.ja-sig.org/downloads/cas-clients/

Copy the cas-client-core-3.1.x.jar into /opt/zimbra/jetty/common/lib.

Sửa đổi thông số trong /opt/zimbra/jetty/etc/zimbra.web.xml.in before

the first <servlet> section (~line 230) and replace cas.url.com:port and

zimbra.url.com:port.

Default ports are 8443 for the CAS Server and 443 for the Zimbra Web

Client (or 80 if HTTP is used instead of HTTPS)



<filter>

<filter-name>CasSingleSignOutFilter</filter-name>

<filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class>

</filter>

<filter-mapping>

<filter-name>CasSingleSignOutFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

<listener>

<listener-class>org.jasig.cas.client.session.SingleSignOutHttpSessionListener</

listener-class>

</listener>

<filter>

<filter-name>CasAuthenticationFilter</filter-name>

Trang 73

http://www.ja-sig.org/downloads/cas-clients/


<filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-

class>

<init-param>

<param-name>casServerLoginUrl</param-name>

<param-value>http://cas.asianux.org.vn/cas/login</param-value>

</init-param>

<init-param>

<param-name>serverName</param-name>

<param-value>http://mail.asianux.org.vn</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>CasAuthenticationFilter</filter-name>

<url-pattern>/public/preauth.jsp</url-pattern>

</filter-mapping>

<filter>

<filter-name>CasValidationFilter</filter-name>

<filter-

class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>

<init-param>

<param-name>casServerUrlPrefix</param-name>

<param-value>http://cas.asianux.org.vn/cas</param-value>

</init-param>

<init-param>

<param-name>serverName</param-name>

<param-value>http://mail.asianux.org.vn</param-value>

</init-param>

<init-param>

<param-name>redirectAfterValidation</param-name>

<param-value>true</param-value>

</init-param>

</filter>

<filter-mapping>

Trang 74


<filter-name>CasValidationFilter</filter-name>


</filter-mapping>

<filter>

<filter-name>CasHttpServletRequestWrapperFilter</filter-name>

<filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-

class>

</filter>

<filter-mapping>

<filter-name>CasHttpServletRequestWrapperFilter</filter-name>


</filter-mapping>

Tương tự cho file /opt/zimbra/jetty/etc/zimbraAdmin.web.xml.in nhưng thay

bằng các cổng của https

Đăng nhập tài khoản Zimbra, sinh key cho domain:zmprov gdpak

asianux.org.vn

Copy key vào file preauth.jsp(/opt/zimbra/jetty/webapps/zimbra/public/preauth.jsp)Nội dung file:

<%@ page import="java.security.InvalidKeyException"%>

<%@ page import="java.security.NoSuchAlgorithmException"%>

<%@ page import="java.security.SecureRandom"%>

<%@ page import="java.util.HashMap"%>

<%@ page import="java.util.Map"%>

<%@ page import="java.util.Iterator"%>

<%@ page import="java.util.TreeSet"%>

<%@ page import="javax.crypto.Mac"%>

<%@ page import="javax.crypto.SecretKey"%>

<%!

public static final String DOMAIN_KEY =

"288106fc72748eaed3305eb659530946e1ee4adffcac157e8d0dc1f1e47fc36d";

Trang 75


public static String generateRedirect(HttpServletRequest request, String name) {

HashMap params = new HashMap();

String ts = System.currentTimeMillis()+"";

params.put("account", name);

params.put("by", "name"); // needs to be part of hmac

params.put("timestamp", ts);

params.put("expires", "0"); // means use the default

String preAuth = computePreAuth(params, DOMAIN_KEY);

return request.getScheme()+"://"+request.getServerName()

+":"+request.getServerPort()+"/service/preauth/?" +

"account="+name+

"&by=name"+

"&timestamp="+ts+

"&expires=0"+

"&preauth="+preAuth;

}

public static String computePreAuth(Map params, String key) {

TreeSet names = new TreeSet(params.keySet());

StringBuffer sb = new StringBuffer();

for (Iterator it=names.iterator(); it.hasNext();) {

if (sb.length() > 0) sb.append('|');

sb.append(params.get(it.next()));

}

return getHmac(sb.toString(), key.getBytes());

}

private static String getHmac(String data, byte[] key) {

try {

ByteKey bk = new ByteKey(key);

Mac mac = Mac.getInstance("HmacSHA1");

mac.init(bk);

return toHex(mac.doFinal(data.getBytes()));

Trang 76


} catch (NoSuchAlgorithmException e) {

throw new RuntimeException("fatal error", e);

} catch (InvalidKeyException e) {

throw new RuntimeException("fatal error", e);

}

}

static class ByteKey implements SecretKey {

private byte[] mKey;

ByteKey(byte[] key) {

mKey = (byte[]) key.clone();;

}

public byte[] getEncoded() {

return mKey;

}

public String getAlgorithm() {

return "HmacSHA1";

}

public String getFormat() {

return "RAW";

}

}

public static String toHex(byte[] data) {

StringBuilder sb = new StringBuilder(data.length * 2);

}

%>

<%

String casUser = request.getRemoteUser().toString().trim();

//String casUser = new String("test08");

String redirect = generateRedirect(request, casUser+"@asiaux.org.vn'');

System.out.println("CAS redirect: " + redirect);

response.sendRedirect(redirect);

Trang 77


%>

chown zimbra:zimbra /opt/zimbra/jetty/webapps/zimbra/public/preauth.jsp

Thay đổi đường dẫn login và logout

zmprov md yourdomain.com zimbraWebClientLogoutURL

https://cas.url.com:port/cas/logout

zmprov md yourdomain.com zimbraAdminConsoleLoginURL

https://zimbra.url.com:port/zimbraAdmin/public/preauth.jsp

zmprov md yourdomain.com zimbraAdminConsoleLogoutURL

https://cas.url.com:port/cas/logout

5.Cấu hình CAS cho LiferayKết nối LDAP cho liferay :

Cấu hình CAS cho Liferay

6. Kiểm tra độ an toàn

Sử dụng wireshark bắt gói tin khi không sử dụng https

Trang 78


Kết quả: Bắt được các gói tin dưới dạng Clear text, có thể sử dụng trực

tiếp các thông tin cookie bắt được sử dụng công cụ Cookie Editor để

sử dụng thông tin cookie thu được chiếm phiên đăng nhập.

Khi sử dụng https: Nếu kẻ tấn công bằng cách nào đó lấy được 2 tham

số Cookie trên trình duyệt người dùng:

Trang 79


Kẻ tấn công sử dụng lại thông tin 2 Cookie để chiếm phiên thành

công.

Trang 80

tìm hiểu hệ thống đăng nhập một lần sso

Documents