Đ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 đã được mã 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 mã 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
đó. 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 đã đượ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
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 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 của 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.
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
đã 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 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.
2.6.3. Open source được phát triển bời đại học Stanford
Tiêu chí Mức độ Đánh giá
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 mã 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ộng
Rất tốt Bởi vì WebKDC là không trạng thái (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
Tiêu chí Mức độ Đánh giá
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ự 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 đã 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 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
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 đã 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 mã 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.
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 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 tạo ra bởi Yale University. Giới thiệu thêm tính năng
• JA-SIG CAS 3.0: Trở thành JA-SIG project vào 2004. Mục đích làm