2.6.2.1. Tổng quan dịch vụ kiểm truy nhập
Microsoft .NET Access Control Service (ACS) [25] là dịch vụ cho phép người sử
dụng dễ dàng định danh và kiểm soát truy nhập tới các ứng dụng web và dịch vụ. Nó cung cấp cơ chế chứng thực và cấp quyền người sử dụng dựa trên việc cấu hình các luật trên ứng dụng. Dịch vụ ACS tích hợp với các nhà cung cấp định danh dựa trên các tiêu chuẩn ví như tích hợp với Active Directory trong mạng doanh nghiệp và định danh với ứng dụng web như Windows Live ID, Google, Yahoo! và Facebook.
Khoa Công Nghệ Thông Tin – Đại học Công nghệ Hà Nội Trang 64
Hình số 2.20: ACS, ứng dụng và người sử dụng:
ACS theo kiến trúc claims-based (dựa theo thông tin và vai trò của người dùng) nơi mà người sử dụng nhận được các thông tin và vai trò của họ t ACS dựa trên những thông tin định danh và những thông tin của chính họ trong ứng dụng. Một cách đơn giản, ACS là một dịch vụ chuyển đổi thông tin và vai trò của người (claims- transformation) trên đám mây giúp cho người dùng giảm bớt gánh nặng trong việc xây
dựng hệ thống cấp quyền dựa theo vai trò bên trong ứng dụng của họ [25].
Thuật ngữ claims được hiểu là những thông tin mong muốn của bất kỳ người dùng hay thuộc tính ứng dụng, một dịch vụ. Ví dụ bạn có một ứng dụng, bạn mong muốn các thuộc tính như địa chỉ email, số điện thoại, mật khẩu và vai trò của người dùng sẽ là những thông tin dành cho điều khiển truy nhập [25].
Hình số 2.21: Ví dụ trường hợp đơn giản của ACS
Mô hình mẫu mô tả trong hình 39 được gọi là mô hình định danh dựa trên thông tin và và vai trò của người dùng (claims-based identity model) Bời vì có sự liên kết chặt chẽ giữa các bên Dịch vụ web (Relying Party), ACS, nhà cung cấp định danh (identity provider) và người dùng cuối (end user). Chức năng chính của ACS đó là
Khoa Công Nghệ Thông Tin – Đại học Công nghệ Hà Nội Trang 65
biến đổi các thông tin, vai trò nguời dùng thành các thông tin, vai trò của người dùng ở đầu ra.
Đầu tiên, người sử dụng phải cấu hình ACS và nhà cung cấp để tạo sự tin cậy giữa chúng (thực chất là viêc thiết lập khóa mật mã với AC, và AC dùng nó để ký vào các token mà nó phát sinh).
Sau đó, người sử dụng phải cấu hình ACS và dịch vụ web của họ. Dịch vụ web đăng ký một khóa với ACS, tiếp theo, người sử dụng phải thiết lập các luật, các luật này được ánh xạ theo các yêu cầu đầu vào tới các yêu cầu đầu của ứng dụng. Trong thực tế thì các quy tắc này sẽ được cấu hình bởi các nhà quản trị/bảo mật hệ thống.
2.6.2.2. Khái niệm và thuật ngữ.
Nhà cung cấp định danh (Identity provider): Nhà cung cấp định danh quản lý định danhvà cung cấp dịch vụ chứng thực cho ứng dụng khách. Nhà cung cấp định danh xác thực thông tin của người dùng và đưa ra những SAML(Security Assertions Markup Language) token. SAML chứa thông tin user IDs và những thuộc tính định danh khác của người dùng. Một số các nhà cung cấp định danh như : Windows Live ID, Geneva Server, Google Accounts, Yahoo ID, and Sun
Relying Party: Là một ứng dụng dựa trên những thông tin và vai trò của người sử dụng, các thông tin này được cung cấp bởi ACS. Nó được dùng để cấp phép và hủy cấp phép truy cập của người sử dụng.
Security Token (SAML token): Một SAML token là một thông báo (message) có định dạng XML, nó chứa một tập hợp chữ ký số gắn với thông tin và vai trò của người dùng.
Secure Token Service (STS): Là một hệ thống con chịu trách nhiệm để xây dựng, ký nhận, hủy bỏ, tạo mới lại và cấp phát các SAML token. Một STS có thể hỗ trợ một hay nhiều đặc tính. Nó thường được thể hiện bởi các giao thức được định nghĩa trong các đặc tả của WS- WS-Trust. Nhà cung cấp định danh và ACS đều có khả năng về STS.
Request for Security Token (RST): Sau khi client(Web Service Consumer) nhận được một SAML token t STS, thì client khởi tạo một thông báo yêu cầu (request message) bao gồm SAML token đã được cấp và nó gửi các thông báo yêu cầu cho Web service (Relying Party).
Request Security Token Response (RSTR): Đáp ứng được gửi bởi một STS tới RTS được gọi là RSTR.
Claim: Một claim chứa các thông tin cần thiết bao gồm thông tin và vai trò của người sử dụng khi đăng nhập vào ứng dụng (Relying Party). Một claim chứa thông tin bất kỳ về người sử dụng, những thông tin này phụ thuộc vào quá trình cấu hình của
Khoa Công Nghệ Thông Tin – Đại học Công nghệ Hà Nội Trang 66
nhà cung cấp định danh và ACS. Tùy theo t ng ngữ cảnh cụ thể của ACS có ba loại claim :
Claim người dùng (user claims): Khi người dùng gửi yêu cầu một SAML token cho ACS, thông tin yêu cầu sẽ chứa claim như là tên đăng nhập, mật khẩu, tên domain và những thông tin khác, các thông tin này thường được sử dụng để yêu cầu xác thực người dùng.
Đầu vào claim(input claim): Khi người sử dụng đã xác thực thành công với nhà cung cấp định danh, nhà cung cấp định danh đưa ra một SAML token. SAML token thường chứa đầu vào claim cho ACS, thông tin đầu vào của claim có thể cúa claim người dùng (user claim) và bổ sung thêm một số các thông tin của claim, các thông tin này được cung cấp bởi nhà cung cấp định danh và chúng được lưu trữ trong SAML.
Đầu ra claim (output claim): ACS kiểm tra đầu vào claim (input claim) t thẻ bảo mật (SAML token) được cung cấp bởi nhà cung cấp định danh và ánh xạ sang đầu ra claim.
Định danh liên đoàn (Identity Federation): Là một tập hợp các kỹ thuật, tiêu chuẩn, nguyên mẫu, và những định nghĩa khác nhằm để chia sẻ thông tin định danh người dùng giữa các miền(domain) với nhau. Định danh liên đoàn dễ dàng cho phép các nhà phát triển thiết lập cơ chế đăng nhập một lần (single sign-on) giữa các ứng dụng chạy trên các miền khác nhau.
Windows Identity Foundation (Geneva Framework): Windows Identity Foundation là một sản phẩm của microsoft được sử dụng để tạo các ứng dụng và dịch vụ dựa trên claim. Người sử dụng có thể xây dụng STS của mình bằng các sử dụng Windows Identity Framework nếu sản phẩm hiện nay không đáp ứng được yêu cầu ứng dụng của họ. Windows Identity Framework đơn giản hóa sự phát triển ứng với các kịch bản bảo mật của các ứng dụng trên nhiều vùng miền. Nó cung cấp nền tảng cho sự phát triển ứng dụng máy khách dựa trên nền tảng web hay WCF(Windows Communications Foundation) và hỗ trợ định danh liên đoàn trải trên miền diện rộng theo mô hình client/server.
Active Directory Federation Server (ADFS 2.0) (Geneva Server): Geneva Server là một sản phẩm của Microsoft cung cấp chức năng STS cho Active Directory và bất kỳ nhà cung cấp định danh nào. Phiên bản tiếp theo của ADFS hỗ trợ mô hình định danh theo claims-based. ADFS cho phép tạo cơ chế đăng nhập một lần (single sign-on) giữa các ứng dụng được xây dựng trước (on-premise) và ứng dụng đám mây bằng cách sử dụng mô hình định danh theo claims-based. Geneva Server thực hiện các giao thức được định nghĩa trong đặc tả WS-Trust và cung cấp khả năng tương tác với các sản phẩm khác như Sun OpenSSO và Novell Access Manager. Geneva Server
Khoa Công Nghệ Thông Tin – Đại học Công nghệ Hà Nội Trang 67
không chỉ hỗ trợ các ứng dụng máy khách được xây dựng trên nền tảng web mà còn hỗ trợ các ứng dụng phía máy khách sử dụng công nghệ WCF.
2.6.2.3. Mô hình định danh dựa trên thông tin và vai trò người dùng
Hình số 40, mô tả các các thông báo và token truyền qua lại và bốn thành phần chính trong mô hình định định danh claims-based. Trước khi bắt đầu tương tác, các điều kiện được mô tả tại bước số 0 là điều kiện bắt buộc. Các bước thực hiện được mô tả như sau :
Bước 0
Hai điều kiện tiên quyết đầu tiên cần phải thiết lập trong mô hình định danh claims-based đó là : Thứ nhất : Web service đăng ký một khóa bí mật với Access Control thông qua dịch vụ quản lý ACS. ACS sẽ ký lên tất c ả các token mà nó phát ra với khóa này. Web service có quyền sở hữu khóa này và sử dụng nó để validate c ác chữ ký trên các thẻ bài mà nó nhận được. Thứ hai: Người quản trị sẽ tạo ra một Issuer để định danh dịch vụ khách hàng và định nghĩa quy tắc ánh xạ giữa input claims và output claims dưới hình thức và các quy tắc của ACS.
Bước 1
Khi ACS, relying party, và nhà cung cấp định danh, được cấu hình, dịch vụ hoặc ứng dụng phía máy khách (Service consumer) phải sử dụng key issurer cho việc sinh token t ACS để thực hiện lời gọi dịch vụ web. ACS hỗ trợ ba loại để thể hiện token yêu cầu.
PlainText: Ứng dụng hoặc phía máy khách gửi trực tiếp issuer key tới ACS để chứng thực yêu cầu. Đây là cách đơn giản nhất để yêu cầu token t Access Control.
Signed: Ứng dụng hoặc dịch vụ phía máy khách tạo một SWT, ký nên token, và gửi token này cho ACS để chứng thực. Mặc dù phức tạp hơn, nhưng cách tiếp cận này, cho phép clien có thể gửi nhiều claim cho ACS khi yêu cầu token.
SAML: Ứngdụng hoặc dịch vụ phía máy khách ký nên SAML token do ADFS 2.0 hoặc nhà định danh cung cấp. Sau đó ứng dụng hoặc dịch vụ máy khách sẽ gửi SAML token cho ACS để tiến hành xác thực. SAML chủ yếu cho việc tích hợp với ADFS phiên bản 2.0.
Khoa Công Nghệ Thông Tin – Đại học Công nghệ Hà Nội Trang 68
Hình số 2.22: Dòng thông báo trên mô hình định danh Claims-Based
Bước 2
Dựa trên các quy tắc claim- mapping đã được cấu hình trong ACS, Tiến hành Input Claims và Output Claims bằng việc sử dụng các nguyên tắc và phát sinh token. ACS sẽ đưa ra một SWT có chứa output claims tới các dịch vụ của khách hàng. ACS tạo ra một token chứa c ác claim này và ký nó bằng khóa đã đăng ký ở bước 0. Quá trình ánh xạ giữa Input Claims và Output Claims sẽ tạo một R-STS của ACS.
Bước 3
ACS tạo ra một SWT và gửi nó cho các ứng dụng/dịch vụ máy khách. SWT chứa Ouput Claims mà web service mong đợi.
Bước 4
Ứng dụng phía máy khách đóng gói SWT vào trong HTTP header. Và gửi nó tới web service.
Bước 5
Web service tiến hành xác nhận tính hợp lệ của token dựa trên khóa bảo mật đã được cung cấp tại bước 0. Web service tiến hành xác nhận hợp lệ của claim yêu cầu và cấp hoặc hủy quyền truy cập tới tài nguyên. Không có sự trao đổi trực tiếp nào giữa ACS và web service trong quá trình phương thức được gọi.
Khoa Công Nghệ Thông Tin – Đại học Công nghệ Hà Nội Trang 69
2.6.2.4. Quản lý tài nguyên dịch vụ kiểm soát truy cập[25]
Lược đồ tài nguyên kiểm soát truy cập được mô tả bằng hình vẽ sau :
Hình số 2.23: Lược đồ tài nguyên dịch vụ kiểm soát truy cập
Service Namespace : Service namespace là tài nguyên cấp cao nhất trong lược đồ AppFabric Access Control. Tất cả các tài nguyên khác là cấp dưới của mỗi service namespace. Các tài nguyên AppFabric Access Control không thể chia sẻ giữa các service namespace với nhau.
Token Policy: Tài nguyên Token policy quyết định thời gian hết hạn, và khóa dùng để ký cho các token được phát ra bởi AppFabric Access Control. Một token policy được liên kết với 0 hoặc nhiều scope. Những tham số điển hình cho token policy như sau :
SigningKey: Khóa ký nhận. Khóa này được ACS sử dụng để ký token.
DefaultTokenLifetimeInSeconds: Thời gian được tính bằng giây mà token còn hiệu lực.
Người sử dụng có thể tạo token policy bằng cách sử dụng công cụ Acm.exe
Scope: Là tập hợp các quy tắc mà ACS dùng để tham chiếu Input claims với Output claims. ACS sử dụng URI scope để tiến hành gom nhóm các quy tắc. Khi người sử dụng đệ trình yêu cầu tới URI scope, ACS sẽ kiểm tra tham số applies_to và sinh ra Output claims. Danh sách các tham số điển hình để tiến hành tương tác với tài nguyên scope được mô tả như sau :
AppliesTo: URI của tài nguyên mà scope tác động.
RuleSets/Id: ID của tập hợp các quy tắc cho scope.
TokenPolicyId: ID của token policy kết hợp với scope.
Người sử dụng có thể tạo scope bằng cách sử dụng công cụ Acm.exe
Issuer: Một issuer là tên của một bộ khóa mã hóa. Service consumers sử dụng nó khi chứng thức với AppFabric Access Control. Các Issuer có thể chứa một cặp
Khoa Công Nghệ Thông Tin – Đại học Công nghệ Hà Nội Trang 70
base64-encoded 32-byte keys, hoặc một chứng chỉ X.509. Chú ý các issuer dùng chứng chỉ X.509 được dùng để chứng thực với SAML token.
Ruleset: Rulesets là tên của một tập các rules. Trong phiên bản hiện tại, ruleset được tạo tự động và tương ứng với mỗi scope. Có nghĩa, mỗi scope có duy nhất một ruleset
Rule: Các rule trong ACS quyết định claim xuất hiện trong token được phát ra bởi ACS. Môt rule chứa một giá trị tiền đề và một giá trị kết quả. Một rule phải liên kết với một ruleset.
Người sử dụng có thể tạo rule bằng cách sử dụng công cụ Acm.exe.