Xây dựng Web Services Trust AccessControl

Một phần của tài liệu Đồ án tìm hiểu về windows azure (Trang 60 - 65)

Chương 1 : TỔNG QUAN WINDOWSAZURE PLATFORM

5.3.2.Xây dựng Web Services Trust AccessControl

5.3. Tổng quan Fabric AccessControl

5.3.2.Xây dựng Web Services Trust AccessControl

5.3.2.1. Mẫu tương tác thông dụng

Các ứng dụng theo Access Control hầu hết đều có cách tương tác như sơ đồ:

Hình 5.5- Sơ đồ trao đổi

- Bước 0: Trao đổi khóa.

Web service đăng ký một khóa bí mật với Access Control thơng qua dịch vụ quản lý Access Control. Access Control 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. Đây là cơ chế chính Web service dùng để chắc chắn sự toàn vẹn của các thể bài nó nhận được. Các khóa này có thể thay đổi quay vòng bởi yêu cầu bào mật của Web service.

- Bước 1: Định nghĩa các luật cho một Service Consumer.

Access Control sử dụng các luật này để quyết định claim xuất hiện trong thẻ bài nó phát ra, và sử dụng các Issuer để định danh các ứng dụng muốn truy cập dịch vụ. Để chuẩn bị cho một service consumer mới , Web service sử dụng Access Control management service để thiết lập các rule và một issuer và phân phối

Window Azure 2013

issuer này cho service consumer.

- Bước 2: Gửi Send Claims đến Access Control để trao đổi Token.

Trước khi truy cập đến dịch vụ Web, service consumer phải yêu cầu một token từ Access Control sử dụng khóa issuermust được nhận từ Web service, Có thể nhận bằng 3 cách sau:

o Gửi khóa Issuer trực tiếp.

o Tạo một token và ký lên nó bởi khóa Issuer.

o Gửi một token ADFSv2-issued SAML được ký với khóa Issuer.

- Bước 3: So khớp Input Claims và Output Claims bằng việc sử dụng các

Rules và phát sinh Token.

Dựa trên token yêu c ầu, Access Control trích xuất và phân tích claim từ token, sử dụng các rules có sẵn để tính tốn claim nào sẽ xuất hiện trên token

phản hồi. Sau khi tính tốn xong, Access Control 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.

- Bước 4: Trả Token về cho client.

Sau khi tạo token, Access Control trả token vè cho service consumer, Access Control luôn luôn trả về một kiêu token, bất chấp cho chế yêu cầu token nào được sử dụng ở bước 2.

- Bước 5: Khởi thông điệp đến cho Web Service với Access Control Token.

Sau khi nhận được Access Control token, service consumer gởi token trong request header đến Web service, cùng với các dữ liệu của mình.

- Bước 6: Web Service kiểm tra tính hợp lệ và Claim trong token.

Sau khi nhận được Access Control token và các dữ liệu, Web service validate và kiểm trả các claim trong token. Nếu token hợp lệ, và các claim yêu cầu

xuất hiện trong token, service consumer được phép truy cập. Ngược lại nếu token không hợp lệ hoặc không chứa claim yêu cầu,service consumer bị từ chối truy cập. Chú ý rằng, Web service không gọi Access Control để kiểm tra token.

Window Azure 2013

5.3.2.2. Cấu trúc một Access Control token

Access Control token tuân theo đặc tả của SimpleWebToken (SWT) - Các cặp Key/Value.

SWT tokens được biểu diễn như một dang căp key/value được encode và ký với khóa mật mã. Sau đây là các key ln xuất hiện trong SWT token.

Bảng 5.5 - Key trong một SWT Toke (adsbygoogle = window.adsbygoogle || []).push({});

Key Mô tả

Issuer Thể hiện cho Access Control service namespace chịu trách nhiệm phát sinh token. Giá trị cho key này có dạng Error! Hype rlink reference not valid.

Audience Giá trị của trường applies_to được sử dụng để yêu cầu token. Giá trị này là một URI HTTP hoặc HTTPS. ExpiresOn Thời gian hết hạn.

HMACSHA256 Chữ ký HMACSHA256 cho tất cả các cặp key/value. Cặp key/value này l à cặp cuối cùng trong token.

-Claims mở rộng.

Ngoài các cặp key/value trên, Access Control thêm một hoặc hiều claim vào token trước khi nó được phát ra. Các claim này được diều khiển bởi cấu hình các rules trong Access Control lúc yêu cầu token. Tất cả các claim đều có kiểu và một hoặc nhiều giát trị, tất cả đêu dạng chuỗi. Khi một claim có nhiều giá trị, chúng được ngăn cách bởi dấu phẩy. Các claim được encode giống như các cặp key/value

ở trên. Ví dụ:

action=add%2csubtract&Issuer=https%3a%2f%2flvth2006.accesscontrol.windows. net%2f&Audience=http%3a%2f%2flocalhost%2facscalculator&ExpiresOn=12755 01214&HMACSHA256=z23ty2XzyIlWXHAp2tJ8EUVV%2fahrnPYRx%2f3zjeIv vTg%3d.

Window Azure 2013

- Chữ ký.

Chữ ký được tính tốn sử dụng tất cả các cặp key/value trước chuỗi

"&HMACSHA256=". Thuật toán Access Control sử dụng là HMACSHA256 và kích thước khóa là 32 bypes.

Ví dụ hàm tạo chữ ký(Có trong SDK sampe)

private string GenerateSignature(string unsignedToken, string signingKey) {

HMACSHA256 hmac = new

HMACSHA256(Convert.FromBase64String(signingKey)); byte[] locallyGeneratedSignatureInBytes = hmac.ComputeHash(Encoding.ASCII.GetBytes(unsignedToken)); string locallyGeneratedSignature = HttpUtility.UrlEncode(Convert.ToBase64String(locallyGen eratedSignatureInBytes)); return locallyGeneratedSignature; }

5.3.2.3. Thiết lập Trust với Access Control

Trong bước đầu tiên, liên quan đến sự thiết lập trust giữa Web service và Access Control, thực chất là viêc thiết lập khóa mật mã với Access Control, và Access Control dùng nó để ký vào các token mà nó phát sinh. Web service có thể sử dụng khóa và thay đổi khóa theo u cầu bảo mật của mình. Access Control sử

dụng khóa đối xứng 32-bytes và thuật tốn HMACSHA256 để ký vào token, Ví dụ: public static byte[] CreateHMACSHA256Key()

{

byte[] sha256key = new Byte[64]; RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();

rng.GetBytes(sha256key); return sha256key;

}

Window Azure 2013

thông qua Access Control management service, qua một thuộc tính ở Access Control Resource là TokenPolicy. Bạn có thể sử dụng Access Control management

service để đăng ký một TokenPolicy mới bằng cách:

Sử dụng ACM.exe (hoặc AcmBrowse.exe) có trong Windows Azure platform AppFabric SDK.

Viết một ứng dụng sử dụng Access Control management service.

5.3.2.4. Yêu cầu Token từ Access Control

Có ba cách để có thể yêu cầu Access Control token, plain text, signed Simple Web Token (SWT), và SAML token. Tất cả các yêu cầu token được truyền qua (adsbygoogle = window.adsbygoogle || []).push({});

SSL. Access Control luôn luôn phát sinh một kiểu token trong response. Ngoài ra, các token request đến Access Control được gởi qua HTTP POST.

Bảng 5.6 - Các kiểu yêu cầu Access Control

Kiểu yêu cầu Mô tả

PlainTe xt Cách đơn giản nhất để yêu cầu token từ Access Control, bằng cách gửi trực tiếp khóa issuer đến Access Control để chứng thực

Signed Client tạo ra một token, ký lên nó, và sử dụng token được ký này để chúng thực với Access Control, 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 Access Control khi yêu cầu token

SAML Chủ yếu dùng cho việc tích hợp với ADFSv2. Cách tiếp cận này, yêu cầu một SAML token và gửi nó đến Access Control để xác thực.

. 5.3.2.5. Mở gói và gởi Token

cho Web Service

Window Azure 2013

tham số được encoded wrap_token và wrap_token_expires_in. Giá trị của các tham số ngày là token và thời gian sống của token tương ứng.

Trước khi gửi token đến Web service, service consumer phải trích xuất và

URL-decode token từ response. Sau đó, gửi đến Web service thông qua header Authorization.

Một phần của tài liệu Đồ án tìm hiểu về windows azure (Trang 60 - 65)