- Một ứng dụng Windows Azure có thể lưu trữ dữ liệu trong Cơ sở dữ liệu SQL Azure. Trong khi bộ lưu trữ Windows Azure không hỗ trợ các bảng dữ liệu quan hệ, mà nhiều ứng dụng đang tồn tại sử dụng cơ sở dữ liệu quan hệ. Vì vậy, lập trình viên có thể chuyển ứng dụng đang chạy sang ứng dụng Windows Azure với lưu trữ dữ liệu trong Cơ sở dữ liệu SQL Azure.
- Xây dựng một ứng dụng của doanh nghiệp nhỏ hoặc của các phòng ban trong công ty lớn có thể lưu trữ dữ liệu trong Cơ sở dữ liệu SQL Azure.
- Giả sử một nhà sản xuất muốn thông tin sản phẩm có sẵn trên cả mạng lưới đại lý và khách hàng. Đưa dữ liệu này vào Cơ sở dữ liệu SQL Azure để cho nó được truy cập bởi các ứng dụng đang chạy tại các đại lý và ứng dụng Web của khách hàng.
Chương 6 Tổng quan Windows Azure Platform AppFabric
6.1. Giới thiệu
Windows Azure platform AppFabric cung cấp dịch vụ cơ sở hạ tầng dựa trên đám mây. Các thành phần của Windows Azure platform AppFabric:
- Service Bus. - Access Control.
6.2. Giới thiệu AppFarbic Service Bus 6.2.1. Giới thiệu
Service Bus trong kiến trúc Windows Azure AppFabric là một dịch vụ hướng đến người phát triển có khả năng tùy biến cao chạy ở trung tâm dữ liệu của Microsoft, là một thành phần của Windows Azure platform. Mục đích chính của Service Bus là chuyển tiếp thông điệp từ đám mây đến các service đang chạy on- premise phía sau các thiết bị firewall và NAT. Service Bus được bổ sung bởi Access Control Service, là một thành phần khác của Windows Azure platform. Service Bus dựa vào Aceess Control trong việc truy cập an toàn đến các điểm cuối. Hai dịch vụ này cùng với nhau cung cấp một môi trường phát triển hiệu quả, đơn giản hóa việc phát triển, cho phép bạn tập trung hơn vào các nghiệp vụ cần thiết.
6.2.2. Kiến trúc Service Bus
Hình 6.21 - Kiến trúc Service Bus.
AppFabric Service Bus chứa 4 service chính: Security service, Naming Service, Service Registry, Messaging Fabric.
6.2.2.1. Security Service
Một trong những vấn đề lớn nhất khi doanh nghiệp đưa ứng dụng lên đám mây là an toàn. Trên môi trường Internet với nhiều mối de dọa từ các hacker hằng ngày, việc đảm bảo an toàn là một vấn để thật sự cần thiết. Với các ứng dụng on- premises, việc này được kiểm soát, điều khiển bởi chính sách của doanh nghiệp, và thường thì thích phòng hơn chống. Với các ứng dụng đám mây, AppFabric Service Bus đưa ra 2 lựa chọn cho việc đảm bào an toàn trao đổi thông điệp từ client đến servic:
• Tích hợp Access Control Service (ACS).
• Messege security.
6.2.2.1.1. Tích hợp Access Control Service
Microsoft đã tích hợp Service Bus với Access Control Service để cung cấp việc xác thực và phân quyền. Cả người gửi, người nhận thông điệp đều phải qua bước kiểm tra an toàn trước khi kến nối được đến Service Bus. Về phía dịch vụ,
Access Control trước khi kết nối đến AppFabric Service Bus. Mặc định, client hay người gửi thông điệp cũng phải xác thực nhưng có thể bỏ qua nếu phía dịch vụ không yêu cầu. Cách thức xác thực của client có thể khác với cách mà service xác thực
Hình 6.22 - Mô hình tích hợp Service bus và Access Control.
Theo đó, quá trình xác thực và gửi thông điệp của client như sau:
1. Client yêu cầu một token SWT từ phía cung cấp nhận dạng, hoặc tạo mới một token SWT, hay yêu cầu khóa bí mật. Gửi token/khóa cùng với yêu cầu “Send” lên Access Control Service. Sau khi xác thực thành công, Access Control Service trả về một SWT token cùng với claim “Send” cho client. 2. Client gửi thông điệp đến cho Service bus với header là token/ khóa
3. Service bus kiểm tra token hợp lệ và gở bỏ nó ra khỏi thông điệp, Việc kiểm tra được thực hiện, nhờ giữa Access Control Service và Service Bus đã thiết lập sự tin tưởng bởi Service Bus Potal. Access Control Service sử dụng khóa công cộng để mã hóa,và Service Bus sử dụng khóa riêng để giải mã.
4. Service bus gửi thông điệp đến cho service Và quá trình xác thực của phía dịch vụ:
1. Phía dịch vụ gửi yêu cầu xác thực đến Access Control Service cùng với claim “Listen”.
2. Một token với claim “Listen” được tích hợp trong phân mô tả yêu cầu gởi đến dich vụ chuyển tiếp (Relay service) AppFabric Service Bus .
3. Relay service kiểm tra token và để cho dịch vụ có thể mở một kết nối 2 chiều từ dịch vụ ra đến Relay service.
Phía dịch vụ, có thể bỏ qua quá trình xác thực cho client bằng cách cấu hình lại cấu hình binding của dịch vụ:
<binding name="default">
<security relayClientAuthenticationType="None" /> </binding>
Giá trị của RelayClientAuthenticationType = None chỉ ra rằng client không cần thiết phải chỉ ra token nào được phát ra bởi Access Control Service.Giá trị mặc định là RelayAccessToken.TransportClientEndpointBehavior là lớp trong không gian tên Microsoft.ServiceBus namespace mô tả hành vi WCF của một endpoint cụ thể đã đăng ký với Service Bus. Thuộc tính CredentialType của TransportClientEndpointBehavior chỉ ra kiểu xác thực bạn dùng cho điểm cuối này.
Bảng 6.3 – Bảng giá trị của TransportClientCredentialType. TransportClientCredentialType Mô tả
SharedSecret Chỉ đến một issuer và issuer key được tạo bởi Access Control Service từ Access Control Service management portal. Service Bus có một tên và khóa issuer dành riêng được tạo mặc định khi bạn tạo mới một service namespace.
Saml Yêu cầu client phải được chứng thực bởi một
token Security Assertions Markup language (SAML). Token SAML token được gửi qua một kết nối SSL.
SimpleWebToken Yêu cầu client xác thực bằng cách gửi SWT token được sinh ra bởi client và đã đăng ký với Access Control Service.
Unauthenticated Không yêu cầu xác thực client để kết nối đến Service Bus.
6.2.2.1.2. Message Security
Xác thực chuyển tiếp (Relay authentication) được hướng đến việc xác thực client và service để giao tiếp với AppFabric Service Bus. Nhưng một giải pháp doanh nghiệp thực thụ, sẽ không hoàn chỉnh nếu thiếu đi sự an toàn trong việc chuyển thông điệp giữa các bên liên quan. An toàn thông điệp chỉ ra việc đảm bào an toàn của thông điệp chuyển từ AppFabric Service Bus đến đích. AppFabric Service Bus đưa ra 4 lựa chọn về an toàn thông điệp giữa client và service.
Bảng 6.4 – Bảng giá trị của Message Security. Message Security Type Mô tả
được gửi như từ client đến service.
Transport Thông điệp được gửi qua một kênh an toàn (ví dụ HTTPS) đến hay từ dịch vụ chuyển tiếp. Bên trong Service Bus, thông điệp được chuyển đi không bảo mật. Đây là kiểu thông dụng và mặc định cho hầu hết các ứng dụng có các thông điệp không chứa các thông tin nhạy cảm.
Message Trong kiểu bảo mật này, Nội dung thông điệp được mã hóa với một chứng chỉ X.509 được cung cấp bởi service. Bởi vì thông điệp được mã hóa. Nên thông điệp truyền trong Service Bus là an toàn. Thông điệp này có thể chứa ủy quyền của client (credential), và service phải xác thực nó nếu nó tồn tại trong thông điệp.
TransportWithMessageC redentials
Kiểu bảo mật này là sự kết hợp giữa hai kiểu Transport và Message security types. Sự truyền tải giữa dịch vụ chuyển tiếp và ứng dụng được đảm bảo sử dụng kênh truyền an toàn, và thông điệp được chuyển đi từ client được mã hóa.
6.2.2.2. Naming Service
Naming service cho phép bạn gán một định danh DNS cho dịch vụ của bạn, mà dịch vụ có thể dể dàng được phân giải trên Internet. Với AppFabric Service Bus,có một tên miển gốc (root) có thể được phân giải thông qua Internet DNS, và dịch vụ naming dựa vào một tiểu chuẩn khác- đó là không gian tên dịch vụ (service namespace).
Sơ đồ gọi tên của Service Bus thể hiện như sau:
Như vậy, cách để xác định URI của một dịch vụ như sau:
[scheme]://[service-namespace].servicebus.windows.net/[nameB]/[name2]/... Trong đó: [scheme]: có thể là “sb” dùng cho các điểm cuối TCP-based, “http” và “https” cho các điểm cuối HTTP-based. [service-namespace] là tên duy nhất của service namespace, được xác định trên Potal. [nameA],[name2] là các tên do chính bạn định nghĩa.
6.2.2.3. Service Registry
Service Bus cung cấp dịch vụ đăng ký cho việc công bố và khám phá các điểm cuối bên trong một service namespace. Mặc khác có thể khám phá các điểm cuối bằng cách truy cập đến service namespaee dựa vào địa chỉ của service namespace và nhận về một Atom feeds.
Service Bus có thể đảm bảo việc công bố thông tin các điểm cuối khi bạn đăng ký một điểm cuối mới. Nếu bạn muốn một điểm cuối có thể được phân giải, bạn cần chỉ ra trong thiết lập ServiceRegistrySettings behavior với điểm cuối WCF, đặt giá trị cho thuộc tính DiscoveryMode thành DiscoveryType.Public.
6.2.2.4. Messaging Fabric
Messaging fabric cho phép việc chuyển tiếp, và giao tiếp của các thông điệp giữa client và service. Nó có thể biểu diễn các điểm cuối dịch vụ lên đám mây cho các dịch vụ on-premises cũng như các dịch vụ triển khai trên đám mây. Đồng thời, tích hợp với Access Control Service để cung cấp sự an toàn ở mức độ thông điệp. Dịch vụ chuyển tiếp là thành phần cốt lõi của AppFabric Service Bus messaging fabric.
Dịch vụ chuyển tiếp (relay service) làm cho nó có thể dể dàng xây dựng giải pháp có thể giao tiếp qua các thiết bị tường lửa hay NAT sử dụng các mẫu thông điệp khác nhau. Dịch vụ chuyển tiếp hỗ trợ one-way messaging, request/response messaging, and peer-to-peer messaging. Đồng thời, hỗ trợ bộ đệm thông điệp (Message buffer) cho các dịch vụ không có khả năng sử dụng SDK để tích hợp và chỉ sử dụng HTTP.
Service mở một kết nối outbound với một kết nối 2 chiều với AppFabric Service Bus relay service, Dịch vụ đăng ký sẽ đăng ký một điểm cuối cho các listener để cho client có thể phân giải được. Hầu hết các listener yêu cầu các cổng sau được mở trên firewall và NAT: 808, 818, 819, và 828. Relay service sử dụng cổng 808 cho kết nối một chiều TCP, và 828 cho kết nối một chiều TCP/SSL, Nó sử dụng cổng 818 và 819 cho kết nối 2 chiều TCP và các kết nối nâng cao khác. Điều quan trọng là bạn không cần phải mở bất kì cổng inbound nào trên thiết bị firewall
- AppFabric Service Bus Binding
Mô hình lập trình chính để làm việc với Service Bus trên nền .Net framework là WCF. SDK ra đời với một bộ WCF binding mới tự động tích hợp giữa các service và client WCF với relay service.Sau đây là các binding được hỗ trợ bởi WCF và của Service Bus tương ứng.
Bảng 6.5 – WCF và AppFabric Service Bus Binding.
. -
System Connectivity Mode
Trừ các kiểu binding HTTP, trong các kiểu binding còn lại, một service WCF kết nối đến relay service thông qua kết nối TCP theo mặc định, Nếu bạn muốn không cho phép bất kì kết nối TCP outbound nào, bạn có thể thiết lập lại để WCF chỉ kết nối HTTP thay vì TCP. Service Bus cung cấp một lớp hệ thống ConnectivityMode cho phép bạn thiết lập một trong 3 giá trị: Tcp, Http, và AutoDetect
Bảng 6.6 – Giá trị ConnectivityMode. ConnectivityMod
e
Description
Tcp Service tạo kết nối TCP với relay service thông qua cổng 828(SSL).
Http Service tạo kết nối HTTP với relay service AutoDetect
(Default)
Tự động lựa chọn giữa Tcp và http dựa vào cơ chế phát hiện tự động, rằng có thể, kết nối hiện tại có thể là tcp. Nếu sau khi thử với Tcp thất bại, sẽ tự động chuyển sang két nối Http
Standard WCF Binding Equivalent Relay Binding
BasicHttpBinding BasicHttpRelayBinding WebHttpBinding WebHttpRelayBinding WS2007HttpBinding WS2007HttpRelayBinding NetTcpBinding NetTcpRelayBinding N/A NetOnewayRelayBinding N/A NetEventRelayBinding
6.2.3. Message Buffer
6.2.3.1. Giới thiệu Message Buffer
Bộ đệm thông điệp là bộ đệm nhỏ, tạm thời dùng để lưu giữ thông điêp trong thời gian ngắn, cho đến khi chúng được nhận. Client gửi thông điệp đến message buffer và ứng dụng on-premise nhận thông điệp từ bộ đệm thông điệp tương ứng.
Hình 6.24 – Message Buffer trong Service Bus.
Message buffers đặc biệt hữu ích cho mô hình lập trình Web khi mà Windows Azure platform AppFabric Service Bus bindings không sử dụng được. Message buffers có thể được truy cập bởi ứng dụng sử dụng HTTP và không cần có Windows Azure platform AppFabric SDK. Do đó, message buffers cho phép các lập trình viên Web,thiết bị di động,.., để tích hợp với ứng dụng với AppFabric Service Bus bằng việc tạo “message consumers “ cho phép sử dụng HTTP để yêu cầu thu lấy thông điệp.
6.2.3.2. Message Buffer Policy
Chính sách bộ đệm thông điệp là một tài liệu XML định nghĩa các thông tin cần thiết cho một bộ đệm thông điệp. Bạn phải chèn thêm chính sách này vào request khi tạo mời một bộ đệm thông điệp. Bạn cũng có thể cập nhật một tài liệu đã có để làm mới thời gian hết hạn của bộ đệm.Khi thực hiện điều này, bạn phải chắc chắn các thuộc tính khác không thay đổi.
6.2.3.3. Message Buffer Protocol
Giao thức message buffer là giao thức HTTP REST được thiết kế dựa theo chuẩn REST để có thể đơn giản và dể dàng hiểu. Mục đích là đảm bào lập trình viên có thể dể dàng sử dụng giao thức từ bất kỳ client mà không cần có SDK hay thư viện nào. Giao thức dựa vào mô hình chứng thực HTTP của AppFabric Access Control Service để giúp nó điều khiển truy cập trên bộ đệm thông điệp. Điều này có nghĩa nó sử dụng Simple Web Token (SWT) bạn có thể nhận token sử dụng HTTP và nhúng nó vào HTTP request header. Token này có thể chứa thêm các claim được sử dụng để quyết dịnh nơi nào một thao tác có thể được chấp nhận.
Với giao thức này, yêu cầu mỗi bộ đệm thông điệp phải được định vị tại một URL duy nhất trong AppFabric Service Bus namespace. URL này trở thành gốc cho bộ các tài nguyên đại diện cho thể hiện của bộ đệm. Mỗi kiểu tài nguyên có một URI duy nhất, và ứng với một tập các HTTP verb tương tác với nó.
Các HTTP verbs được sử dụng tương tác với message buffers :
• POST/PUT: Dùng để tạo mới hay cập nhật tài nguyên. PUT được sử dụng để tạo tài nguyên mới, PUT được sử dụng để tạo/cập nhật tài nguyên bộ đệm thông điệp.
• PUT: Sử dụng để cập nhật tài nguyên đã tồn tại • DELETE: Sử dung để xóa tài nguyên.
• GET: Nhận về một tài nguyên.
6.2.3.4. Message Buffer Quota
Mặc định, bộ bộ đệm chứa tối đa 10 thông điệp. Bạn có thể thay đổi giá trị này qua thuộc tính MaxMessageCount trong lớp MessageBufferPolicy. Số lương tối đa là 50 thông điệp.
6.3. Tổng quan Fabric Access Control 6.3.1. Giới thiệu
Windows Azure platform AppFabric Access Control (AC) service là dịch vụ dùng để cung cấp chứng thực liên đoàn(federated authentication) và phân quyền dựa trên các luật, và dựa trên các claim cho các dịch vụ Web REST. Chúng có thể
dựa vào AC services trong các kịch bản đơn giản như tên đăng nhâp, mật khẩu, hay các kịch bản tích hợp sử dụng Active Directory Federation Services (ADFS) v2.
Windows Azure platform AppFabric Access Control service đơn giản hóa việc điều khiển truy cập cho các nhà cung cấp dịch vụ Web bởi việc giảm chi phí, và sự phức tạp trong việc tích hợp với các công nghệ chứng thực khác của khách hàng. Thay vì phải làm việc với các công nghệ khác nhau, các dịch vụ Web có thể dể dàng tích hợp với AppFabric Access Control, đồng thời có thể tích hợp với tất cả các mô hình và công nghệ chứng thực mà AppFabric Access Control hỗ trợ thông qua một quá trình chuản bị đơn giản, và thông qua các API quản lý REST-based.
Tất cả các ứng dụng liên quan đến AAC đều chứa 3 phần chính:
- Service provider: Dịch vụ Web REST.
- Service consumer: Các ứng dụng khách truy cập đến dịch vụ. - Token issuer: AppFabric Access Control phục vụ cho chính nó.
Các đặc tính chính:
Với phiên bản tháng 12/2009, AppFabric Access Control tập trung cho việc phân quyền cho các dịch vụ Web REST và AppFabric Service Bus. Sau đây là các tính năng cơ bản:
- Hỗ trợ Cross-platform. AppFabric Access Control có thể được truy cập từ các ứng dụng chạy trên các hệ điều hành hay các platform có hỗ trợ giao thức HTTPS.
- Tích hợp với Active Directory Federation Services (ADFS) 2.0 , bao gồm cả khả năng phân tích và xuất bản WS-Federation metadata.
- Chứng thực và phân quyền sử dụng khóa đối xứng và chữ ký HMACSHA256.
- Có khả năng cấu hình các luật, cho phép mapping các claim input và output. Hỗ trợ Web Resource Authorization Protocol (WRAP) và Simple Web Token (SWT).
6.3.2. Xây dựng Web Services Trust Access Control 6.3.2.1. Mẫu tương tác thông dụng