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 (adsbygoogle = window.adsbygoogle || []).push({});
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) (adsbygoogle = window.adsbygoogle || []).push({});
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ỏ (adsbygoogle = window.adsbygoogle || []).push({});
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