PORTAL - Cơ chế Single Sign On - 2

Central Authenticate Service 

- Giới thiệu
- Triển khai
- Các giải pháp bảo mật ứng dụng

C - Central Authenticate Service (CAS)
CAS là gì?

- Là một giải pháp Single Sign On, mã 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ũng được tạo ra bởi Yale University.
- Giới thiệu thêm tính năng mới là Proxy Authentication.
• JA-SIG CAS 3.0
- Trở thành JA-SIG project vào 2004.
- Mục đích là làm cho CAS tương thích cao hơn, mềm dẻo hơn.
- 100% tương thích với CAS 2.0

CAS URIs

CAS thực hiện Single Sign On thông qua những URI và sinh ra những ticket khác nhau. CAS sẽ sử dụng những URI sau:
-/logout
o Hủy Single Sign On session và ticket granting cookie
o Hiển thị một trang trạng thái để báo với user đã đă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
oKiể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.
oNhữ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 sẽ 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 mã lỗi với thông điệp thất bại tương ứng. Sau đây là một số mã lỗi được trả về response nếu /serviceValidate thất bại.
oINVALID_REQUEST: Không tìm thấy tham số cần tìm trong request.
oINVALID_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.
oINVALID_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.
oINTERNAL_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à mã lỗi giống tương tự. Khi thành công, respone chứa PGT và danh sách các proxy cá 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
-/proxy
oCung cấp proxy ticket đến những service, lấy PTG thông qua /proxyValidate hoặc /serviceValidate
oNhữ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.
o/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 mã lỗi với thông điệp tương ứng. Các mã 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ệ.
-/samlValidate
o SAML (Secuirty Assertion Markup Language) framework

CAS Tickets

Ticket đơn giản 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 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-”

Nguyên tắc hoạt động của CAS

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 mã hóa trước truyền đi.
-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

Truy cập vào ứng dụng

-Người dùng truy cập vào ứng dụng khi đã chứng thực với CAS server.
oNgười dùng truy xuất ứng dụng thông qua trình duyệt.
oỨ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.
oNế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.
oỨng dụng sử dụng ST nhận được từ trình duyệt và sau đó chuyển nó cho CAS server.
oCAS 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 đã được chứng thực bởi CAS server.
oỨng dụng đăng nhập cho người dùng và bắt đầu phục vụ người dùng.

Hình - Người dùng truy cập vào ứng dụng khi đã chứng thực với CAS server
-Người dùng truy cập vào ứng dụng mà chưa chứng thực với CAS server
oNgườ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
oNgườ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
oXác thực thành công, CAS server sẽ trả về cho trình duyệt đồng thời TGC và ST
oỨng dụng 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
oỨng dụng chuyển ST cho CAS server và nhận về ID của người dùng
oỨng dụng đăng nhập cho người dùng và bắt đầu phục vụ người dùng