c5 22c 33223 E£+vEEseereeereseresHình 3.20 Giao diện phân quyền Viewer cho Úse...--2- 2 52+EeEE+E+E£EeEe£zxzxzedHình 3.21 Giao diện profile của User trên Grafana...- - - 5c 3x *+stsserre
Giới thiệu về cơ chế xác thực -: -:¿©++2x+2xt2x+zrxerxerxrrxezrrsred 2
Khái quát về xác thực - 2c s+x+2E+EESEEEEEEEEEEEEEEEEErkerrrerrex 2
Xác thực là quá trình xác nhận tính đáng tin cậy của một đôi tượng hoặc người dùng trong hệ thông Điều này thường bao gồm việc chứng minh những lời khai báo của người đó về một vật thé hoặc sự thật liên quan đến chính họ. Xác thực có thể liên quan đến việc công nhận nguồn gốc của một đối tượng và thậm chí cả việc kiểm tra nhận dạng của một người.
Quá trình xác thực đóng vai trò quan trọng trong việc bảo đảm an toàn và tính bảo mật của hệ thống Khi một thực thé yêu cầu thiết lập liên lạc, hệ thống sẽ tiến hành xác thực bang cach su dung thong tin nhan dang cua thuc thé dé xác định quyền truy cập của nó Trong quá trình này, thông tin bí mat được trao đôi giữa hai bên đề đảm bảo tính an toàn và toàn vẹn của hệ thống.
Access Manager Authentication user Registry Services
1 Requests prower HTTPIHTTPS WEB SERVER eee 2
Hình 1.1 Qua trình xác thực người dùng khi đăng nhập vào web server
Có ba cách chính dé người dùng xác thực với hệ thống:
- Yéu tố kế thừa: Điều nay bao gồm những đặc điểm tự nhiên của người dùng như vân tay, mẫu hình võng mạc, quét mống mắt, giọng nói, chữ ký, hoặc các tín hiệu sinh học đặc hữu khác của cơ thể.
- _ Yếu tố sở hữu: Bao gồm các vật phẩm hoặc thông tin mà người dùng sở hữu như chứng minh thư, chứng chỉ an ninh, chứng chỉ phần mềm, hoặc thông tin từ điện thoại di động.
- Yếu tố tri thức: Bao gồm những thông tin mà người dùng biết như tên người dùng, ID, mật khâu hoặc số định danh cá nhân (PIN).
Tuy nhiên, các hệ thống xác thực ngày nay đối mặt với nhiều thách thức Mật khâu, mặc dù phô biến, thường dé bị đánh cắp, đặc biệt là bởi rất nhiều công cụ được cung cấp miễn phí trên mạng Dé giải quyết vấn đề này, cần có sự sáng tạo trong việc xây dựng các phương thức xác thực mới và mạnh mẽ hon, có thé kết hợp nhiều yếu tố khác nhau để tăng cường tính bảo mật [1] s* Phân biệt xác thực (Authentication) và ủy quyền (Authorization)
- Xac thực là quá trình xác định khả năng của một bên để xác định danh tính của bên kia trong một giao dịch Quá trình này có thê diễn ra một chiều (one-way) hoặc hai chiều (two-way) Trong ngữ cảnh an toàn thông tin, xác thực đảm bảo rằng thực thể tham gia trong giao dịch là ai họ nói họ là, và không có sự giả mạo xảy ra.
- Uy quyền là khả năng cho phép hoặc ngăn chặn việc sử dụng một tai nguyên hoặc dịch vụ cụ thể bởi một bên đã xác thực Trong môi trường an toàn thông tin, ủy quyền quản lý quyền truy cập và quyền hạn sau khi quá trình xác thực đã được thực hiện Nó là cơ sở để kiểm soát quyền truy cập và dam bao rằng người dùng chỉ có thé truy cập vào những phan của hệ thống mà họ được phép.
Hình 1.2 Minh họa quá trình xác thực và quá trình ủy quyén
1.1.2 Các kỹ thuật xác thực
Xác thực bằng thẻ là một phương pháp phổ biến dé đảm bảo an ninh và kiểm soát quyền truy cập trong các hệ thống máy tính, mạng, và máy chủ Đây là một giải pháp kinh tế cho nhiều tô chức, đặc biệt là trong lĩnh vực ngân hàng và tai chính Mỗi người dùng sẽ được cung cấp một thẻ riêng, và hệ thong sé tao ra một số PIN duy nhất khi người dùng sử dung thẻ lần đầu tiên Thông tin trên mỗi thẻ được lưu trữ trong một trường duy nhất, và trường này cũng được mã hóa và lưu trữ trên cơ sở dữ liệu máy chủ Việc mã hóa thường sử dụng các thuật toán mạnh mẽ như DES, 3DES, AES với độ dài khóa 128-bit, 192-bit, hoặc 256- bit Khi người dùng muốn đăng nhập, họ cần đưa thẻ vào thiết bị đọc thẻ và nhập số PIN Nếu thông tin đúng, người dùng sẽ được đăng nhập thành công; ngược lại, họ phải thử lại Hệ thống có khả năng tự động khóa tài khoản sau một số lần đăng nhập không thành công liên tiếp, nhằm ngăn chặn các cuộc tấn công. Người dùng cũng có thé thay đổi số PIN của mình dé tăng cường an toàn Người dùng có thê thay đổi số PIN bắt cứ lúc nào Số PIN có thể gồm các kí tự, con số Người dùng nên tránh đặt những số PIN qua dễ nhớ dé đảm bảo an toàn.
Mặc dù hệ thống xác thực băng thẻ có nhiều ưu điểm như khả năng ngăn chặn việc làm giả mạo thẻ, nhưng cũng có nhược điểm của nó Chi phí cho các thiết bị đọc thẻ và triển khai hệ thống trên diện rộng có thé là đáng kê Ngoài ra, mặc dù mã PIN khó nhớ, nhưng nó vẫn có khả năng bị đánh cắp, và vấn đề này vẫn là mối quan ngại chính khi triển khai phương pháp này ngoài lĩnh vực ngân hàng.
1.1.2.2 Xác thực dựa theo tri thức
Phương pháp xác thực dựa trên tri thức, đặc biệt là sử dụng mật khẩu, là một trong những phương tiện phổ biến nhất dé đảm bảo an ninh và kiểm soát quyền truy cập trong các hệ thống máy tính, mạng, và máy chủ Mặc dù có sự đa dạng, việc sử dụng mật khâu dưới dạng dãy ký tự vẫn là lựa chọn phô biến và rộng rãi.
Khi người dùng đăng ký vào hệ thống, họ sẽ tự tạo một mật khâu, được mã hóa và lưu trữ trên cơ sở dữ liệu máy chủ Quá trình đăng nhập yêu cầu người dùng nhập tên và mật khẩu, sau đó mật khâu này sẽ được mã hóa và so sánh với dữ liệu trong cơ sở dit liệu Nếu khớp, người dùng có quyền truy cập vào hệ thống.
Mặc dù phương pháp này tiết kiệm chi phí vì không đòi hỏi thiết bị vật lý như xác thực bang thẻ, nhưng cũng mang theo nhược điểm đáng kể Mật khẩu thường dễ bị tấn công và dự đoán do phụ thuộc vào thói quen, sở thích, hoặc thông tin cá nhân dé đoán Các công cụ từ điển để dò mật khẩu cũng là mối de dọa, khiến cho tài khoản dé bị tan công Dé tăng cường an ninh, người dùng cần tạo mật khâu có tính an toàn cao, tránh sử dụng thông tin dé đoán và thường xuyên thay đổi mật khẩu Việc này giúp giảm thiểu nguy cơ tan công va bảo vệ tài khoản người dùng khỏi các mối đe dọa an ninh trực tuyến.
1.1.2.3 Xác thực dựa theo sinh trắc học
Hình 1.3 Mô hình xác thực bằng sinh trắc học
Sinh trắc học là một ngành khoa học bao gồm các phương pháp nhận dạng duy nhất con người dựa trên một hoặc nhiều đặc điểm thể chất hoặc hành vi nội tại Nó đã trở thành một trong những hệ thống bảo mật phổ biến và đáng tin cậy, thay thế cho hệ thống bảo mật dựa trên mật khẩu Các đặc điểm sinh trắc học có thé được chia thành ba loại chính là 'Hình thai’, 'Hanh vi' và 'Sinh hoc’ Hình thái có liên quan đến hình dang của cơ thể như võng mạc, giọng nói, dấu vân tay (ngón tay, ngón cái, lòng bàn tay), mong mat, hinh hoc ban tay, nhan dang khuôn mặt, tai, chiều cao, cân nặng, da, tĩnh mạch, giới tính Hành vi liên quan đến hành vi của một người như dáng đi, chữ ký, động lực gõ phím, giọng nói, lái xe, chơi game Sinh học có liên quan đến phần bên trong của cơ thể sống như nhịp tim, mui, DNA, máu Giọng nói có thể được phân loại theo cả đặc điểm hình thái và hành vi vì mỗi người có một giọng nói khác nhau, nhưng việc nhận dạng giọng nói chủ yếu dựa trên nghiên cứu về cách một người nói, do đó thường được phân loại là hành vi [2]
Xác thực dựa trên sinh trắc học là một phương thức phô biến, sử dụng các công nghệ như nhận dạng vân tay, võng mạc, khuôn mặt, giọng nói, và các chi tiết sinh học khác trên cơ thể người dùng Ưu điểm chính của các phương pháp xác thực này là tồn tại mối quan hệ chặt chẽ giữa cá nhân (người dùng) và dữ liệu xác thực (dữ liệu sinh trắc học) Hơn nữa, rất khó dé sao chép các đặc điểm sinh trắc học của một cá nhân so với hầu hết các phương thức xác thực khác nên độ an toàn của hệ thống rất cao Tuy nhiên, có một hạn chế trong xác thực sinh trắc học, đó là sự không chắc chắn của kết quả xác minh, ví dụ như trong xác thực dấu vân tay; có thê xảy ra lỗi do vị trí ngón tay không đúng.
Các số đo sinh học đóng vai trò quan trọng trong việc cung cấp độ đảm bảo cho quá trình nhận dạng người truy nhập, bao gồm các đặc trưng vật lý, hình dang, và nhận dang Dé tăng cường mức độ an toàn, các số đo sinh học thường được tích hợp với các nguyên tắc xác thực khác, tạo ra một hệ thống nhận dạng với độ tin cậy cao Dưới đây là một danh sách các số đo vật lý được sắp xếp theo hiệu suất giảm dan:
Cac kỹ thuật xác thực - - c Sc 122112 112v 19 111181 11v nrưy 3
Thê hệ the RFID đâu tiên được sử dụng vào những năm 1950 cho mục đích quân sự, nhưng nó chỉ giới hạn ở mục đích nhận dạng Vào thời điểm đó, việc sử dụng chúng chỉ giới hạn ở việc truyền số sê-ri không dây qua sóng vô tuyến.
Trong vải năm qua, thẻ RFID đã đạt được thành công lớn trong ngành và việc sử dụng chúng trở nên phổ biến Phạm vi ứng dụng của thẻ RFID rất rộng: nhận dạng mặt hàng cho dữ liệu tồn kho, quản lý chuỗi cung ứng, điện thoại có khả nang RFID, thẻ nhựa xác thực .
Thực hiện truyền thông tin trong phạm vi hẹp, RFID sử dụng tín hiệu sóng để truyền dữ liệu Khi người sử dụng đưa thé RFID gan đầu đọc, số serial của thẻ sẽ tự động truyền đến thiết bị ghi nhận Thẻ RFID thường được sử dụng như một yếu tố thứ hai trong quá trình xác thực hai yếu tố, thường kết hợp với mật khâu dé xác định người dùng đăng nhập hệ thống một cách chính xác.
Trong thực tê, đôi khi cân kêt hợp nhiêu yêu tô xác thực đê đảm bảo mức độ an toàn mong muôn, bởi mỗi phương thức xác thực déu mang nhược điểm riêng.
Dưới đây là một sô ví dụ cụ thê:
- Xác thực bang mật khẩu thường có nhược điểm lớn nhất là người dùng thường chọn mật khẩu dễ nhớ, làm cho chúng trở nên dễ đoán và dễ bị tan công.
- Phuong pháp nhận dạng sinh học đòi hỏi phải có hạ tầng thông tin tốt, và đôi khi có thể gặp khó khăn khi triển khai.
- RFID chỉ hoạt động hiệu quả trong phạm vi gần đầu đọc chuyên dụng, giới hạn khả năng sử dụng của nó.
- Sử dụng OTP đòi hỏi cơ sở hạ tang thông tin phải được kết nối đáng tin cậy và liên tục, vì mỗi mã OTP chỉ tồn tại trong một khoảng thời gian ngắn nhất định.
Kết hợp những yếu tố này có thé giúp tăng cường tính an toàn và dam bảo độ tin cậy của quá trình xác thực Thẻ RFID dang mở ra một tương lai mới khi chúng ta ngày cảng phụ thuộc vao Internet Sự hiện diện của chúng trong cuộc sống hàng ngày đang mở ra nhiều ứng dụng tiềm năng, từ thẻ tín dụng tích hợpRFID có thé thanh toán không dây đến việc bảo vệ hộ chiếu RFID thông qua mãPIN dé ngăn chặn các cuộc tan công không mong muốn.
Giới thiệu về cơ chế xác thực một lần - - 2 s+s+s+E se SeEEeEeEezsrsss 9
Khái niệm xác thực một lần -2¿ 2+ +++2++zxzx+zzxerxezsees 9
Trong thê giới kỹ thuật sô hiện nay, người dùng phải truy cập vao nhiêu hệ thống dé thực hiện công việc hàng ngày của họ hoạt động kinh doanh Khi số lượng hệ thống tăng lên, số lượng thông tin đăng nhập cho mỗi người dùng sẽ tăng lên và do đó kha năng mắt hoặc quên chúng cũng tăng lên Đăng nhập một lần có thé được sử dụng dé giải quyết nhiều van đề liên quan đến nhiều thông tin đăng nhập cho các ứng dụng khác nhau Quyền truy cập đăng nhập một lần vào trung tâm xác thực chính cho phép người dùng truy cập vào tất cả các tài nguyên khác có san SSO giúp cải thiện năng suất của người dùng và nhà phát triển bằng cách tránh người dùng nhớ nhiều mật khâu và cũng giảm lượng thời gian người dùng dành cho việc nhập các mật khẩu khác nhau dé đăng nhập SSO cũng don giản hóa quản trị bằng cách quản lý thông tin đăng nhập duy nhất thay vì nhiều thông tin đăng nhập Nó làm cho dé dàng dé quan lý quyền của người dùng đến, thay đổi chức năng trong hoặc rời khỏi công ty, dé nhanh chóng tích hợp được thêm vào ứng dụng, ủy quyền truy cập trong các ngày lễ mà không làm tăng khối lượng công việc của bộ phận trợ giúp [3]
Cơ chế đăng nhập một lần là cơ chế giúp cho người dùng hợp pháp có thê truy nhập vào rất nhiều những dịch vụ khác nhau trên hệ thống mạng phân tán nhưng chỉ phải sử dụng một định danh duy nhất Người dùng chỉ cần đăng ký và đăng nhập duy nhất một lần vào hệ thông, khi đó trong phiên làm việc của mình họ có thê truy cập ngay lập tức vào các dịch vụ liên kết của hệ thống phân tán mà không phải đăng ký thêm định danh và thông qua quá trình đăng nhập lần nữa.
Các loại SSO QQ TS 9 1.2.3 Ưu nhược điểm của xác thực một lần . - - 5z s+x+E+zezzezscez 15
Các loại SSO khác nhau được mô tả trong hình 1.4, thuộc các loại khác nhau, dựa trên nơi chúng được triển khai (Intranet, Extranet, Internet), cách chúng được triển khai (architecture — Simple, Complex), các thông tin mà họ sử dụng (token, certificate) và giao thức mà họ sử dụng (Kerberos, SAML,OpenID)
Single SiT On intranet — Internet Where they are deployed sso ss0
: =i] Type of Credentials oken based J PKi-based — Client-side Server-side sso — credential caching credential caching eg: kerberos) Ifeg:Browser!ID ep:Pass Go : rust SSO
Hình 1.4 Các loại SSO theo từng tiêu chi
1.2.2.1 Nơi chúng được triển khai a Intranet hoặc Enterprise (ESSO) Co
Enterprise Single Sign-On (ESSO) là một giải pháp được thiệt kê đê kêt nôi và tương tác với nhiều hệ thống khác nhau trong một tô chức ESSO được thiết kế dé cung cấp Single Sign-On cho hầu hết mọi ứng dụng mà người dùng có thé cần, bao gồm cả các ứng dụng Windows, ứng dụng Java, các ứng dụng mô phỏng kết nối và trong một số trường hợp là các ứng dụng web Thông thường, Enterprise SSO được triển khai dưới dạng một ứng dụng quản lý thông tin người dùng thay mặt cho một người dùng duy nhất Nó ghi lại ID người dùng và mật khâu cho ứng dụng khi người dùng đăng nhập Khi ứng dụng được khởi chạy lần tiếp theo, giải pháp sẽ tự động nhập thông tin đăng nhập thay mặt cho người dùng Nó cũng có thé được lập trình dé xử lý các thay đổi mật khâu, vi dụ như thay đôi mật khâu do hết hạn Đối với Enterprise SSO, một tệp tin thực thi được cài đặt trên máy tính để bàn của người dùng và các hồ sơ được tao dé nhận biết màn hình đăng nhập/mật khẩu thay đôi dé phan tử có thé phản ứng với chúng. b Extranet hoặc Multi-domain SSO ;
Extranet hoặc Multi-domain Single Sign-On (SSO) là một hệ thông xác thực được thiết kế để cung cấp khả năng đăng nhập một lần cho người dùng trên nhiều hệ thống hoặc miền khác nhau Điều này đặc biệt hữu ích trong môi trường doanh nghiệp có nhiều hệ thống và miền, nơi người dùng cần truy cập vào các tài nguyên và ứng dụng trên nhiều nền tảng khác nhau mà không cần phải nhập thông tin đăng nhập mỗi lần. Ưu điểm lớn của Extranet hoặc Multi-domain SSO là nó mang lại trải nghiệm người dùng thuận lợi và giảm bớt gánh nặng về việc quản lý mật khẩu
10 đối với người quản trị hệ thống Người dùng không cần phải nhớ nhiều mật khẩu cho từng hệ thống và có thé dé dang di chuyên giữa các ứng dụng mà không gặp khó khăn về xác thực. c Internet hoặc Web SSO Ộ Web SSO tập trung vào các ứng dụng dựa trên web Một máy chủ ủy quyên được sử dụng để xác định ai có thê truy cập dịch vụ nào Một IdP sẽ xác thực người dùng và kiểm tra các quy tắc truy cập trong máy chủ ủy quyền để xem liệu yêu cầu có nên được chuyển đến máy chủ web không Điều này cung cấp một cách tiếp cận tích hợp hơn, vì kiểm soát truy cập được thêm vào ngoài việc sử dụng SSO Loại SSO này hữu ích khi nhiều ứng dụng web được liên quan. Trong Web SSO, người dùng chỉ có một mật khẩu dé xác thực Sau khi người dùng có một phiên với sản phẩm Web SSO, họ có thể truy cập nhiều trang web mà không cần xác thực lại
1.2.2.2 Cách được triển khai a Simple SSO architecture ;
Simple SSO su dung cơ quan xác thực duy nhat, bộ thông tin đăng nhập duy nhất cho mỗi người dùng Kiến trúc này có thể dé dàng thực hiện trong môi trường mạng LAN va mạng nội bộ đồng nhất.
Kiến trúc Simple Single Sign-On (SSO) là một cơ chế xác thực linh hoạt và thuận tiện Trong hệ thống này, người dùng chỉ cần xác thực một lần với một cơ chế xác thực, thường là thông qua việc nhập một tên người dùng và mật khâu duy nhất Sau khi xác thực thành công, người dùng có khả năng sử dụng nhiều danh tính khác nhau dé kết nối với các Nhà Cung Cấp Dich vụ (SP) khác nhau mà ho có quyên truy cập Mỗi SP duy nhất được quản lý bằng cách sử dụng một cơ sở đữ liệu riêng, nơi lưu trữ thông tin đăng nhập của người dùng Các cơ sở dữ liệu này có thể được bảo vệ bằng cách tích hợp các cơ chế xác thực nâng cao như sinh trắc học hoặc token, đảm bảo mức độ an toàn cao Authentication Service Provider (ASP) chịu trách nhiệm làm nhà cung cấp dịch vụ xác thực, tạo ra một giao tiếp tin cậy giữa người dùng và các SP Trong mô hình này, người dùng có khả năng duy trì nhiều danh tính dé linh hoạt truy cập các dich vụ khác nhau, mỗi danh tính có thé yêu cầu một cơ chế xác thực khác nhau tùy thuộc vào yêu cầu cụ thê của SP.
Tóm lại, Simple SSO mang lại trải nghiệm xác thực thuận tiện cho người dùng, giảm bớt gánh nặng của việc phải xác thực nhiều lần khi di chuyên giữa các dịch vụ trong hệ thống b Complex SSO architecture
Complex SSO sử dụng nhiều cơ quan xác thực với một hoặc nhiều bộ thông tin đăng nhập cho mỗi người dùng.
Kiến trúc Complex Single Sign-On (SSO) chia thành hai hệ thống chính: Centralized SSO va Federated SSO dé đáp ứng môi trường phức tạp với nhiều miễn hoặc công ty.
+ Centralized SSO: Trong hệ thống SSO tập trung, có một cơ sở dit liệu tập trung và bên thứ ba trung ương quản lý giao tiếp tin cậy trong một miễn cụ thể Người dùng sử dụng cùng một danh tính cho tất cả các hệ thống, và quá trình xác thực sử dụng mật mã để bảo vệ tính toàn vẹn.
Cơ chế giả mạo (ASP) và Nhà Cung Cấp Dịch Vụ (SP) tương tác với nhau qua các khóa bí mật được truyền qua ASP.
+ Federated SSO: Trong hệ thống SSO liên kết, người dùng có danh tính riêng và được các hệ thống khác nhau tin tưởng Điều này quan trọng khi người dùng sử dụng dịch vụ từ các miền hoặc công ty khác nhau. Mỗi SP trong các miền khác nhau cần tin tưởng lẫn nhau và biết về IdP của mình Sử dụng giao thức như SAML, Shibboleth và Kerberos, cùng với các tiêu chuẩn bảo mật, dé chia sẻ danh tính người dùng an toàn qua các miền, dịch vụ và ứng dụng khác nhau. Điều này tạo ra một môi trường an toàn và thân thiện, cho phép người dùng sử dụng các dịch vụ mà không cần phải xác thực lại mỗi khi chuyển đổi giữa các hệ thống khác nhau.
1.2.2.3 Thông tin đăng nhập được sử dụng
Hệ thong SSO được chia thành hai kiến trúc cơ ban: Simple SSO và Complex SSO Simple SSO chỉ có một cơ quan xác thực duy nhất có sẵn, vì vậy cũng chỉ có một bộ thông tin xác thực cho mỗi người dùng Theo các nhà cung cấp hệ điều hành như Novell và Microsoft, kiến trúc này có thé dé dang triển khai trong môi trường LAN và intranet Complex SSO có nhiều nền tang và nhiều thông tin xác thực được quản lý bởi nhiều cơ quan xác thực khác nhau cho nên phức tạp hơn và khó thực hiện hơn Complex SSO có thể được phân biệt thành: Complex SSO xử lý một bộ thông tin xác thực và Complex SSO xử lý nhiều bộ thông tin xác thực khác nhau Và trong mỗi loại lại có những cách xử lý khác nhau s* Complex SSO xử lý một bộ thông tin xác thực a Hệ thống SSO dựa trên Token : ;
Hệ thong SSO dựa trên Token hoạt động theo co chê sau: khi người dùng gửi thông tin xác thực đến hệ thống xác thực, hệ thống sẽ kiểm tra thông tin xác
12 thực trong cơ sở đữ liệu của mình Nếu thông tin xác thực khớp, người dùng sẽ nhận được một Token Token này được lưu trữ tạm thời trên máy tính của người dùng và sẽ được chuyền đến hệ thống xác thực thứ hai khi người dùng cần truy cập máy chủ ứng dụng do hệ thống xác thực hai quản lý Thành công của quá trình nay phụ thuộc vao sự tin tưởng giữa các hệ thong xác thực với nhau. b Hệ thống SSO dựa trên Token trong môi trường HTTP :
Hệ thống SSO dựa trên Token có thể được triển khai bằng cách sử dụng cookie trong môi trường HTTP Cookie là một tập hợp thông tin được máy chu web cung cấp cho trình duyệt web và được lưu trữ trong máy khách Cookie được sử dụng dé xác thực có thé được mã hóa dé giữ bí mật Sau đó, máy chủ có thé truy xuất cookie và cung cấp dịch vụ tùy chỉnh cho khách hang Qua đó, hệ thống Kerberos cung cấp một cơ sở dé xây dựng SSO an toàn trong môi trường mạng, nhưng đòi hỏi cấu hình và cơ sở hạ tầng ở phía máy khách Trong môi trường hỗ trợ HTTP, việc sử dụng cookie giúp xây dựng hệ thống SSO mà không cần cài đặt hoặc cau hình bé sung Sự khác biệt quan trọng giữa hệ thống Kerberos và hệ thông SSO sử dung Cookies là hệ thống Kerberos sử dụng Cuộc gọi thủ tục từ xa để truyền vé xác thực, trong khi hệ thống SSO hỗ trợ Cookies sử dụng cookie như một token. c Hệ thống SSO dựa trên PKI: -
Trong SSO dựa trên PKI, máy chủ/tài nguyên và người dùng xác thực lân nhau bằng cách sử dụng cặp khóa tương ứng của họ Người dùng có thể xác thực máy chủ bằng cách yêu cầu máy chủ giải mã bất kỳ tin nhắn nào họ gửi được mã hóa băng khóa chung của máy chủ Theo cách tương tự, máy chủ có thé xác thực người dùng bang cách thách thức anh ta giải mã tin nhắn họ gửi được mã hóa bằng khóa chung của người dùng Vì chủ sở hữu thực sự của khóa riêng chỉ có thé giải mã nên việc xác thực lẫn nhau tức là máy chủ xác thực người dùng và ngược lại xảy ra Cơ quan chứng nhận của người dùng và máy chủ có thể khác nhau và nếu chúng khác nhau thì phải có sự tin cậy giữa các cơ quan chứng nhận.
* Complex SSO xử lý nhiều bộ thông tin xác thực d Đồng bộ hóa thông tin xác thực (Credential Synchronization)
Kết chương 5-5: St St E12 1211211121121 11 2111111111111 xe 16 CHƯƠNG 2: CAC GIAO THUC VÀ GIẢI PHÁP XÁC THUC MOT LAN
Thông qua nội dung chương 1, đô án dé cap đên những kiên thức co bản vê cơ chế xác thực và các kỹ thuật xác thực sử dụng trong đăng nhập; giới thiệu khái quát về cơ chế đăng nhập một lần, phân loại SSO theo từng khía cạnh đánh giá và những ưu khuyết điểm của cơ chế này trong hệ thống.
CHƯƠNG 2: CÁC GIAO THỨC VÀ GIẢI PHÁP XÁC THỰC MỘT LÀN
Các giao thức xác thực một
Giao thức KerbeTOs - c1 333313191 vn vn ờ 23 “0 tr 290 6 5
2.1.2.1 Giới thiệu về giao thức Kerberos
Giao thức chứng thực mạng Kerberos được phát triển trong dự án Athena của MIT và có tên lấy cảm hứng từ con chó ba dau Cerberus trong thần thoại Hy
Lạp, đóng vai trò canh gác công địa ngục Kerberos đảm bảo tính toàn vẹn và tính bí mật thông tin truyền đi bằng cách sử dụng mã hóa bí mật như DES, triple
Khác với việc xây dựng các giao thức chứng thực phức tạp cho mỗi máy chủ,
Kerberos hoạt động dựa trên một máy chủ chứng thực tập trung, được gọi là
KDC (Key Distribution Center) KDC là trung tâm phân phối khóa, có nhiệm vụ cung cấp vé (ticket) để chứng thực người dùng và bảo mật truyền thông băng khóa phiên trong vé KDC bao gồm ba thành phan chính:
- May chủ chứng thực AS (Authentication Server): Xác minh danh tính của người dùng và cung cấp vé khởi đầu.
- Máy chủ cấp phát vé (Ticket Granting Server): Cung cấp vé phục vụ cho việc truy cập các dịch vụ khác sau khi người dùng đã được chứng thực.
- Cơ sở dit liệu (Database): Lưu trữ thông tin về người dùng và khóa mật khẩu dé thực hiện quá trình chứng thực.
Bước 1: Authentication Server Request (AS REQ)
May client yêu cầu KDC cu thể ở đây là máy chủ cấp phát vé( Authentication Server) cấp cho một TGT( Ticket Granting Ticket) Yêu cầu này sẽ gồm có Principalcien , Principalservice , IP_list , Lifetime, trừ Principal cient thì các thành phần còn lại sẽ được mã hóa bang mat khau cua Client.
AS_REQ = {Principalciien} Kuser (PrincipalService , IP_list , Lifetime)
- Principalcien là principal liên kết tới người dùng đang được xác thực (vi du: nhan@EXAMPLE.COM)
- Prineipalseue là principal liên kết tới dich vụ Trong trường hợp yêu cầu
TGT, Principalservice sẽ là "krbtgt/REALM@REALM".
- IP list la danh sách địa chi IP của các máy chủ có thé sử dung vé.
- Lifetime là thời han tối da cho việc phát vé, tức là thời gian sống của TGT.
Bước 2: Authentication Server Reply (AS_ REP)
Khi Authentication Server nhận được yêu cau, sẽ sử dung Principalcien đê truy xuât mật khâu từ cơ sở dữ liệu và giải mã phân được mã hóa.
Authentication Server sẽ kiểm tra xem Principalse.: có trong Database không.
Nêu tôn tại thì Authentication Server sẽ làm các bước sau:
Tạo một khóa phiên ngẫu nhiên, được sử dụng làm bí mật giữa máy khách và máy chủ cấp phát vé, được gọi là SKrs.
Tạo Ticket Granting Ticket (TGT) bang cách chứa principal của người gửi yêu cầu, principal của dich vụ (thường là "krbtg/REALM@REALM"), danh sách địa chỉ IP (được sao chép từ gói tin AS_REQ), ngày giờ cua
KDC dưới dạng nhãn thời gian, thời gian sống và cuối cùng là khóa phiên
Tạo và gửi gói tin trả lời (AS_REP), bao gồm vé được tạo ra ở bước trước (được mã hóa bằng khóa bí mật cua dich vu Kies), principal của dich vụ, nhãn thời gian, thời gian sống va khóa phiên Tat cả được mã hóa bằng khóa bí mật của người gửi yêu cầu (Kuser).
AS_REP = {PrinciIpals.e., Timestamp, Lifetime, SKros} Kuser {TGT} Kros
Bước 3: Ticket Granting Server Request (TGS REQ)
Sau khi nhận được TGT, người dùng gửi yêu cầu TGS REQ đến máy chủ cấp phát vé(Ticket Granting Server) dé yêu cầu vé dich vu mà họ cần Quá trình tạo gói tin TGS_ REQ như sau:
Tao một authenticator với principaciien, nhãn thời gian của máy khách và mã hóa bằng khóa phiên TGS:
Tao gói tin yêu cầu gồm principal của dich vụ mà khách hang yêu cầu cùng nhãn thời gian ở dạng không mã hóa; Ticket Granting Ticket mã hóa băng khóa bí mật của TGS và authenticator vừa tạo:
TGS_ REQ = (Principalsevice, Lifetime , Authenticator) { TT }Kros Bước 4: Ticket Granting Server Reply (TGS_ REP)
Khi nhận được gói tin TGS REQ, bước đầu tiên, máy chủ cấp phát vé sẽ kiểm tra xem principal của dịch vụ mà người dung yêu cau (PrincipalService) có trong cơ sở dữ liệu của trung tâm phân phối khóa hay không Nếu có, nó dùng khóa của krbtgt/REAM@REALM để mở TGT và trích xuất ra khóa phiên (SKTGS) Dé có thé cấp phát vé dịch vụ, máy chủ TGS sẽ kiểm tra các điều kiện:
- PrincipalClient trong authenticator trùng với trong PrincipalClient TGT;
- Authenticator chưa hết hạn va không có trong bộ đệm phat lại;
- Nếu IP list không rỗng, địa chỉ IP nguồn của gói tin yêu cầu (TGS_REQ) phải trùng với một trong các địa chỉ IP có trong danh sách IP.
- Nếu thỏa mãn các điều kiện trên thì TGT thực sự được gửi bởi người yêu cầu dịch vụ và do đó, máy chủ TGS sẽ tạo gói tin trả lời như sau:
- Tao một khóa phiên ngẫu nhiên dùng làm khóa bi mật chia sẻ giữa may khách và dich vụ Gọi khóa ngẫu nhiên này là SK service
- Tao vé dịch vụ, trong vé gồm có principal của người dùng, danh sách địa chỉ IP, ngày và giờ (của máy chủ KDC) ở dạng nhãn thời gian, thời gian sông (là giá trị nỏ nhất giữa thời gian sống của TGT và thời gian sống của principal dich vụ) và cuối cùng là khóa phiên SKsewice Gọi vé này là
Tservice = (Principalcien, Principalsevice, IP list, Timestamp, Lifetime,
Gửi thông điệp trả lời, bao gồm vé vừa tao, mã hóa bằng khóa bí mật của dich vụ gọi là KService; principal dịch vụ, nhãn thời gian, thời gian sống và khóa phiên mới, tất cả được mã hóa bằng khóa được trích xuất từ TGT:
TGS_REP = {Principalsevice, Timestamp, Lifetime, SKservice} SKras {Tservice}
Khi nhận được trả lời, may khách sé dùng khóa phiên SKTGS trong bộ đệm ủy nhiệm dé giải mã phan thông điệp có chứa khóa phiên mới dé lay được SKService và lưu nó lại cùng với vé dịch vụ TService, tuy nhiên vẫn ở dạng mã hóa.
Bước 5: Application Server Request (AP_REQ)
Khi có đủ giấy ủy nhiệm (vé và khóa phiên có liên quan) dé truy cập dich vu, máy khách yêu cầu máy chủ ứng dụng cấp quyền truy cập tài nguyên bằng cách gửi gói tin AP REQ Khác với những gói tin trao đổi với máy chủ KDC,
AP REQ không theo một chuẩn nào mà tùy thuộc vào từng ứng dụng Có thé xem xét kịch bản sau:
Giao thức OAAuth - - S2 01112223 111111 1H21 1x4 32
2.1.4.1 Giới thiệu về giao thức OAuth
OAuth là một giao thức mở đê xác thực OAuth cung cap cho máy khách phương pháp truy cập tài nguyên của máy chủ Đồng thời OAuth cho phép người sử dụng xác thực việc sử dụng tài nguyên của bên thứ ba mà không làm lộ các thông tin bí mật như tên người sử dụng, mật khâu OAuth cơ bản sử dụng
“access token” cấp cho máy khách bởi một máy chủ ủy quyên, với sự chấp thuận của chủ sở hữu nguôn tài nguyên Các máy khách sau đó sử dung “access token” dé truy cập các nguồn tài nguyên được bảo vệ trên máy chủ tài nguyên.
Ví dụ, một ứng dụng trò chơi có thể truy cập vào dữ liệu người sử dụng trong các ứng dụng Facebook, hoặc một ứng dụng dựa trên địa điểm có thé truy cập dir liệu người sử dụng của ứng dung Foursquare
SS | uf, Access user data | Ị from Facebook
Hình 2.17 Ví dụ về cách OAuth 2.0 được sử dụng dé chia sẻ dữ liệu
OAuth được phát triển từ 11/2006 Do sự tiện lợi, OAuth đang được phát triển lên các phiên bản cao hơn Hiện nay, OAuth 2.0 thay thé cho OAuth 1.0. OAuth 1.0 phức tạp hơn, nó yêu cầu các giấy chứng nhận liên quan OAuth 2.0 đơn giản hơn, nó không đòi hỏi tất cả giấy chứng nhận mà chỉ cần SSL/TLS [7
OAuth được ứng dụng nhiều trong việc xác thực trên Internet, truy cập một cửa trong các hệ thống phức tạp và người dùng không phải lo lắng về thông tin truy cập của họ đang bị tổn hại Các chức năng trong OAuth cho phép: Tiếp cận được đồ thị xã hội của người dùng (bạn bè của họ trên Facebook, Twitter hoặc Google Contacts ) Chia sẻ thông tin về các hoạt động của người dùng trên trang web của nhà phát triển ứng dụng, bằng cách gửi bài đến tường trên
Facebook hoặc dòng thời gian của Twitter Truy cập vào tải khoản Google
Docs hay Dropbox của người dùng dé lưu trữ dữ liệu trong hệ thong tập tin trực tuyến của họ Tích hợp các ứng dụng thương mại với nhau Vì thế, OAuth có thể được sử dụng hoặc dé tạo ra ứng dụng đọc dữ liệu người dùng từ một ứng dụng khác (ví dụ như các trò chơi trong sơ dé trên), hoặc ứng dụng cho phép các ứng dụng khác truy cập vào dữ liệu người dùng của nó (ví dụ như Facebook trong ví dụ trên)
OAuth được sử dụng để một ứng dụng máy khách có thể truy cập vào các nguồn tài nguyên được lưu trữ trên máy chủ tài nguyên Dé hiểu hơn về cách hoạt động cua OAuth, ta làm rõ một số khái niệm:
- Resource Owner: là người hoặc ứng dụng sở hữu nguồn tài nguyên được bảo vệ.
- OAuth Client: là ứng dụng có yêu cầu truy cập vào các nguồn tài nguyên được bảo vệ.
- Resource Server: là may chủ lưu trữ các nguồn tài nguyên được bảo vệ mà OAuth Client muốn truy cập.
- Authorization Server: là máy chủ cho phép OAuth Client truy cập tải nguyên cua chủ sở hữu tài nguyên Resource Server va Authorization
Server có thé là cùng một máy chủ.
- Client ID va Client secret: Client ID là một định danh duy nhất cho một
OAuth Client OAuth Client sử dụng Client ID (client ID) và Client secret (client_secret) để cung cấp danh tính.
- Access Token: là một định danh để truy cập vào các nguồn tài nguyên được bảo vệ của chủ sở hữu tài nguyên OAuth Client có thể sử dụng các Access Token trước khi nó hết hạn.
- Refresh Token: là một định danh để có được Access Token Authorization
Server tạo ra Refresh Token cùng với Access Token OAuth Client có thể sử dung Refresh Token để yêu cầu một Access Token mới từ Authorization Server khi Access Token hiện tại hết hạn hoặc yêu cầu một
Access Token với phạm vi trùng hoặc hẹp hơn Không giống Access Token, Refresh Token không được gửi đến Resource Server. s* 3-legged OAuth:
3-legged OAuth là một mô hình truyền thống với sự tương tác của
Resource Owner Trong trường hợp này, Resource Owner muôn cap cho một
Client truy cập vào một Server mà không chia sẻ thông tin Hình 2.2 cho thấy quá trình hoạt động của 3- legged OAuth.
Hoạt động của 3-legged OAuth như sau:
Resource Owner, bat đầu một yêu cầu cho OAuth Client.
OAuth Client chuyên hướng Resource Owner đến Authorization Server
Resource Owner xac nhan va cho phép tuy chon voi Authorization Server. Authorization Server đưa ra một form dé Resource Owner cap quyên truy cap.
Resource Owner đệ trình form cho phép hoặc từ chối truy cập.
Dựa vào những phản hồi của Resource Owner, có hai trường hợp xảy ra:
- Nếu Resource Owner cho phép truy cập, Authorization Server sẽ chuyền hướng OAuth Client với một mã ủy quyền
- Nếu Resource Owner từ chối truy cập, OAuth Client vẫn được chuyên hướng nhưng không được cấp mã ủy quyền.
OAuth Client gửi các thông tin sau cho Authorization Server:
- Authorization grant code (mã ủy quyền)
- Client secret hoặc Client certificate
Nếu được xác nhận, Authorization Server gửi cho OAuth Client một
Access Token và một Refresh Token tùy ý.
Hình 2.18 Hoạt động cua 3-legged OAuth
9 OAuth Client gửi Access Token tới Resource Server để yêu cầu nguồn tài nguyên được bảo vệ.
10.Nếu Access Token hợp lệ với tài nguyên được yêu cầu thì OAuth Client có thé truy cập nguồn tài nguyên được bảo vệ đó. s* 2-legged OAuth:
2-legged OAuth hoạt động như một Client-Server điển hình, mà không cần sự tham gia của Resource Owner Ví du, một ứng dụng Client Facebook truy cập vào tài khoản Facebook.
2-legged OAuth hoạt động đơn giản như sau:
1 OAuth Client bắt đầu yéu cầu với một Authorization Server và nhận một
2 OAuth Client sử dụng Access Token để truy cập tài nguyên được bảo vệ trên Resource Server.
Hình 2.19 Hoạt động cua 2-legged OAuth
- Bảo mật tích hợp: OAuth cung cấp mô hình ủy quyên, giup giam rủi ro cho chủ sở hữu tai nguyên băng cách không chia sẻ thông tin đăng nhập mà vẫn cho phép truy cập tài nguyên.
- Thuận tiện cho người dùng: Người dùng có khả năng quản lý quyền truy cập ứng dụng mà không cần chia sẻ mật khâu của họ, tăng tính an toàn.
- Kha năng đa nền tảng: OAuth có thé được triển khai và sử dụng trên nhiều nền tảng và dịch vụ khác nhau, làm cho nó trở thành một tiêu chuẩn phô biến.
- Phu hợp cho ứng dụng di động va Web: Giao thức này thích hợp cho ca ứng dụng di động và web, cho phép người dùng truy cập tải nguyên từ nhiều thiết bị.
- Quản lý quyền truy cập tinh tế: OAuth cung cấp cơ chế phân quyền linh hoạt, cho phép quyết định chỉ tiết về quyền truy cập của ứng dụng khách. s* Nhược điểm:
Giao thức SAML ĂĂ SH vn ven, 36
2.1.5.1 Giới thiệu về giao thức SAML
Security Assertion Markup Language (SAML) là một giao thức cung cấp xác thực và ủy quyên Bằng cách sử dụng SAML, một dịch vụ có thé liên lạc với một IdP dé xác thực người dùng muốn truy cập nội dung an toàn Phiên ban 1.1 của đặc tả SAML hỗ trợ duy nhất đăng nhập một lần (SSO) qua web Ké từ đó, SAML đã phát trién thành một khung làm việc mở rộng hơn.
SAML 2.0 hiện là tiêu chuẩn hàng đầu cho xác thực giữa các miền Nó được hỗ trợ bởi phần mềm sẵn có và các nhà cung cấp dịch vụ lớn như Google, Salesforce, WorkDay, Box, Amazon và nhiều người khác SAML là một tiêu chuẩn cho các mạng doanh nghiệp, chính phủ và giáo dục trên khắp thế giới. SAML hỗ trợ các bindings, là cách mà Identity Provider (IdP) chuyên hướng người dùng trở lại Service Provider (SP) Có hai loại bindings quan trọng: HTTP
Redirect và HTTP POST binding HTTP Redirect sẽ sử dụng một HTTP
Redirect dé gửi người dùng trở lại SP Binding này chủ yếu hữu ich cho các thông điệp SAML ngắn Những thông điệp dài hơn (ví dụ: chứa các SAML claim đã được ký) nên được truyền bằng HTTP POST Các token trong SAML có định dạng XML, khác với các JSON web token được hỗ trợ bởi OAuth2 và
Khác với OpenID Connect va OAuth2, SAML chỉ có một luồng
Hình 2.20 Mô hình hoạt động cua SAML
Quá trình bắt đầu khi một khách hàng liên lạc với dịch vụ
1 Đề truy cập dịch vụ, khách hàng gửi một thông điệp đến IdP và AS dé yêu cầu quyền truy cập ứng dụng Dich vụ sẽ gọi đến máy chủ IdP/AS xem khách hàng đã được xác thực chưa.
Máy chủ IdP/AS yêu cầu khách hàng cung cấp thông tin đăng nhập
Khách hàng trả lại thông tin đăng nhập cho máy chủ IdP/AS, máy chủ sau đó xác minh chúng.
Nếu thông tin đăng nhập hợp lệ, IdP liên hệ với AS và yêu cầu dữ liệu uy quyén.
AS tra lai ma thong bao truy cap cho IdP
IdP sau đó thông bao cho dịch vu rằng người dùng đã được xác thực va gửi một mã thông báo truy cập
Khách hàng đăng nhập dịch vụ và cấp quyền truy cập vào nguồn tài nguyên được yêu câu.
SAML mang lại nhiều lợi ích đối với xác thực ứng dụng web an toàn Tuy nhiên, đê đảm bảo sự an toàn và hiệu quả của hệ thông xác thực SAML, cân phải xem xét và giải quyêt cân thận các nhược điêm liên quan đên bảo mật và khả năng tân công tiêm ân. Ưu điêm:
Kiểm soát bảo mật cao hơn: SAML cung cấp một cấp độ bảo mật cao hon khi hoạt động như một điểm xác thực duy nhất, giảm thiểu nguy cơ việc xâm phạm danh tính.
Trải nghiệm người dùng tốt hơn với SSO (Single Sign-On): SAML cho phép người dùng đăng nhập một lần và tự động giữ đăng nhập khi truy cập các ứng dụng hoặc dịch vụ khác.
Liên kết chặt chẽ giữa các hệ thống: không đòi hỏi thông tin người dùng phải được giữ và đồng bộ hóa giữa nhiều thư mục Điều này giúp giảm thiểu sự liên kết lỏng lẻo giữa các thành phần của hệ thống hoặc mạng.
Lưu trữ mật khâu: Mật khẩu ở các Identity Provider (IdP): Nếu mật khâu của người dùng được lưu trữ tại IdP, điều này có thể tạo ra một điểm yếu nếu IdP bị tan công, vì kẻ tan công có thé có quyền truy cập vao nhiều tài khoản người dùng thông qua SSO.
SSO khởi tạo từ IdP: Nguy cơ Man-in-the-Middle (MitM): Quá trình SSO khởi tao từ IdP có thé làm tăng nguy cơ bị tan công MitM, nơi kẻ tan công có thể chặn hoặc sửa đổi thông tin truyền tải giữa người dùng và IdP.
Sự phụ thuộc vào IdP: Ảnh hưởng khi IdP không khả dụng: Nếu IdP gặp sự cố hoặc không khả dụng, người dùng không thể truy cập các dịch vụ yêu cầu xác thực từ IdP.
Quản lý phiên và Đăng xuất (Single Logout): Khả năng xử lý Single Logout không đồng bộ: Quá trình đăng xuất từ một ứng dụng có thể không đồng bộ với các ứng dụng khác, tạo ra nguy co rui ro nếu một phiên đăng nhập vẫn được giữ nguyên ở một số ứng dụng sau khi người dùng đã đăng xuất từ một ứng dụng khác.
Quản lý Token: Nguy cơ đánh cắp Token: Nếu SAML token không được bảo vệ chặt chẽ, có khả năng bị đánh cắp và sử dụng dé giả mạo người dùng.
Giao thức OpenID Connect - ¿+ +s +3 *+*£‡++sevxseeeexseses 38 2.1.7 So sánh các giao thức xác thực một lẦn 5 cc St tr Erkskrrerrrxses 41
2.1.6.1 Giới thiệu về giao thức OpenID Connect
OpenID là một giao thức xác thực, cho phép người dùng sử dụng một tài khoản đê đăng nhập vào nhiêu trang web, mà không cân phải tạo mật khâu mới.
Với OpenID, người dùng có thể kiểm soát lượng thông tin được chia sẻ với các trang web mà họ truy cập Mật khẩu của người dùng được đưa cho nhà cung cấp danh tính, và nhà cung câp này sau đó sẽ xác nhận danh tính của người dùng đên
38 các trang web mà họ truy cập Khác với nhà cung cấp danh tính, không có trang web nào có thé nhìn thay mật khâu của họ, vì vậy, không cần phải lo lắng về một trang web vô đạo đức hoặc không an toàn ảnh hưởng đến danh tính của người dùng.
OpenID được tạo ra vào năm 2005, bởi một cộng đồng mã nguồn mở, cố gắng giải quyết vấn đề không dễ giải quyết bằng công nghệ nhận dạng hiện có lúc bấy giờ OpenID không thuộc sở hữu của bất kỳ ai Hiện nay, ai cũng có thể sử dụng một OpenID hoặc trở thành một nhà cung cấp OpenID miễn phí mà không cần phải đăng kí hoặc được sự chấp thuận của bất kỳ tô chức nào Vào tháng 2 năm 2014, thế hệ thứ ba của công nghệ OpenID là OpenID Connect ra đời Nó là lớp xác thực đơn giản phần đầu của giao thức OAuth 2.0 OpenID Connect thực hiện nhiều nhiệm vụ giống với OpenID 2.0 nhưng thân thiện hơn.
Cơ chế tùy chọn ký và mã hóa mạnh mẽ được định nghĩa bởi OpenID Connect. Không giống như OpenID 2.0, OpenID Connect tích hợp khả năng OAuth 2.0 với giao thức riêng của mình và không cần phần mở rộng [9]
2.1.6.2 Hoạt động cua OpenID Connect Đề hiểu về cách hoạt động cua OpenID, ta làm rõ một số khái niệm:
- Relying Party (RP) hay còn gọi là "Consumer": là một trang web hoặc ứng dụng mà muốn xác nhận danh tính người dùng.
- Identity Provider (IdP) còn gọi là OpenID Server: Là một hệ thống tạo, duy trì và quan lý các thông tin nhận dang, là một dịch vụ chuyên về đăng ký OpenID URL hoặc XRI OpenID cho phép người dùng giao tiếp với
RP Giao tiếp này được thực hiện thông qua việc trao đổi thông tin nhận dạng hoặc OpenID (là URL hoặc XRI được lựa chọn bởi người dùng để đặt tên cho danh tính của họ) IdP cung cấp xác thực OpenID dé các ứng dụng khác có thể nhận dạng Việc trao đôi được kích hoạt bởi một User- agent, đó là chương trình (chăng hạn như một trình duyệt) được sử dụng bởi người dùng dé giao tiếp với RP và IdP Ví dụ, nếu một trang web cho phép đăng nhập thông qua Facebook, Google chính là các OpenID Server.
Giả sử răng người dùng chưa đăng nhập vào OpenID Server OpenID hoạt động như sau:
1 Người dùng nhận form đăng nhập OpenID từ Consumer.
2 Người dùng phản hồi băng URL đại diện cho OpenID của họ.
3 Consumer chuyền đổi OpenID URL thành dạng chuẩn và sử dụng dé yêu cầu một tài liệu từ Identity Server.
4 Identity Server trả về tài liệu HTML được đặt tên bởi OpenID URL.
5 Consumer kiểm tra tiêu đề tài liệu HTML với thẻ , thuộc tỉnh rel thiết lập openid server và tùy chọn openid.delegate Consumer sử dụng các giá trị trong các thẻ này để xây dựng một URL với chế độ checkid setup cho Identity Server và chuyển hướng User Agent. Chekid setup URL mã hóa, trong đó, một URL dé quay trở lại trong trường hợp thành công và một URL để trở lại trong trường hợp thất bại hoặc hủy bỏ yêu cầu.
6 OpenID Server trả về một màn hình đăng nhập.
7 Người dùng nhập ID va password đăng nhập và gửi cho OpenID Server.
8 OpenID Server sẽ trả về một form ủy thác tài người dùng hỏi họ có tin tưởng vào Consumer (xác định bởi URL) với danh tính của họ hay không.
9 Người dùng gửi phản hồi tới OpenID Server.
10 Người dùng sẽ được chuyên hướng tới một trong hai URL thành công hoặc URL thất bại ở bước 5 tùy thuộc vào phản hồi của người dùng.
11 Consumer trả về trang thích hợp cho người dùng tùy thuộc vào hoạt động mã hóa trong các URL chỉ ra ở bước 10. si User Agent
Hình 2.21 Cách ma OpenID hoạt động.
Nếu người dùng đã đăng nhập vào OpenID Server thì bước 6 và 7 là không cần thiết.
Tích hợp linh hoạt: Giao thức OpenID Connect thể hiện tính linh hoạt cao trong việc tích hợp với đa dạng loại ứng dụng, bao gồm cả ứng dụng web và di động Điều này giúp tối ưu hóa quá trình triển khai và sử dụng cho nhiều kịch bản ứng dụng khác nhau.
Xác thực an toàn: OpenID Connect sử dụng giao thức OAuth 2.0 để cung cấp token truy cập an toàn, đồng thời thêm lớp xác thực người dùng Điều này tạo nền tảng cho việc xây dựng các hệ thống an toàn, đáp ứng yêu cầu bảo mật cao trong quá trình xác nhận danh tính người dùng. Đăng nhập một lần (SSO): Một trong những điểm mạnh lớn của OpenID Connect là khả năng hỗ trợ đăng nhập một lần (SSO) Điều này giúp cải thiện trải nghiệm người dùng bằng cách cho phép họ truy cập nhiều ứng dụng mà không cần phải nhập lại thông tin đăng nhập.
Hỗ trợ từ cộng đồng lớn: OpenID Connect được hỗ trợ và phát triển bởi một cộng đồng lớn của các chuyên gia về bảo mật và phát triển phần mềm Sự tích hợp chặt chẽ với cộng đồng này đồng nghĩa với việc có sẵn nhiều tài nguyên, cập nhật và hỗ trợ khi cần thiết. s* Nhược điểm :
Khó tiếp cận đối với đội triển khai công nghệ : Việc hiểu rõ và triển khai OpenID Connect có thé đôi khi là một thách thức đối với các nhà phát triển mới, đặc biệt là khi phải làm quen với các khái niệm của OAuth 2.0. Yêu cầu hiểu biết sâu sắc: Đề tận dụng hết các tính năng và lợi ích của OpenID Connect, các nhà phát triển cần có hiểu biết sâu sắc về giao thức này và cách nó tương tác với các yêu tố khác trong hệ thống.
Tương tác phức tạp: Trong một số trường hợp, quá trình xác thực và ủy quyên thông tin có thê trở nên phức tạp đối với các hệ thống lớn và phức tap, đòi hỏi sự quản ly kỹ lưỡng dé đảm bảo tính ôn định và an toàn.
2.1.7 So sánh các giao thức xác thực một lan
Bảng 2.1 cung cap nội dung so sánh các giao thức xác thực đã mô tả.
Bảng 2.1 So sánh các giao thức xác thực
Tiêu | LDAP | Kerberos CAS OAuth SAML | OpenID chi Connect
Mục | Quanly | Cung cap | Single Xacdinh | Traodéi | Xác dich | va truy dich vu Sign-On |cáchứng | thdngtin | thực xuat xác thực | (SSO) dụng có xác thực | người
4I thông tin | an toàn trong môi | thê truy giữa các | dùng và về người | và ủy trường cập tải tổ chức Ủy dùng và | quyền web nguyên quyền tài giữa các người dùng truy cập nguyên | máy tính vào ứng hệ thống dụng web
Các giải pháp xác thực một lần - 2-2 + ©x+EE+E££E+EE+ErEerxerxrkrree 42
Microsoft Azure Active Directory S©€TVIC€ cccs Sex 42
Microsoft Azure Active Directory (Azure AD) là dịch vụ quản lý danh tính điều khiển quyền truy cập trong môi trường đám mây của Microsoft Azure. Azure AD chủ yếu được sử dung dé xác thực và quản lý người dùng trong ứng dụng và dịch vụ trực tuyến của Microsoft Nó là một kho lưu trữ trực tuyến an toàn cho hồ sơ người dùng và nhóm hồ sơ người dùng Azure AD được thiết kế dé quản lý quyền truy cập vào các ứng dung và máy chủ dựa trên đám mây bằng các giao thức xác thực hiện đại như SAML 2.0, OpenID Connect, OAuth 2.0 và WS-Federation [10]
Azure AD Single Sign-On (SSO) là một tính nang Azure AD cho phép người dùng đăng nhập thuận tiện vào các ứng dung SaaS Nó cho phép mỗi người dùng truy cập vào bộ ứng dụng đầy đủ mà họ cần mà không cần phải đăng nhập vào từng ứng dụng riêng lẻ Azure AD tạo mã thông báo truy cập được lưu trữ cục bộ trên thiết bị của nhân viên Những mã thông báo này có thể được cấu hình đề hết hạn sau một khoảng thời gian nhất định Dé tăng cường bảo mật hơn nữa, Azure AD cũng có thể thực thi xác thực đa yếu tố (MFA).
Quá trình xác thực Hybrid SSO:
1 Người dùng nhập địa chỉ của ứng dụng kinh doanh vao trình duyệt của ho, trên máy trạm nối miền chạy trong văn phòng công ty.
Người dùng được chuyên hướng đến trang đăng nhập Azure AD.
Người dùng cung cấp tên người dùng trên trang đăng nhập Azure AD.
Azure AD thách thức trình duyệt cung cấp vé Kerberos.
Trình duyệt yêu cầu vé Kerberos cho tài khoản Azure AD SSO cục bộ của máy tính Tài khoản này được tạo trong Microsoft Active Directory khi
Azure AD Dàn SSO được định cấu hình.
6 Microsoft Active Directory cung cấp vé Kerberos cho tài khoản Azure AD
SSO cục bộ Nó được mã hóa bang bi mật thuộc về tai khoản cục bộ.
7 Trình duyệt phản hồi Azure AD băng vé Kerberos được mã hóa.
8 Azure AD giải mã khóa Kerberos bằng cách sử dụng khóa được chia sẻ với Azure AD khi cau hình ban đầu Azure AD Dan SSO.
9 Nếu vé hợp lệ, Azure AD sé cấp quyền truy cập va trả lại mã thông báo xác thực cho trình duyệt.
10.Giờ đây người dùng có thể đăng nhập vào ứng dụng doanh nghiệp mà không cần nhập lại mật khẩu.
Các giao thức xác thực khác nhau có thể hỗ trợ SSO trong Azure AD:
- _ Kết nỗi OAuth/OpenID chọn tùy chọn OIDC dựa trên OAuth 2.0 cho các ứng dụng hỗ trợ tùy chọn này Nền tảng nhận dạng của Microsoft cung
2.2.2 cấp thông tin chỉ tiết về các tùy chọn này trong giao thức OpenID Connect va OAuth 2.0.
SAML đây là tùy chọn tốt nhất cho các ứng dụng không hỗ trợ OIDC/OAuth Giao thức SSO SAML cung cấp thông tin chỉ tiết về tùy chọn này.
SSO dựa trên mật khâu tùy chọn này phù hợp với các ứng dụng có trang đăng nhập HTML Cách tiếp cận này, được gọi là lưu trữ mật khẩu, cho phép quản trị viên quan lý quyền truy cập và mật khâu của người dùng vào các ứng dụng web không bật danh tính liên kết Nó rất hữu ích khi quan lý một tài khoản được chia sẻ bởi nhiều người dùng (vi du: tài khoản mạng xã hội) SSO dựa trên mật khẩu cho phép các ứng dụng yêu cầu nhiều trường đăng nhập với nhiều chỉ tiết hơn tên người dùng và mật khâu tiêu chuẩn Các nhãn trường có thé tùy chỉnh.
IWA SSO sử dụng đăng nhập một lần với Xác thực Windows tích hợp cho các ứng dụng sử dụng [WA hoặc nhận biết xác nhận quyền sở hữu.
SSO dựa trên tiêu đề chọn tùy chọn này cho các ứng dụng sử dụng tiêu đề dé xác thực.
SSO được liên kết chọn phương thức SSO được liên kết cho các ứng dụng được định cau hình dé đăng nhập một lần vào nha cung cấp danh tính bên thứ ba Tùy chọn này cho phép quản trị viên định cấu hình vị trí mục tiêu khi người dùng chọn một ứng dụng trong cổng thông tin của tổ chức. Quản trị viên có thé thêm liên kết vào các ứng dụng web tùy chỉnh đã sử dụng liên kết danh tính (ví dụ: Dịch vụ liên kết Active Directory) Cũng có thé thêm liên kết đến một trang web cụ thể, liên kết này sẽ xuất hiện trên bảng truy cập của người dùng Quản trị viên có thê thêm liên kết vào các ứng dụng không yêu cầu xác thực Tùy chọn này không hỗ trợ chức năng SSO bằng thông tin xác thực của người ding Azure AD.
SSO đã bị tắt quản tri viên có thể tắt SSO nếu ứng dụng chưa sẵn sảng cho cấu hình SSO.
Okta là một dịch vụ quản lý danh tính và truy cập dựa trên đám mây, tập trung chủ yếu vào việc cung cấp giải pháp Single Sign-On (SSO) cho doanh nghiệp Okta giúp tổ chức kiểm soát và bảo vệ việc truy cập vào ứng dụng va dịch vụ trực tuyến Ứng dụng: tích hợp của Okta trong tổ chức sử dụng Đăng nhập Một lần (SSO) dé cung cấp một trải nghiệm xác thực liền mạch cho người dùng cuối Sau khi người dùng đăng nhập vào Okta, họ có thé khởi chạy bat kỳ ứng dụng tích hợp nào đã được gán cho họ dé truy cập các ứng dụng va dịch vụ bên ngoài mà không cần nhập lại thông tin đăng nhập Đối với các ứng dụng hỗ trợ SSO qua SAML, OIDC hoặc bất kỳ giao thức xác thực độc quyền nào khác,
Okta thiết lập một kết nối an toàn với trình duyệt của người dùng và sau đó xác
44 thực người dùng Với SSO, một miền trung thực hiện xác thực và sau đó chia sẻ phiên làm việc với các miên khác Cách phiên được chia sẻ có thê khác nhau giữa các giao thức SSO khác nhau, nhưng khái niệm chung là giông nhau [11]
Okta cung cấp quyền truy cập SSO đến hàng nghìn ứng dụng dựa trên đám mây thông qua Okta Integration Network (OIN) Các tích hợp trong OIN có thể sử dụng OpenID Connect (OIDC), SAML, SWA hoặc các API độc quyền để triển khai SSO Okta duy trì các giao thức SSO và các API cung cấp Okta cũng cung cấp tích hợp cho SSO đối với các ứng dụng web trên nền tảng on-premises.
Có thé tích hợp các ứng dụng on-premises bằng cách sử dụng SWA hoặc các bộ công cụ SAML Okta cũng hỗ trợ việc cung cấp và hủy cấp quyền người dùng với các ứng dụng mà công khai API cấp quyền của chúng.
Okta cung cấp tích hợp SSO với các ứng dụng đi động, cho dù chúng là ứng dụng web được tối ưu hóa cho thiết bị di động, ứng dung iOS native hoặc ứng dụng Android Người dùng có thé truy cập tích hợp ứng dụng web trong OIN sử dụng SSO từ bat kỳ thiết bị di động nào Ung dụng web di động có thé sử dụng công nghệ OIDC, SAML hoặc Okta SWA theo tiêu chuẩn ngành Ví dụ, Okta có thé tích hợp với các ứng dung native như Box Mobile bằng cách sử dụng xác thực SAML cho việc đăng ký và OAuth cho việc sử dụng liên tục.
Các giao thức xác thực được hỗ trợ trong SSO Okta:
- OpenID Connect (OIDC) là một tang xác thực tiêu chuẩn được xây dựng trên giao thức ủy quyền OAuth 2.0 Giao thức OAuth 2.0 cung cấp bảo mật thông qua các token truy cập có phạm vi, và OIDC cung cấp chức năng xác thực người dùng và đăng nhập một lần (SSO) Trong quy trình làm việc của OIDC, Okta có thê hoạt động cả như nhà cung cấp danh tính
(IdP) và như nhà cung cấp dịch vụ (SP), phụ thuộc vào trường hợp sử dụng cụ thể.Các quản trị viên có thể duyệt qua danh mục OIN và sử dụng bộ lọc dé tìm kiếm các tích hợp ứng dụng với chức năng OIDC Khi được thêm vào tổ chức và được gán cho người dùng cuối bởi một quản trị viên, tích hợp ứng dụng có khả năng OIDC sẽ xuất hiện như một biểu tượng mới trên Bảng điều khiển Người dùng Cuối cùng của Okta.
- SAML là giao thức ma hầu hết các tô chức sử dụng cho SSO và bảo mật doanh nghiệp Sự hấp dẫn chính của SAML đến từ việc giúp giảm diện tích tấn công cho các tổ chức và cải thiện trải nghiệm đăng nhập của khách hàng Khi người dùng đăng nhập vào một ứng dụng bằng SAML,
IdP gửi một khẳng định SAML đến trình duyệt của họ, sau đó chuyển đến
SP Trong nhiều trường hợp, IdP xác minh người dùng (với Xác minh Da yếu tố (MFA), ví dụ) trước khi cấp khăng định SAML Quản trị viên có thể duyệt qua danh mục OIN và sử dụng bộ lọc để tìm kiếm các tích hợp ứng dụng với chức năng SAML Khi được thêm vào tô chức và được gan cho người dùng cuối bởi quản trị viên, tích hợp ứng dụng có khả năng
SAML sẽ xuất hiện như một biểu tượng mới trên Bảng điều khiển Người dùng Cuối cùng của Okta.
- Xác thực web an toàn (SWA) là công nghệ Okta cung cấp chức năng Đăng nhập một lần (SSO) cho các ứng dụng web bên ngoài không hỗ trợ các giao thức liên kết Chúng bao gồm Ngôn ngữ đánh dấu xác nhận bảo mật (SAML), Liên kết dịch vụ web (WS-Fed) hoặc Kết nối OpenID (OIDC) Quản trị viên có thê đặt thông tin xác thực cho ứng dụng hoặc người dùng cuối có thê nhập tên người dùng va mật khâu cụ thé Okta lưu giữ thông tin xác thực của ứng dụng đó trong một kho lưu trữ an toàn, được mã hóa bằng mã hóa AES-256 mạnh Sau khi thiết lập thông tin xác thực, người dùng cuối chỉ cần xác thực bằng Okta và sau đó họ có thể SSO trực tiếp vào ứng dụng Quản trị viên có thể làm cho thông tin xác thực SWA khớp với thông tin xác thực Okta của người dùng bằng cách định cấu hình tùy chọn đăng nhập để tích hợp ứng dụng SWA đó Nếu quản trị viên không đặt thông tin xác thực thì Okta sẽ nhắc người dùng nhập tên người dùng và mật khẩu vào lần đầu tiên họ khởi chạy tích hợp ứng dụng Nếu yêu cầu đăng nhập không thành công, họ cần xác minh thông tin đăng nhập của mình cho ứng dụng bên ngoài đó và thử lại Sau khi đăng nhập, người dùng nhấp vào biểu tượng tích hợp ứng dụng trên trang tong quan của họ Okta điền tên người dùng và mật khẩu, đồng thời đăng thông tin xác thực qua SSL lên trang đăng nhập của ứng dụng một cách an toàn Ứng dụng bên ngoài sẽ tự động đăng nhập người dùng. Quản trị viên có thé duyệt danh mục OIN và đặt bộ lọc dé tìm kiếm tích hợp ứng dụng với SWA dưới dạng chức năng Khi được quản trị viên thêm vào tô chức và chỉ định cho người dùng cuối, tích hợp ứng dụng hỗ trợ SWA sẽ xuất hiện dưới dang biểu tượng mới trên Trang tổng quan của người dùng cuối.