2.5.1. Username và Password
Sự kết hợp của một username và password là cách xác thực cơ bản nhất. Với kiểu xác thực này, chứng từ ủy nhiệm người dùng được đối chiếu với chứng từ được lưu trữ trên CSDL hệ thống, nếu trùng khớp username và password, thì người dùng được xác thực và nếu không người dùng bị cấm truy cập. Phương thức này không bảo mật lắm vì chứng từ xác nhận người dùng được gửi đi xác thực trong tình trạng plain text, tức không được mã hóa và có thể bị tóm trên đường truyền.
2.5.2. Giải pháp kiểm soát truy nhập hệ thống SSO
Mỗi lần truy nhập một dịch vụ của hệ thống, người dùng phải khai báo thông tin về mật khẩu và tên đăng nhập cho hệ thống xác thực. Do vậy, người dùng phải nhớ rất nhiều cặp tên truy cập và mật khẩu khác nhau và phải đăng nhập nhiều lần. Điều này gây khó khăn cho người dùng và nhà cung cấp dịch
vụ, người quản trị cũng phải đối mặt với một loạt vấn đề như bảo mật, mã hóa, lưu trữ cơ sở dữ liệu.
Trước đây, để giải quyết vấn đề này, người sử dụng bắt buộc phải nhớ các thông tin đăng nhập, hoặc lưu trong các file có mã hóa, hoặc sử dụng một chương trình quản lý tài khoản trên máy tính của họ. Tuy nhiên, người dùng vẫn phải nhớ quá nhiều tên truy cập và mật khẩu, người quản trị luôn nhận được các yêu cầu tạo lại mật khẩu và kích hoạt lại tài khoản người dùng, do họ gặp phải các sự cố về thông tin đăng nhập.
Một giải pháp cho vấn đề trên là sử dụng một kỹ thuật xác thực một lần cho tất cả các tài khoản có yêu cầu bảo mật khác nhau. Giải pháp này vừa đảm bảo tính thuận tiện, vừa tăng độ bảo mật khi sử dụng. Hơn nữa, áp lực trong việc quản lý tài khoản đối với nhà quản trị hệ thống có thể được giảm xuống. Hệ thống SSO có khả năng tích hợp và kết hợp các hệ thống tài khoản khác nhau. Điều này sẽ đem lại lợi ích cả cho người dùng và nhà cung cấp dịch vụ.
Ưu điểm của giải pháp SSO
Đối với người dùng: Hệ thống SSO cung cấp cho người dùng công cụ xác thực đăng nhập một lần. Công cụ này xác thực người dùng đăng nhập vào mọi hệ thống có tích hợp giải pháp SSO, vì vậy, người dùng chỉ cần nhớ một cặp tên truy cập và mật khẩu duy nhất.
Khi cập nhật mật khẩu và tên đăng nhập, người dùng chỉ cần cập nhật một lần cho toàn bộ các hệ thống có yêu cầu xác thực người dùng. Khi đã đăng nhập vào một hệ thống chứa các hệ thống con có tích hợp giải pháp SSO, người dùng có thể dễ dàng truy nhập vào các hệ thống con này mà không cần phải xác thực lại trong một khoảng thời gian nào đó, tùy thuộc vào chính sách quản trị.
Đối với nhà cung cấp dịch vụ, quản trị hệ thống: Người quản trị chỉ cần bảo mật và quản lý thông tin đăng ký của người dùng một lần, vì vậy có thể
giảm dung lượng cơ sở dữ liệu và tránh được các xung đột nảy sinh do phải xử lý mật khẩu của các hệ thống khác nhau, tăng khả năng mở rộng và triển khai các chiến lược bảo mật.
Người quản trị có thể thay đổi và cập nhật thông tin được bảo mật của người dùng khi cần thiết, một cách dễ dàng hơn so với việc thay đổi ở từng hệ thống riêng lẻ mà người dùng đó được phép truy cập. Điều này rất hữu ích khi người dùng thay đổi vị trí của mình với các cấp độ bảo mật khác nhau.
Nhược điểm của giải pháp SSO
Việc xử lý một loạt các hệ thống con có tích hợp giải pháp SSO không đơn giản, bởi vì mỗi hệ thống con có thể hoạt động trên các nền phần cứng và phần mềm khác nhau. Vì vậy, khi cài đặt sẽ phải giải quyết nhiều vấn đề liên quan đến tính tương thích và đồng bộ giữa các hệ thống.
Khi đã được xác thực thành công, người dùng có thể truy nhập vào nhiều ứng dụng trong hệ thống. Bởi vậy, nếu không được bảo mật tốt tại các hệ thống con, thì đối tượng tấn công khi tiếp cận vào một ứng dụng có thể tấn công vào toàn bộ hệ thống.
Các kỹ thuật mang tính mở áp dụng với hệ thống hoặc chưa được chuẩn hóa, hoặc chưa được cung cấp, có thể gây mâu thuẫn và không tương thích với các sản phẩm khác.
Thách thức đối với giải pháp SSO là làm việc theo kiến trúc, các cơ chế bảo mật độc lập đối với các nền ứng dụng. Để thuận tiện và đơn giản hơn khi giải quyết nhược điểm của SSO, người ta thường đi theo hướng xây dựng các ứng dụng sử dụng cơ sở hạ tầng bảo mật, xác thực người dùng chung, thông suốt giữa các ứng dụng. Điều này đòi hỏi phải có định dạng chung khi thể hiện các thông tin xác thực hoặc ủy nhiệm, sao cho tất cả các ứng dụng đều có thể hiểu và chấp nhận chúng. Đồng thời, phải đảm bảo được các ủy nhiệm là đúng đắn. Mặc dù có một số nhược điểm, nhưng giải pháp SSO vẫn đang
được triển khai rộng rãi ở nhiều nước trên thế giới, trong nhiều hệ thống thông tin có nhu cầu xác thực và bảo mật. Nó được đánh giá là một trong các giải pháp hiệu quả, tiện dụng và kinh tế khi triển khai trên diện rộng. Các vấn đề nêu trên sẽ được giải quyết trong thời gian tới khi chúng ta tăng cường chuẩn hóa và có các chính sách cụ thể cho vấn đề này.
Các hệ thống xác thực SSO đang được sử dụng rộng rãi là: CAS (Central Authentication Service), WebAuth. RSA Single Sign On Manager, Open Single Sign - On (OpenSSO) hoạt động dựa trên Token, Java Open SSO (JOSSO)[3].
2.5.2.1. Open SSO Enterprise
OpenSSO là một sản phẩm mã nguồn mở 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 Federation Manager và Sun System SAML v2 Java Plugin, kiểm soát truy nhập, đảm bảo an toàn các dịch vụ web và các dịch vụ định danh Web. Khi truy cập vào những tài nguyên được bảo vệ của người dùng, yêu cầu truy cập cần được xác thực và phải có đủ quyền truy cập. Khi một người gửi yêu cầu để truy cập tài nguyên được bảo vệ, policy agent chặn yêu cầu này và kiểm tra. Nếu OpenSSO token được tìm thấy không hợp lệ, policy agent sẽ yêu cầu máy chủ tiến hành xác thực và cấp phép.
Policy agent là ứng dụng web với nhiệm vụ ngăn tất cả yêu cầu đến ứng dụng, để kiểm tra xem người dùng đã xác thực hay chưa.
Hình 2.6: Cơ chế hoạt động của OpenSSO Cơ chế hoạt động của OpenSSO như sau:
- Từ trình duyệt, người dùng kết nối đến ứng dụng web.
- Policy Agent sẽ kiểm tra token có tồn tại trong URL hay không. Nếu token chưa tồn tại thì Policy Agent sẽ chuyển trình duyệt đến OpenSSO máy chủ.
- OpenSSO máy chủ xác thực người dùng thông qua trang đăng nhập. Người dùng nhập tên truy cập/mật khẩu để xác thực.
- OpenSSO (tạo ra session cho người dùng và kích hoạt nó nếu xác thực thành công).
- OpenSSO gửi token cho trình duyệt (trình duyệt sẽ lưu token dưới dạng cookie) và Trình duyệt sẽ gửi token đến cho Agent.
- Policy Agent sẽ lấy thông tin token gửi đến OpenSSO máy chủ để kiểm tra. - OpenSSO sẽ gửi thông tin đăng nhập (tên truy cập, mật khẩu) và thông tin vai trò đến Agent nếu kiểm tra token hợp lệ.
- Policy Agent sẽ quyết định cho phép truy cập ứng dụng hay không và ghi thông tin session trên URL[3].
2.5.2.2. Giải pháp Dịch vụ xác thực trung tâm CAS
CAS (Central Authenticate Service) là một giải pháp SSO mã nguồn mở được phát triển bởi đại học Yale, với các tính năng như sau:
- CAS hỗ trợ nhiều thư viện phía máy khách được viết bởi nhiều ngôn ngữ: PHP, Java, PL/SQL. Nó lấy thông tin SSO thông qua cookie. Cookie này sẽ bị hủy khi người dùng đă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à TGC (Ticket Granting Cookie) chứa một ID duy nhất.
- 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ư tên truy cập/mật khẩu, chứng chỉ khóa công khai X509,... để 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 cung cấp tính năng “Remember me”. Người phát triển 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. Khi người dùng mở trình duyệt thì CAS sẽ chuyển đến service URL tương ứng mà không cần hiển thị khung đăng nhập.
Chứng thực người dùng với máy chủ CAS: Người dùng nhập tên truy cập/mật khẩu vào khung đăng nhập. Các thông tin này được truyền cho CAS máy chủ thông qua giao thức HTTPS. 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 để đăng nhập với tất cả các ứng dụng (Hình 2.7).
Hình 2.7: Người dùng truy cập vào ứng dụng khi đã chứng thực với CAS máy chủ
Trường hợp người dùng truy cập vào ứng dụng khi đã chứng thực với CAS máy chủ:
- 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 máy chủ thông qua giao thức HTTPS.
- Nếu TGC này là hợp lệ, CAS máy chủ trả về một Service Ticket (ST) cho trình duyệt, trình duyệt truyền ST vừa nhận cho ứng dụng.
- Ứng dụng sử dụng ST nhận được từ trình duyệt và sau đó chuyển nó cho CAS máy chủ.
- CAS máy chủ 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 là người dùng này đã được chứng thực bởi CAS máy chủ.
- Ứng dụng đăng nhập cho người dùng và bắt đầu phục vụ người dùng. Trường hợp người dùng truy cập vào ứng dụng mà chưa chứng thực với CAS máy chủ:
- 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 máy chủ.
- Người dùng cung cấp tên truy cập/mật khẩu 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 máy chủ sẽ trả về cho trình duyệt đồng thời cả 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 nêu trên.
- Ứng dụng chuyển ST cho CAS máy chủ 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 2.8)[3].
Hình 2.8. Người dùng truy cập ứng dụng mà chưa chứng thực với CAS
2.5.3. Xác thực máy chủ bằng SSL
SSL (Secure Socket Layer) Giao thức do Netscape phát triển để bảo mật dữ liệu gửi và nhận trên Internet của các giao thức thuộc lớp ứng dụng như HTTP, LDAP hay POP3.
Nhiệm vụ: Xác thực server, xác thực client, mã hoá kết nối. Kiến trúc SSL: gồm 4 giao thức con sau:
- SSL Handshake.
- SSL Alert.
- SSL Record Layer.
SSL là một lớp (bảo mật) trung gian giữa lớp vận chuyển và lớp ứng dụng. SSL được xếp lớp lên trên một dịch vụ vận chuyển định hướng nối kết và đáng tin cậy, SSL nằm trong tầng ứng dụng của giao thức TCP/IP.
SSL Record Protocol: Sử dụng để trao đổi tất cả các kiểu dữ liệu trong một phiên – bao gồm các thông điệp, dữ liệu của các giao thức SSL khác và dữ liệu của ứng dụng. SSL Record Protocol liên quan đến việc bảo mật và đảm bảo toàn vẹn dữ liệu, mục đích là thu nhận những thông điệp mà ứng dụng chuẩn bị gửi, phân mảnh dữ liệu cần truyền, đóng gói, bổ xung header tạo thành một đối tượng bản ghi được mã hoá và có thể truyền bằng giao thức TCP.
- Handshake Protocol: Giao thức này được sử dụng để khởi tạo phiên SSL giữa client và Server, nhờ giao thức này các bên sẽ xác thực lẫn nhau và thoả thuận các tham số cho phiên làm việc sẽ được thiết lập.
- Alert Protocol: Sử dụng để mang các thông điệp của phiên liên quan tới việc trao đổi dữ liệu và hoạt động của các giao thức.
- Change Cipher Spec Protocol: Chứa một thông điệp mang giá trị 1 làm chuyển trạng thái của một phiên từ “đang chờ” sang “bền vững”.
Hoạt động xác thực máy SSL: Khi trình duyệt của một máy khách đến một Website bí mật của một máy chủ, máy chủ gửi một lời chào tới trình duyệt. Trình duyệt đáp lại bằng một lời chào. Việc tiến hành trao đổi lời chào, hoặc bắt tay cho phép 2 máy tính quyết định các chuẩn mã hoá và nén (mà chúng cùng hỗ trợ). Trình duyệt máy khách yêu cầu máy chủ đưa ra một chứng chỉ số. Máy chủ gửi cho trình duyệt một chứng chỉ đã được công nhận bởi CA. Trình duyệt kiểm tra chữ ký số có trên chứng chỉ của máy chủ, dựa vào khoá công khai của CA, khoá này được lưu giữ trong trình duyệt. Hoạt động này xác thực máy chủ thương mại.
Máy khách và máy chủ thoả thuận rằng mọi trao đổi phải được giữ bí mật, bởi vì những thông tin này là quan trọng. Để thực hiện bí mật, SSL sử dụng mã hoá khoá công khai (không đối xứng) và mã hoá khoá riêng (đối xứng). Thoạt đầu, trình duyệt sinh ra một khoá riêng dùng chung cho cả hai. Sau đó, trình duyệt mã hoá khoá riêng bằng khoá công khai của máy chủ. Khoá công khai của máy chủ được lưu giữ trong chứng chỉ số, máy chủ gửi chứng chỉ này cho trình duyệt trong quá trình xác thực. Một khi khoá được mã hoá, trình duyệt gửi nó cho máy chủ. Ngược lại, máy chủ giải mã thông báo bằng khoá riêng của nó và tìm ra khoá riêng dùng chung. Tất cả các thông báo giữa máy khách và máy chủ được mã hoá bằng khoá riêng dùng chung (cũng được biết đến như là một khoá phiên). Sau khi kết thúc phiên giao dịch, khoá phiên bị huỷ bỏ. Một kết nối mới lại bắt đầu tương tự[3].
2.5.4. Xác thực sử dụng token
Token là những phương tiện vật lý như các thẻ thông minh (smart card), thẻ đeo của nhân viên (ID badge) chứa thông tin xác thực hoặc bộ tạo mật khẩu dùng một lần (One Time Password - OTP). Ở đây OTP là mật khẩu dùng một lần, được tạo ra trên bộ tạo OTP (token) và kiểm tra trong hệ thống bảo mật riêng. OTP tự động thay đổi thường xuyên và chỉ tồn tại trong một thời gian ngắn (khoảng vài chục giây) cho từng lần truy nhập. Token có thể lưu trữ mã số nhận dạng cá nhân (PIN), thông tin về người dùng, lưu giữ hoặc tạo ra password. Các thông tin trên token chỉ có thể được đọc hoặc xử lý bởi các thiết bị hoặc hệ thống đặc dụng. Chẳng hạn như thẻ thông minh được đọc bởi đầu đọc thẻ smart card chuyên dụng, OTP được xử lý bởi hệ thống xác thực sử dụng yếu tố xác thực thứ hai là mật khẩu dùng một lần.
2.5.5. Giải pháp ký số, xác thực tài liệu trên nền tảng Web
Bài toán đặt ra là cần phải phát triển một hệ thống thông tin với giao diện người dùng trên nền web, có thể truy cập thông qua Internet. Người sử dụng
của hệ thống này có thể gửi tài liệu đến máy chủ các tập tin có định dạng khác nhau (Word, PDF, Excel, JPEG, GIF...). Để xác thực người gửi và đảm bảo tài liệu sau khi gửi đi không bị sửa đổi trái phép thì hệ thống cần cung cấp cho người dùng khả năng có thể ký số các tập tin được gửi đi[4].
2.5.5.1. Giải pháp ký số trên máy client
Ký số yêu cầu truy cập vào khóa bí mật của người ký. Khóa bí mật của