Công nghệ RESTful web services và hệ thống cổng kết nối với tổng đài tin nhắn cho các dịch vụ thông tin di động

Một số phần mềm đòi hỏi về lượng thông tin lớn, dữ liệu lớn… nhưng không thể lưu dữ liệu đó tại thiết bị sử dụng, một số loại yêu cầu được cập nhật realtime theo thời gian thực để đảm bả

BỘ GIÁO DỤC VÀ ĐÀO TẠO

VIỆN ĐẠI HỌC MỞ HÀ NỘI

LUẬN VĂN THẠC SỸ

CHUYÊN NGÀNH: CÔNG NGHỆ THÔNG TIN

CÔNG NGHỆ RESTFUL WEB SERVICES

VÀ HỆ THỐNG CỔNG KẾT NỐI VỚI TỔNG ĐÀI TIN NHẮN

CHO CÁC DỊCH VỤ THÔNG TIN DI ĐỘNG

BỘ GIÁO DỤC VÀ ĐÀO TẠO

VIỆN ĐẠI HỌC MỞ HÀ NỘI

LUẬN VĂN THẠC SỸ

CÔNG NGHỆ RESTFUL WEB SERVICES

VÀ HỆ THỐNG CỔNG KẾT NỐI VỚI TỔNG ĐÀI TIN NHẮN

CHO CÁC DỊCH VỤ THÔNG TIN DI ĐỘNG

LỜI CAM ĐOAN

Tôi xin cam đoan luận văn là công trình nghiên cứu của riêng cá nhân tôi, không sao chép của ai do tôi tự nghiên cứu, đọc, dịch tài liệu, tổng hợp và thực hiện Nội dung lý thuyết trong trong luận văn tôi có sử dụng một

số tài liệu tham khảo như đã trình bày trong phần tài liệu tham khảo Các số liệu, chương trình phần mềm và những kết quả trong luận văn là trung thực và chưa được công bố trong bất kỳ một công trình nào khác

Hà Nội, ngày tháng năm 2017

Học viên thực hiện

Nguyễn Thị Lan

LỜI CẢM ƠN

Lời đầu tiên, em xin gửi lời biết ơn sâu sắc đến TS Đinh Tuấn Long người đã tận tình hướng dẫn, chỉ bảo, giúp đỡ em trong suốt quá trình làm luận văn

Em cũng xin gửi lời cảm ơn đến các thầy cô giảng dạy và các thầy cô trong Khoa Đào Tạo Sau Đại Học đã truyền đạt những kiến thức và giúp đỡ

em trong suốt quá trình học của mình

Và cuối cùng em xin gửi lời cảm ơn tới các đồng nghiệp, gia đình và bạn bè những người đã ủng hộ, động viên tạo mọi điều kiện giúp đỡ để

em có được kết quả như ngày hôm nay

Hà Nội, ngày tháng năm 2017

Học viên thực hiện

Nguyễn Thị Lan

MỤC LỤC

LỜI CAM ĐOAN i

LỜI CẢM ƠN ii

MỤC LỤC iii

DANH MỤC CÁC THUẬT NGỮ, CHỮ VIẾT TẮT vi

DANH SÁCH HÌNH VẼ vii

MỞ ĐẦU viii

CHƯƠNG 1: DỊCH VỤ WEB SERVICE VÀ REST 1

1.1Tổng quan về dịch vụ web 1

1.2Kiến trúc và các thành phần của dịch vụ Web service 4

1.2.1Khái niệm định dạng XML - eXtensible Markup Language 4

1.2.2Mô tả các giao thức sử dụng trong dịch vụ web SOAP - Simple Object Access Protocol 5

1.2.3WSDL - Web Service Description Language 7

1.2.4Khái niệm UDDI 9

1.3XML-RPC 9

1.4Khái niệm REST 10

1.5Nguyên tắc của REST 11

1.5.1Tài nguyên 12

1.5.2Khả năng đánh địa chỉ 13

1.5.3Phi trạng thái 14

1.5.4Kết nối 14

1.5.5Giao diện đồng nhất 15

1.5.6Khả năng lưu cache 16

1.6Dịch vụ web RESTful 17

1.7So sánh SOAP và RESTful 18

KẾT LUẬN CHƯƠNG 21

CHƯƠNG 2: VẤN ĐỀ BẢO MẬT VỚI WEB SERVICE DỊCH VỤ RESTFUL 22

2.1 Vấn đề an toàn bảo mật Web Service 22

2.1.1 Bảo mật Web Service 22

2.1.2 Một số kỹ thuật Web Service Security 23

2.2 Vấn đề bảo mật với dịch vụ RESTful 29

2.3 Kiểu kiến trúc REST phù hợp với bộ đệm web 30

2.4 Khóa mã hóa nội dung đối xứng 31

2.5 An toàn cho dịch vụ web 32

2.6 Xây dựng một dịch vụ web 34

2.7 Tích hợp dịch vụ web theo chuẩn 35

2.8 Thảo luận về giải pháp 37

2.9 Áp dụng bảo mật dịch vụ web RESTful 38

2.9.1 Bảo mật dịch vụ web RESTful bằng cách cấu hình web.xml 38

2.9.2 Bảo mật dịch vụ web RESTful bằng cách sử dụng SecurityContext 38

2.9.3 Bảo mật dịch vụ web RESTful bằng cách sử dụng ký hiệu 39

KẾT LUẬN CHƯƠNG 40

CHƯƠNG 3: TÌM HIỂU HỆ THỐNG SMS GATEWAY 41

3.1 Tìm hiểu về hệ thống SMSGatewate 41

3.1.1 Giới thiệu chung về hệ thống 41

3.1.2 Nguyên tắc hoạt động của hệ thống SMS 42

3.1.3 Hệ thống SMSGateway 42

3.1.4 Mục tiêu áp dụng REST 44

3.1.5 Tài nguyên 45

3.1.6 Đánh địa chỉ 46

3.1.7 Phi trạng thái 46

3.1.8 Liên kết với nhau 47

3.1.9 Giao diện đồng nhất 47

3.1.10 Khả năng cache 49

3.2 Cấu trúc REST API 49

3.3 Các lược đồ tuần tự 52

3.4Thử nghiệm API với Google Chrome 64

3.5Thử nghiệm API với giao diện ứng dụng 65

KẾT LUẬN CHƯƠNG 68

KẾT LUẬN 69

TÀI LIỆU THAM KHẢO 70

PHỤ LỤC 71

DANH MỤC CÁC THUẬT NGỮ, CHỮ VIẾT TẮT

REST Representational State

Protocol

Giao thức truy cập đối tượng đơn giản

UDDI Universal Description,

Discovery và Integration HTTP Hypertext Transfer Protocol Giao thức truyền tải nội dung

siêu văn bản

RPC Remote Procedure Call Triệu gọi thủ tục từ xa

JAX-RS Java API for RESTful Web

Services

Thư viện API cho dịch vụ web RESTful

URI Uniform resource identifier Xác định tài nguyên đồng nhất

DANH SÁCH HÌNH VẼ

Hình 1.1: Kiến trúc dịch vụ web 4

Hình 1.2: Mô tả hoạt động của SOAP 6

Hình 1.3: Cấu trúc của một thông điệp SOAP 6

Hình 1.4: Cấu trúc của WSDL 7

Hình 1.5:Các thành phần của WSDL 8

Hình 1.6: Hai uri cùng trỏ đến một tài nguyên 12

Hình 1.7: Minh họa việc gửi địa chỉ 13

Hình 1.8: Sự liên kết giữa các máy khách 14

Hình 1.9: So sánh SOAP và RESTful 19

Hình 3.1: Mô hình hệ thống SMS Gateway 42

Hình 3.2: Nguyên tắc hoạt động của hệ thống 42

Hình 3.3: Mô hình hệ thống SMSGateway 43

Hình 3.4: Mô hình REST API trong hệ thống admin 44

Hình 3.5: Mô hình REST API trong hệ thống 50

Hình 3.6: Thiết kế cấu trúc REST API trong hệ thống 51

Hình 3.7: Lược đồ tuần tự lấy danh sách MO 56

Hình 3.8: Lược đồ tuần tự lấy một MO 58

Hình 3.9: Lược đồ tuần tự tạo mới một MO 60

Hình 3.10: Lược đồ tuần tự cập nhật một MO 61

Hình 3.11: Lược đồ tuần tự tìm kiếm MO 63

Hình 3.12: Kiểm tra chức năng POST dữ liệu với Postman 64

Hình 3.13: Kiểm tra chức năng GET dữ liệu với Postman 65

Hình 3.14: Giao diện demo chức năng POST 66

Hình 3.15: Kiểm tra chức năng GET dữ liệu với ứng dụng demo 67

MỞ ĐẦU

1 Lý do chọn đề tài

Ngày này hệ thống Internet ngày càng phát triển, phần mềm sử dụng hệ thống Internet ngày càng nhiều Các phần mềm đa dạng dẫn đến có rất nhiều yêu cầu cần được đáp ứng Một số phần mềm đòi hỏi về lượng thông tin lớn, dữ liệu lớn… nhưng không thể lưu dữ liệu đó tại thiết bị sử dụng, một số loại yêu cầu được cập nhật realtime (theo thời gian thực) để đảm bảo sự đúng đắn của thông tin (chứng khoán, tiền tệ ), một số phần mềm đòi hỏi xử lý nhanh và mạnh, mà các thiết bị lại không thể thực hiện được do cấu hình không đủ Thông thường, để sử dụng các dịch vụ đó thì người dùng cần dùng trình duyệt, truy cập website và thực hiện Nhưng người dùng chỉ có thể sử dụng các giao diện mà nhà cung cấp đã thiết kết sẵn tuy nhiên chúng không đáp ứng những mong muốn của người dùng Để giải quyết vấn đề trên chúng ta cần xây dựng một ứng dụng có các tính năng như các dịch vụ đó nhưng giao diện thân thiện hơn Vì vậy cần phải sử dụng những dịch vụ riêng biệt để tương tác với hệ thống cung cấp các dịch vụ nói trên Công nghệ có thể hỗ trợ để giải quyết bài toán trên là RESTful, do vậy tôi xin được lựa chọn đề tài nghiên cứu là: “Công nghệ RESTful web services và hệ thống cổng kết nối với tổng đài tin nhắn cho các dịch vụ thông tin di động”

2 Mục tiêu và đối tượng nghiên cứu của đề tài

- Mục tiêu nghiên cứu

+ Hiểu được các nguyên tắc của REST

+ Hiểu được loại dữ liệu được điều khiển bởi các hệ thống dựa trên nền web

+ Đưa ra được phương pháp xây dựng cách thức truy cập dữ liệu sử dụng API REST

+ Tiến hành cài đặt API RESTful theo phương pháp trên

+ Cho thấy rằng API vừa cài đặt có thể dùng chung cho cả người và máy

- Đối tượng và phạm vi nghiên cứu

Đối tượng nghiên cứu:

+ Tìm hiểu nguồn gốc từ REST và ý nghĩa

+ Tìm hiểu về thư viện JAX-RS

+ Nghiên cứu dịch vụ RESTful, các phương pháp bảo mật cơ bản, cũng như các vấn đề liên quan

3 Nội dung

Chương 1: Giới thiệu chung về dịch vụ web, kiến trúc và các thành phần cơ bản của dịch vụ web như XML, SOAP, WSDL và UDDI từ đó đưa ra mục tiêu phát triển luận văn, cũng trong chương này sẽ giới thiệu về REST, mô tả từ khóa REST ngày nay rất phù hợp với nền tảng cơ bản với dịch vụ web, đưa ra lý do tại sao chọn REST để phát triển dịch vụ web, và phần giới thiệu hệ thống mà sau này tác giả có

ý định phát triển dịch vụ RESTful cũng được giới thiệu trong phần này Giới thiệu thư viện JAX-RS và cách sử dụng thư viện vào việc lập trình phát triển dịch vụ web, các tính năng cũng như các toán tử của thư viện JAX-RS cũng sẽ được trình bày ở chươn g này

Chương 2: Chương này giới thiệu các phương pháp bảo mật cơ bản cũng như cách thực hiện và áp dụng vào hệ thống

Chương 3: Trong nội dung của chương này sẽ tìm hiểu về hệ thống SMSGateway, nguyên tắc hoạt động của hệ thống cũng như mục tiêu mà hệ thống cần đạt được, áp dụng các nguyên tắc của REST và sử dụng thư viện JAX-RS để thiết kế các dịch vụ web RESTful ứng dụng vào hệ thống SMSGateway Ngoài ra

sẽ có các thực nghiệm mô tả các tiến trình phát triển ứng dụng và cung cấp một một vài tool để có thể thực nghiệm ứng dụng thực hiện các yêu cầu REST API

4 Phương pháp thực hiện đề tài

 Thu thập, phân tích các tài liệu và những thông tin liên quan đề đề tài

 Tìm hiểu các giải pháp trong việc xây dựng API của một số Website trong và ngoài nước

 Kết hợp các nghiên cứu đã có trước đây của các tác giả trong và ngoài nước cùng với sự chỉ bảo, góp ý của thầy hướng dẫn để hoàn thành nội dung nghiên cứu

CHƯƠNG 1: DỊCH VỤ WEB SERVICE VÀ REST

Trong nội dung chương này tác giả sẽ tìm hiểu tổng quan về dịch vụ web, kiến trúc, thành phần cơ bản, cũng trong chương này tác giả sẽ đưa ra những tìm hiểu nguồn gốc từ REST và ý nghĩa của nó, tại sao chúng ta lựa chọn REST thay thế mà không phải là cái khác Trong chương này cũng giới thiệu những ý tưởng cơ bản của REST, các đặc điểm chính và lý do nên sử dụng REST

1.1 Tổng quan về dịch vụ web

Dịch vụ Web (Web Service) được coi là một công nghệ mang đến cuộc cách mạng trong cách thức hoạt động của các dịch vụ B2B (Business to Business) và B2C (Business to Customer) Giá trị cơ bản của dịch vụ Web dựa trên việc cung cấp các phương thức theo chuẩn trong việc truy nhập đối với hệ thống đóng gói và hệ thống kế thừa Các phần mềm được viết bởi những ngôn ngữ lập trình khác nhau và chạy trên những nền tảng khác nhau có thể sử dụng dịch vụ Web để chuyển đổi dữ liệu thông qua mạng Internet theo cách giao tiếp tương tự bên trong một máy tính Tuy nhiên, công nghệ xây dựng dịch vụ Web không nhất thiết phải là các công nghệ mới, nó có thể kết hợp với các công nghệ đã có như XML, SOAP, WSDL, UDDI… Với sự phát triển và lớn mạnh của Internet, dịch vụ Web thật sự là một công nghệ đáng được quan tâm để giảm chi phí và độ phức tạp trong tích hợp và phát triển hệ thống Chúng ta sẽ xem xét các dịch vụ Web từ mức khái niệm đến cách thức xây dựng

1.1.1 Giới thiệu công nghệ

Có rất nhiều những định nghĩa được đưa ra, nhưng theo định nghĩa của W3C (World Wide Web Consortium) [18] thì một dịch vụ web là một hệ thống phần mềm được xây dựng sẵn các tính năng cần thiết, hay còn gọi là các phương thức theo chuẩn để hỗ trợ sự tương tác giữa máy tính và máy tính, giữa người và máy tính Dịch vụ web cung cấp một API được mô tả theo một định dạng chung gọi là ngôn ngữ mô tả dịch vụ web (Web Service Description Language) viết tắt

là WSDL [6] Trong đó người dùng hoặc máy tính thực hiện tương tác với dịch

vụ web thông qua giao thức SOAP (Simple Object Access Protocol) [9] Đây là

một trong các giao thức được sử dụng để trao đổi thông tin trên mạng phổ biến nhất hiện nay sử dụng HTTP (Hypertext Transfer Protocol) [12,6,7] kết hợp với việc sử dụng XML cùng với một số chuẩn khác Tóm lại qua đây chúng ra dễ dàng nhận thấy mục đính chính của dịch vụ web là cho phép trao đổi và tương tác thông tin, các chức năng, dữ liệu, các tài nguyên giữa các ứng dụng một cách

dễ dàng mà không cần quan tâm đến môi trường phát triển cũng như ngôn ngữ lập trình bởi tất cả đã cả được quy về một định dạng chung Ngoài ra chúng ta cần hiểu rõ được bản chất của dịch vụ web là một tập hợp các đối tượng, các phương thức được thực thi và công bố lên mạng để có thể triệu gọi được từ xa thông qua các ứng dụng khác nhau

1.1.2 Các đặc điểm của dịch vụ web

a Đặc điểm

- Dịch vụ Web cho phép client và server tương tác được với nhau ngay cả trong những môi trường khác nhau Ví dụ, đặt Web server cho ứng dụng trên một máy chủ chạy hệ điều hành Linux trong khi người dùng sử dụng máy tính chạy hệ điều hành Windows, ứng dụng vẫn có thể chạy và xử lý bình thường mà không cần thêm yêu cầu đặc biệt để tương thích giữa hai hệ điều hành này

- Phần lớn kĩ thuật của Dịch vụ Web được xây dựng dựa trên mã nguồn mở và được phát triển từ các chuẩn đã được công nhận, ví dụ như XML

- Một Dịch vụ Web bao gồm có nhiều mô-đun và có thể công bố lên mạng Internet

- Là sự kết hợp của việc phát triển theo hướng từng thành phần với những lĩnh vực cụ thể và cơ sở hạ tầng Web, đưa ra những lợi ích cho cả doanh nghiệp, khách hàng, những nhà cung cấp khác và cả những cá nhân thông qua mạng Internet

- Một ứng dụng khi được triển khai sẽ hoạt động theo mô hình client-server

Nó có thể được triển khai bởi một phần mềm ứng dụng phía server ví dụ như PHP, Oracle Application server hay Microsoft.Net…

- Ngày nay dịch vụ Web đang rất phát triển, những lĩnh vực trong cuộc sống

có thể áp dụng và tích hợp dịch vụ Web là khá rộng lớn như dịch vụ chọn lọc

và phân loại tin tức (hệ thống thư viện có kết nối đến web portal để tìm kiếm các thông tin cần thiết); ứng dụng cho các dịch vụ du lịch (cung cấp giá vé, thông tin về địa điểm…), các đại lý bán hàng qua mạng, thông tin thương mại như giá cả, tỷ giá hối đoái, đấu giá qua mạng…hay dịch vụ giao dịch trực tuyến (cho cả B2B và B2C) như đặt vé máy bay, thông tin thuê xe…

- Các ứng dụng có tích hợp dịch vụ Web đã không còn là xa lạ, đặc biệt trong điều kiện thương mại điện tử đang bùng nổ và phát triển không ngừng cùng với sự lớn mạnh của Internet Bất kì một lĩnh vực nào trong cuộc sống cũng

có thể tích hợp với dịch vụ Web, đây là cách thức kinh doanh và làm việc có hiệu quả bởi thời đại ngày nay là thời đại của truyền thông và trao đổi thông tin qua mạng Do vậy, việc phát triển và tích hợp các ứng dụng với dịch vụ Web đang được quan tâm phát triển là điều hoàn toàn dễ hiểu

b Ưu và nhược điểm

- Nâng cao khả năng tái sử dụng

- Thúc đẩy đầu tư các hệ thống phần mềm đã tồn tại bằng cách cho phép các tiến trình/chức năng nghiệp vụ đóng gói trong giao diện dịch vụ Web

- Tạo mối quan hệ tương tác lẫn nhau và mềm dẻo giữa các thành phần trong

hệ thống, dễ dàng cho việc phát triển các ứng dụng phân tán

- Thúc đẩy hệ thống tích hợp, giảm sự phức tạp của hệ thống, hạ giá thành hoạt động, phát triển hệ thống nhanh và tương tác hiệu quả với hệ thống của các doanh nghiệp khác

Nhược điểm

- Những thiệt hại lớn sẽ xảy ra vào khoảng thời gian chết của Dịch vụ Web, giao diện không thay đổi, có thể lỗi nếu một máy khách không được nâng cấp, thiếu các giao thức cho việc vận hành

- Có quá nhiều chuẩn cho dịch vụ Web khiến người dùng khó nắm bắt

- Phải quan tâm nhiều hơn đến vấn đề an toàn và bảo mật

1.2 Kiến trúc và các thành phần của dịch vụ Web service

Trong lĩnh vực công nghệ thông tin thì công nghệ dịch vụ web không phải là một công nghệ mới, mà công nghệ này đã được ra đời dựa trên các nền tảng công nghệ sẵn có trước đó Nó sự kết hợp của các ứng dụng dựa trên nền web sử dụng

được sử dụng để mô tả dữ liệu, SOAP đóng vai trò giao thức truyền tải dữ liệu, WSDL đóng vài trò mô tả cho dịch vụ web còn UDDI đóng vai trò cung cấp danh sách các dịch vụ web đang hoạt động Về chi tiết các chuẩn mở này như đặc điểm sẽ được làm rõ hơn trong phần sau của luận văn Dựa vào sơ đồ dưới có thể thấy các thành phần cơ bản của dịch vụ web

Hình 1.1: Kiến trúc dịch vụ web

1.2.1 Khái niệm định dạng XML - eXtensible Markup Language

- XML (Extensible Markup Langguage) là một chuẩn do W3C đề ra và được phát triển từ SGML, XML được xem là một ngôn ngữ đánh dấu mở rộng với

cấu trúc do lập trình viên phát triển dịch vụ tự định nghĩa Về hình thức thì XML hoàn toàn có cấu trúc thẻ giống như HTML, nhưng HTML định nghĩa thành phần được hiện thị như thế nào thì XML lại định nghĩa những thành phần đó chứa những cái gì Hay nói cách khác XML có cú pháp tương tự HTML nhưng không tuân theo một đặc tả quy ước như HTML Người sử dụng hoặc các chương trình có thể quy ước định dạng các thẻ XML

Về cơ bản có thể thấy dịch vụ web là sự kết hợp của nhiều thành phần khác nhau, và dịch vụ này hỗ trợ tương tác giữa các hệ thống được cài đặt trên môi trường khác nhau Do đó cần phải sử dụng một loại tài liệu đồng nhất giúp giải quyết được vấn đề tương thích và XML hoàn toàn phù hợp với yêu

cầu trên Có thể hiểu đơn giản XML giải quyết Blues Middleware truyền thống kết hợp với kết nối chặt chẽ XML làm cho webservice linh hoạt và thích nghi XML đã trở thành nền tảng cho việc xây dựng các dịch vụ web và

XML có hai chức năng chính:

- Trao đổi thông tin dữ liệu trong hệ thống sử dụng dịch vụ web

SOAP - Simple Object Access Protocol

SOAP (Simple Object Access Protocol) là một giao thức dùng để truy xuất các thông tin từ dịch vụ web thông qua một thông điệp chung SOAP được Microsoft đề xuất vào năm 1998, hiện nay SOAP thuộc quyền quản lý và cải tiến của tổ chức W3C SOAP là một giao thức dựa trên nền tảng XML(HTTP/SMTP), mô tả cách định dạng, đóng gói thông tin của các thông điệp và trao đổi chúng thông qua mạng mà không phụ thuộc bất kỳ môi trường thực thi hay ngôn ngữ lập trình nào

Hình 1.2: Mô tả hoạt động của SOAP

Đơn vị trao đổi thông tin cơ bản của SOAP là thông điệp SOAP (SOAP Message) Mỗi thông điệp SOAP sẽ được dùng bởi một thẻ gốc là <Envelope> trong đó chứa 2 thẻ thành phần là SOAP Header và SOAP Body SOAP Header chứa các thông tin cần thiết cho việc thực hiện chuyển thông điệp hay cơ chế định danh, bảo mật SOAP Body chứa dữ liệu ứng dụng Cấu trúc của một thông điệp SOAP như hình sau:

Hình 1.3: Cấu trúc của một thông điệp SOAP

Chúng ta đã hiểu cơ bản Web service như thế nào nhưng vẫn còn một vấn

đề khá quan trọng Đó là làm thế nào để truy xuất dịch vụ khi đã tìm thấy? Câu trả lời là các Web service có thể truy xuất bằng một giao thức là Simple Object Access Protocol – SOAP Nói cách khác chúng ta có thể truy xuất đến UDDI registry bằng các lệnh gọi hoàn toàn theo định dạng của SOAP

1.2.3 WSDL - Web Service Description Language

WSDL (Web Service Description Langguage) là một tài liệu đặc tả dựa trên chuẩn ngôn ngữ XML để mô tả các dịch vụ web Ban đầu WSDL được Microsoft và Ariba đề xuất, nhưng hiện nay WSDL được quản lý và phát triển bởi W3C Mỗi một đặc tả WSDL sẽ cung cấp tài liệu cho các hệ thống phân tán cũng như mô tả chức năng của một dịch vụ web, cách thức tương tác, các thông điệp tương tác cho các yêu cầu theo request hay response Sau đây là cấu trúc

cơ bản của một tài liệu:

Hình 1.4:Cấu trúc của WSDL

Một đặc tả WSDL bao gồm 2 phần chính: phần trừu tượng (Abstract definitions) và phần cụ thể (Concrete definitions), phần trừu tượng bao gồm các thông tin được chứa trong các thẻ types, message và portypes Phần cụ thể bao gồm các thông tin được chứa trong các thẻ bindings và ports Mỗi thành phần sẽ

có một tham chiếu đến một thành phần khác được mô tả như hình sau:

Hình 1.5:Các thành phần của WSDL

Mỗi một thành phần có một chức năng riêng, cụ thể như sau:

- Types: chỉ ra kiểu dữ liệu cho các thông điệp gửi và nhận

- Messages: là một thành phần trừu tượng mô tả cách thức giao tiếp giữa máy khách và máy chủ

- Porttypes: mô tả ánh xạ giữa các thông điệp, được mô tả trong phần tử messages và các phương thức (operations)

- Binding: xác định giao thức nào được sử dụng khi giao tiếp với dịch

vụ web, định nghĩa kiểu binding và giao thức vận chuyển binding cũng định nghĩa các

- operations

- Port: chỉ định địa chỉ và cổng kết nối tới dịch vụ web, thường là một địa chỉ URL đơn giản

1.2.4 Khái niệm UDDI

UDDI (Universal Description, Discovery và Integration) cũng được Microsoft, IBM và Ariba đề xuất năm 2000 Ngày nay UDDI thuộc quyền sở hữu và phát triển của tổ chức OASIS (Organization for the Advancement of Structured Information Standards) UDDI được xây dựng nhằm mục đính cung cấp khả năng cho phép công bố, tổng hợp và tìm kiếm các dịch vụ web UDDI đưa ra một tập hợp các hàm API được chia làm 2 phần: Inquiry API, dùng để tìm kiếm và truy xuất các dịch vụ web đã đăng ký và Publisher ‘s API, dùng để công bố các dịch vụ web muốn đăng ký Thông tin tổ chức trong UDDI được chia làm 3 phần:

- White pages: liệt kê thông tin của các nhà cung cấp dịch vụ web, bao gồm địa chỉ, thông tin liên lạc và định danh

- Yellow pages: phân loại dịch vụ theo tổ chức hay nhóm dịch vụ hoặc địa điểm đặt các dịch vụ

- Green pages: cung cấp thông tin về các dịch vụ web, cách thức truy cập cũng như tương tác với các dịch vụ web đó

1.3 XML-RPC

XML-RPC được kế thừa từ RPC và World Wide Web, sử dụng lại ý tưởng

và nền tảng về việc tạo ra sự giao tiếp giữa con người với nhau để hỗ trợ việc giao tiếp giữa các chương trình trên máy tính Mặc dù web là công cụ giao tiếp giữa con người với con người, sau đó được tiến hóa một cách tinh tế để làm công cụ giao tiếp giữa con người và máy tính, cuối cùng chuyển sang dạng truyền thông phức tạp giữa máy tính và máy tính

HTML thực sự đã rất thành công, nhưng thực tế mới chỉ hữu ích cho các giao dịch hiển thị thông tin cho con người Vì lý do đó, W3C tổ chức phát triển eXtensible Markup Language (XML), một ngôn ngữ đánh dấu cung cấp linh hoạt hơn HTML về việc giao tiếp giữa các chương trình XML được truyền giữa các máy tính sử dụng giao thức HTTP thông qua RPC, sử dụng HTTP có nghĩa là các yêu cầu XML-RPC phải được đồng bộ và phi trạng thái, một yêu cầu XML-RPC luôn luôn có một trả lời XML-RPC tương ứng, bởi vì yêu cầu và trả lời đều phải

xảy ra trên cùng một kết nối HTTP XML cũng có khả năng thực thi hệ thống không đồng bộ, nhưng trong nhiều trường hợp chi phí để tạo ra hệ thống đó là điều không thể Nói chung các yêu cầu không đồng bộ có khả năng thực hiện nhiều yêu cầu của tiến trình hơn

Phi trạng thái (stateless) có nghĩa là không có nội dung được hiểu từ yêu cầu này đến yêu cầu tiếp theo Bản thân XML-RPC cũng không có cách khác là xem chúng như hai yêu cầu riêng biệt không liên quan đến nhau Điều này nhiều khi có thể tránh được các chi phí lớn liên quan đến việc bảo trì hệ thống XML-RPC không cung cấp hỗ trợ duy trì trạng thái, nhưng với một hệ thống với statefull thì XML-RPC có thể thực hiện hỗ trỡ duy trì trạng thái

Với các điểm chính về công nghệ liên quan đến XML-RPC như trên thì XML-RPC có các nhược điểm như sau:

- Một yêu cầu XML-RPC bao gồm hành động để thực hiện và các tham số của hành động đó trong yêu cầu gửi lên HTTP khi mà HTTP đã sẵn sàng đáp ứng yêu cầu và trả lời yêu cầu

- Một API XML-RPC thì cần phải định nghĩa mã lỗi riêng của nó, khi đó

sẽ dễ dàng sử dụng trạng thái mã lỗi hơn

- Với kiểu API sử dụng XML-RPC thì các chức năng về xác thực và cache bên phía máy khách không thể thực hiện được trong hệ thống này

Một giải pháp mới có thế thay thế XML-RPC để khắc phục các nhược điểm của XMLRPC đó chính là dịch vụ RESTful Chúng ta sẽ tìm hiểu dịch vụ này chi tiết hơn trong chương 2 và chương 3 để có thể hiểu REST được thay thế XML-RPC như thế nào

1.4 Khái niệm REST

Những khái niệm đầu tiên về REST ( REpresentational State Transfer) được đưa ra vào năm 2000 trong luận văn tiến sĩ của Roy Thomas Fielding (đồng sáng lập giao thức HTTP) Trong luận văn ông giới thiệu khá chi tiết về các ràng buộc, quy ước cũng như cách thức thực hiện với hệ thống để có được một hệ thống REST

REST (Representational State Transfer) là một kiểu kiến trúc được định nghĩa bởi Roy Fielding [15] Mục đính của REST là thiết kế các ứng dụng mạng

phân tán sử dụng HTTP như là một giao thức tầng ứng dụng và nó là một mô hình kiến trúc thực sự cho web

REST định nghĩa các quy tắc kiến trúc để bạn thiết kế Web services, chú trọng vào tài nguyên hệ thống, bao gồm các trạng thái tài nguyên được định dạng như thế nào và được truyền tải qua HTTP, và được viết bởi nhiều ngôn ngữ khác nhau Nếu tính theo số dịch vụ mạng sử dụng, REST đã nổi lên trong vài năm qua như là một mô hình thiết kế dịch vụ chiếm ưu thế Trong thực tế, REST đã có những ảnh hưởng lớn và gần như thay thế SOAP và WSDL vì nó đơn giản và dễ sử dụng hơn rất nhiều

REST là một bộ quy tắc để tạo ra một ứng dụng Web Service, mà nó tuân thủ 4 nguyên tắc thiết kế cơ bản sau:

- Sử dụng các phương thức HTTP một cách rõ ràng

- Phi trạng thái

- Hiển thị cấu trúc thư mục như các URls

- Truyền tải JavaScript Object Notation (JSON), XML hoặc cả hai

1.5 Nguyên tắc của REST

Như một hệ quả tất yếu của quá trình phức tạp ngày càng lớn của các dịch vụ web lớn nên RESTful đã được đưa ra như là một giải pháp để thay thế việc thực hiện triệu gọi từ xa (RPC) thông qua web

Web dựa vào tài nguyên, nhưng các dịch vụ web lớn lại không dựa vào tài nguyên Web dựa vào URI và liên kết nhưng các dịch vụ web lớn lại không dựa vào chúng Web dựa vào HTTP và các tính năng của nó, nhưng các dịch vụ web hầu như không dựa vào bất kỳ tính năng nào của HTTP Vấn đề này không phải là các dịch vụ web lớn không nhận ra mà nó cảm thấy không nhận được lợi ích gì từ dịch

vụ web hướng tài nguyên Chúng không có khả năng đánh địa chỉ, không cache, kết nối không tốt Chúng cũng không cần giao diện đồng nhất Chúng không được rõ ràng, hiểu được một vấn đề không giúp mình hiểu được vấn đề tiếp theo, trong thực

tế chúng cũng có vấn đề khi tương tác với nhiều khách hàng cùng một lúc

REST là một kiểu kiến trúc cho hệ thống phân tán như World Wide Web Để thực thi kiến trúc RESTful ta cần phải tuân thủ theo hướng dẫn của ROA, kiến trúc

hướng tài nguyên, trong tài liệu này sẽ có các quy tắc cho phép ta thiết kế dịch vụ RESTful [15]

Kiến trúc REST cũng phải dựa vào các nguyên tắc [14,15,16] như mô tả trong các tài liệu, đó là Tài nguyên(Resources), Khả năng đánh địa chỉ(Addressability), Phi trạng thái(Statelessness), Kết nối(Connectedness), Giao diện đồng nhất(Uniform Interface) và Khả năng lưu cache(Cacheability)

Mọi thứ mà dịch vụ cung cấp đều là tài nguyên như khách hàng, xe hơi, tranh ảnh, giọng nói, cửa hàng thương mại điện tử,v.v… tài nguyên có thể là một đối tượng vật lý cũng có thể là một khái niệm trừu tượng nào đó Mọi tài nguyên đều có duy nhất một URI(với một mã duy nhất) Nếu một thông tin nào

đó không có URI thì nó không phải là tài nguyên và không tồn tại trên mạng

Hai tài nguyên không thể có cùng một URI (xem hình 1.5) nhưng hai URI có thể trỏ vào cùng một tài nguyên vào cùng một thời điểm (xem hình 1.6)

Ví dụ chúng ta có một URI xác định http://server/last_version và một URI xác định một tài nguyên khác http://server/last_version_1.3, khi last_version hiện tại

là phiên bản 1.3 thì cả hai URI đều cùng trỏ vào một tài nguyên Sau một thời gian thì last_version lên phiên bản mới là 1.4, lúc đó hai URI này sẽ trỏ vào hai tài nguyên khác nhau

Hình 1.6: Hai URI cùng trỏ đến một tài nguyên

1.5.2 Khả năng đánh địa chỉ

Mọi tài nguyên đều được đánh địa chỉ, mỗi tài nguyên đều được đánh địa chỉ có nghĩa là sẽ có đủ URI để đánh địa chỉ cho mọi tài nguyên, với khả năng đánh địa chỉ chúng ta có thể lưu lại các trang thông tin cần thiết, cũng có thể gửi URI này tới người khác như là một tài nguyên, đặc biệt với khả năng lưu cache, thì tài nguyên được lưu ở máy khách, sau lần truy cập đầu tiên thì tài nguyên sẽ được truy cập ở máy khách

Chúng ta cùng xem xét qua ứng dụng của Google Maps, vào ứng dụng Google Maps chúng ta gõ “Nguyễn Trãi, Hanoi, Vietnam” hệ thống Google Maps sẽ hiện thị ra một số địa chỉ mà liên quan đến từ khóa ta vừa gõ, ta thấy URI của site http://maps.google.com/ không thay đổi, điều đó có nghĩa là không phải Google Maps không có khả năng đánh địa chỉ, có nghĩa rằng ứng dụng web

mà chúng ta đang sử dụng thì không có khả năng đánh địa chỉ mà cái khả năng đánh địa chỉ chính là dịch vụ web Nếu chúng ra muốn gửi thông tin bản đồ này cho người khác thì chúng ta cần yêu cầu ứng dụng một URI mà có thể gửi cho người khác mà vẫn xem được đúng hình ảnh bản đồ mà mình đang xem Nếu không có khả năng đánh địa chỉ thì chúng ta không thể cho người khác xem bản

đồ mà mình đang xem

Hình 1.7: Minh họa việc gửi địa chỉ

1.5.3 Phi trạng thái

Mọi yêu cầu HTTP đều hoàn thành một cách riêng biệt nhau Có nghĩa rằng khi ở máy khách tạo một yêu cầu HTTP thì tất cả các thông tin trong yêu cầu đó phải được đệ trình lên máy chủ Dịch vụ thường không dựa vào thông tin của các yêu cầu trước Nếu máy chủ yêu cầu dữ liệu của yêu cầu trước thì máy khách phải gửi lại thông tin đó xem như là một yêu cầu mới, máy chủ không giữ bất kỳ thông tin gì của máy khách cả Điều này làm cho hệ thống đáng tin cậy hơn, đơn giản hơn và khả năng mở rộng lớn hơn Một máy khách thực hiện yêu cầu đến máy chủ A, một máy khách khác thực hiện một yêu cầu khác tới máy chủ A, vào thời điểm đó máy chủ A lỗi thì nột máy chủ khác được thay để xử lý các yêu cầu mà máy khách đã gửi, điều này có nghĩa là máy chủ web được thay thế một cách dễ dàng và làm cho hệ thống có khả năng thay đổi, đặc biệt nếu trong hệ thống có sự cân bằng tải thì máy chủ sẽ phục vụ tốt hơn đối với các người dùng mà đã yêu cầu trước đó, với cân bằng tải này thì hệ thống sẽ trở nên đơn giản hơn để thực hiện

Hình 1.8: Sự liên kết giữa các máy khách

GET là phương thức an toàn và không thay đổi An toàn ở đây có nghĩa

là nó không làm thay đổi trạng thái của máy chủ, nó chỉ nhận thông tin thôi nên

nó không làm ảnh hưởng gì đến máy chủ, không thay đổi ở đây có nghĩa là có thể nhiều yêu cầu giống hệt nhau mà có thể cho kết quả như nhau Từ khi giao thức HTTP là một giao thức phi trạng thái thì cũng được quy định là an toàn và không đổi Sử dụng tính chất không đổi cho phép GET lấy lại tài nguyên lặp nếu gặp lỗi

Nếu yêu cầu thành công và kết quả là một tài nguyên được trả về thì thông điệp trạng thái trả về phù hợp với yêu cầu đó là 200 (thành công) Nếu tài nguyên không tồn tại thì trạng thái trả về là 404 (không thành công, tài nguyên không tìm thấy)

Nếu thông điệp yêu cầu có chứa cả các trường phạm vi, điều kiện thì ngữ nghĩa của phương thức GET có thay đổi một chút Phương thức này giảm thiểu

sự sử dụng mạng không cần thiết bằng cách cho phép nhận một phần thông tin

để hoàn thành phương thức GET mà không cần phải chuyển hết dữ liệu mà máy khách đang giữ

nguyên mới thì trạng thái trả về là 201 (tạo tài nguyên mới) và chứa đựng thông tin mô tả trạng thái của yêu cầu và tham chiếu tới tài nguyên mới ở phần header của thông tin

Phương thức POST và PUT trông có vẽ giống nhau, tuy nhiên chúng khác nhau về mặt ý nghĩa trong các yêu cầu của chúng, trong phương thức PUT thì URI định nghĩa các thực thể đính kèm với yêu cầu (ở máy khách đã chỉ ra ID của tài nguyên trong URI đó) Ngược lại trong phương thức POST trong URI yêu cầu định nghĩa tài nguyên mà sẽ điều khiển thực thể kèm theo Hơn nữa PUT là một phương thức không thay đổi (giống như GET) nhưng POST thì ngược lại

HTTP DELETE

Phương thức DELETE yêu cầu máy chủ xóa tài nguyên được xác định trong yêu cầu, nó cũng là một phương thức không thay đổi như phương thức GET và PUT Nếu xóa thành công thì mã trạng thái 200 (thành công) sẽ được trả

về, ngược lại nếu không thành công thì một trạng thái mã lỗi tương ứng sẽ được trả về một cách phù hợp

1.5.6 Khả năng lưu cache

Tài nguyên thì nên được cache lại đâu đó trên máy khách với một điều kiện và một khoảng thời gian nào đó Cơ chế cache thì làm cho người dùng có thể tải tài nguyên tốt hơn, nhanh hơn, có thể giảm tải được cho máy chủ về cả

mặt thời gian và lưu lượng Có hai cơ chế cache trong HTTP đó chính là thời hạn và xác thực Theo RFC2616 [9] thì mục tiêu của cache trong HTTP/1.1 đó

là trong nhiều trường hợp loại trừ khả năng gửi yêu cầu đến máy chủ, giảm thiểu

số lượng yêu cầu vào trong qua mạng, cũng loại trừ khả năng gửi kết quả trả lại trong nhiều trường hợp khác, điều này cũng giảm thiểu được băng thông trên máy chủ, nếu các yêu cầu cũ thì thông qua cơ chế thời hạn, nếu các yêu cầu là mới thì thông qua cơ chế xác nhận Phương thức POST thì không có khả năng cache nếu không có sự điều khiển cache phù hợp, phương thức GET được thiết kết là có ý định cho phép cache

Điều khiển cache ở header

Trong HTTP/1.1 có thể thay thế thời hạn ở header bằng cách điều khiển cache ở header, để giải quyết vấn đề đồng bộ của máy chủ và máy khách, làm cho khả năng cache linh hoạt hơn Điều khiển cache ở header có một tập các mệnh đề điều kiện, được dùng để điều khiển máy khách cache tài nguyên như thế nào [11]

tích hợp trực tiếp vào web hơn là tập trung vào các chức năng Dịch vụ RESTful sử dụng tài nguyên web như là các khái niệm trừu tượng chính [13,10]

Dịch vụ RESTful có rất nhiều lợi thế mà web đã đưa ra, các lợi thế có thể kể

ra như sau:

- Các kiểu dữ liệu chuẩn và phổ biến được sử dụng để mô tả dữ liệu, các loại

dữ liệu này cũng được dùng để mô tả tài nguyên ở phía máy khách tùy theo yêu cầu của máy khách, ví dụ kết quả dữ liệu thống kê thì có thể được cung cấp trong HTML cho người dùng có thể đọc được, trong khi đó ở một số máy khách thì có thể áp dụng vào excel để tính toán dữ liệu

- Giao diện đồng nhất được cung cấp từ khi phương thức HTTP chuẩn được sử dụng

- Thực sự độc lập ngôn ngữ

- Khi sử dụng HTTP thì vượt qua tường lửa không phải là vấn đề

- Lưu cache có thể làm tăng khả năng thực hiện

- HTTP được sử dụng trong tầng ứng dụng, bởi vậy tất cả các tính năng chuẩn của HTTP được kết thừa vào trong dịch vụ RESTful, các tính năng quan trọng như mã hóa, xác thực và cache

Các vấn đề thuận lợi này được cung cấp phổ biến trong dịch vụ web 2.0 để phát triển dịch vụ RESTful như Yahoo, Amazon, Flickr

1.7 So sánh SOAP và RESTful

- Tiêu chuẩn hoá

- Cung cấp khả năng mở rộng đáng kể trước khi xây dựng dưới dạng các tiêu chuẩn WS *

- Tích hợp xử lý lỗi

- Tự động hóa khi sử dụng với một số sản phẩm ngôn ngữ

Bên cạnh đó, REST dễ sử dụng hơn và linh hoạt hơn Nó có những lợi thế sau khi so sánh với SOAP:

- Không có tools đắt tiền nào yêu cầu tương tác với Web service

- Smaller learning curve

- Hiệu quả (SOAP sử dụng XML cho tất cả các truyền tin, REST có thể

sử dụng định dạng truyền tin ngắn gọn hơn)

- Nhanh (không yêu cầu xử lý rộng rãi)

- Gần gũi hơn với các công nghệ Web khác trong triết lý design

STT SOAP REST

1 SOAP là một giao thức REST là một kiểu kiến trúc

2 SOAP là viết tắt của Simple Object

Access Protocol

REST của viết tắt của

Representational State Transfer

3 SOAP không thể sử dụng REST bởi vì

5 JAX-WS theo giao thức SOAP JAX-RS theo kiến trúc RESTful

6 SOAP được định nghĩa tiêu chuẩn REST của không định nghĩa tiêu

chuẩn quá nhiều như SOAP

7 SOAP đòi hỏi nhiều băng thông và tài

nguyên hơn REST

REST đòi hỏi ít băng thông và tài

nguyên hơn SOAP

8 SOAP định nghĩa chuẩn bảo mật riêng REST kế thừa chuẩn bảo mật của

KẾT LUẬN CHƯƠNG

Với các nguyên tắc và các lợi ích như đã trình bày ở trên mà REST có thể đưa lại thì có thể đưa ra một số lý do chọn REST như sau:

- Thứ nhất, mỗi đối tượng vật lý hoặc khái niệm trừu tượng đều có thể xem

như một tài nguyên duy nhất, điều này có nghĩa rằng chúng sẽ được truy cập nhanh chỉ với một yêu cầu duy nhất ngay sau khi chúng được xác định, với điều này thì cũng tạo dễ dàng cho người dùng và giảm tải cho máy chủ nếu như tài nguyên chỉ truy cập với một yêu cầu duy nhất

- Thứ hai, với nguyên tắc phi trạng thái thì REST làm cho hệ thống linh động

tốt hơn khi mà máy chủ không bắt được thông tin của máy khách, điều này

có nghĩa rằng các máy chủ được kết nối với hệ thống đều có thể nhận bất kỳ yêu cầu nào từ máy khách và trả lời máy khách một cách phù hợp Các ảnh hưởng khác của nguyên tắc này đó là cân bằng tải phức tạp không cần thiết

và máy khách đang sử dụng hệ thống mà máy chủ bị mất kết nối thì máy chủ cũng không phải thông báo cho máy khách và xem đó là lỗi của hệ thống

- Thứ ba, nếu dịch vụ không theo RESTful thì các dịch vụ rất khó để có thể

liên kết với nhau vì các tài nguyên không có khả năng đánh địa chỉ, chúng không kết nối được với nhau, các phương thức của HTTP sử dụng trong mỗi yêu cầu không theo một mẫu chuẩn Theo kiểu kiến trúc REST thì máy khách có thể đoán được giao diện tương tác được thiết kế như thế nào và kết nối trực tiếp với thông tin cần thiết sử dụng URI chỉ định hoặc điều hướng qua đại diện sử dụng các liên kết

- Thứ tư, khả năng lưu cache có thể dễ dàng sử dụng, làm giảm tải cho máy

chủ và cải thiện thời gian cho máy khách Với các lợi ích như trên thì REST

là một kiểu kiến trúc thú vị và hấp dẫn, rất đáng để sử dụng vì nó có thể cải thiện dịch vụ theo nhiều cách có thể

CHƯƠNG 2: VẤN ĐỀ BẢO MẬT VỚI WEB SERVICE DỊCH

VỤ RESTFUL 2.1 Vấn đề an toàn bảo mật Web Service

Từ những giai đoạn đầu tiên của Internet, các doanh nghiệp luôn đòi hỏi rất khắt khe về vấn đề bảo mật trong thương mại điện tử Những hạn chế của tường lửa như việc giám sát các gói tin được truyền tải dựa trên giao thức HTTP là chưa có; điều này có thể khiến cho máy chủ có nguy cơ bị những cuộc tấn công không hề biết được biết trước Đã có rất nhiều các thuật toán đưa ra cơ chế và những chuẩn về bảo mật như sự mã hoá khoá thông tin, chữ ký số …; nhưng hầu hết chỉ tập trung vào việc đưa ra các định dạng bảo về dữ liệu trong quá trình trao đổi, không quan tâm đến việc xác định các nghi thức mà các bên cần thực hiện khi tương tác với nhau

Ngoài ra, những chuẩn chung về việc chỉ ra nghi thức giao tiếp giữa Web Service là chưa có, đã khiến cho các sản phẩm hỗ trợ bảo mật của Web Service không thể tích hợp với nhau, mặc dù các sản phầm này đều được thiết kế dựa trên chuẩn về bảo mật cho web service

Một chuẩn an toàn chung cho các hệ thống giao dịch trên mạng thường phải tập trung vào những điều sau [1], [2]:

- Identification: định danh được những ai truy cập tài nguyên hệ thống

- Authentication: chứng thực truy cập tài nguyên của người muốn sử dụng

- Authorization: cho phép giao dịch khi đã xác nhận định danh người truy cập

- Integrity: toàn vẹn thông tin trên đường truyền

- Confidentiality: độ an toàn, không ai có thể đọc thông tin trên đường đi

- Auditing: kiểm tra, tất cả các giao dịch đều được lưu lại để kiểm tra

- Non-repudiation: độ mềm dẻo, cho phép chứng thực hợp tính hợp pháp hóa của thông tin đến từ một phía thứ ba ngoài hai phía là người gửi và người nhận

2.1.1 Bảo mật Web Service

2.1.1.1 Khái niệm về Web Service Security

Web Service Security là một chuẩn an toàn cho SOAP và cả những phần mở rộng của SOAP, nó được dùng khi muốn xây dựng những web service toàn vẹn

và tin cậy Web Service Security đảm bảo cho tính an toàn tin cậy của thông điệp[3]

2.1.1.2 Các yêu cầu tạo ra sự an toàn thông tin trong một ứng dụng

- Chỉ rõ một khóa để duyệt chữ kts của thông điệp đến xem có hợp lệ hay không

- Chỉ rõ giải thuật mà khóa sử dụng để bảo đảm toàn vẹn dữ liệu của thông điệp gửi đến

- Thông điệp phản hổi phải được ký và cung cấp thông tin chữ ký khi phản hồi

2.1.2 Một số kỹ thuật Web Service Security

- eXtensible Access Control Markup Language (XACML)

- Security Assertion Markup Language (SAML)

- XML Key Management Specification (XKMS)

- Web Services Policy Framework (WS-Policy)

- eXentisble Rights Markup Language (XrML)

- Secure Socket Layer (SSL)

2.1.2.1 eXtensible Access Control Markup Language (XACML)

Tổng quan XACML

Các chính sách điều khiển truy cập rất phức tạp và phải được thi hành tại nhiều điểm Trong một môi trường phân phối, ví dụ như thiết lập một dịch vụ web, thực hiện các chính sách điều khiển truy cập bằng cách cấu

hình chúng tại mỗi điểm, khiến cho các chính sách trở nên đắt tiền và không đáng tin cậy Hơn nữa, các chính sách điểu khiển truy cập thường được thể hiện thông qua các ngôn ngữ độc quyền và khác nhau XACML được hình thành để giải quyết vấn đè này, bằng cách cung cấp một tiêu chuẩn, ngôn ngữ duy nhất để xác định các chính sách điều khiển truy cập XACML phiên bản 2.0 đã được chấp nhận như một tiêu chuẩn OASIS cùng với sáu cấu hình của XACML: SAML 2.0, XML Digital Signature, Privacy Policy (chính sách bảo mật), Hierarchical Resource (phân cấp tài nguyên) và RBAC (Role-Based Access Control) XACML là một tiêu chuẩn bổ sung của OASIS để đưa ra các quyết định việc điều khiển truy cập

XACML được thực hiện trong XML Các đối tượng của XACML được dùng để tạo ra một tiêu chuẩn cho việc miêu tả các thực thể điều khiển truy cập và các thuộc tính của chúng Chúng đề nghị nhiều các điểu khiển truy cập hơn việc từ chối và cấp quyền truy cập

Mô hình của XACML

PIP: Policy Information Point: Là nguồn gốc của các giá trị thuộc tính hoặc các dữ liệu cần thiết để đánh giá chính sách

Context Handler: Xác định để chuyển đổi các yêu cầu theo định dạng gốc của nó với hình thức XACML và chuyển đổi các quyết định ủy quyền theo hình thức XACML sang định dạng gốc

Các chính sách XACML sẽ được nạp vào PAP, tại đây các chính sách

sẽ được gửi tiếp tới PDP PDP là điểm quyết định sẽ sử dụng chính sách nào cho các yêu cầu truy cập Khi có một yêu cầu truy cập được gửi tới PEP, nó

sẽ tiếp nhận các yêu cầu và thực hiện chúng bằng cách yêu cầu tới các văn bản xử lý Các văn bản này lại được gửi yêu cầu tới PDP, tại đây các yêu cầu được xử lý và sau đó được gửi phản hồi lại cho Context Handler Và tiếp tục gửi lại cho PEP – nơi thực hiện các chính sáchh sau khi đã qua quá trình xử

lý và thực hiện tại PDP Sau khi thực thi các chính sách PEP sẽ gửi các chính sách tới các Máy chủ chứng thực và tạo ra các tài nguyên để chia sẻ Các tài nguyên này kết hợp cùng với PIP được lưu trữ trở lại cho Context Handler phục vụ cho những yêu cầu lần sau

Các XACML Context Handler sẽ cách ly và xử lý các ứng dụng cho các đầu vào và đầu ra sử dụng PDP Trong thực tế, đó là các Context Handler dùng để dịch các yêu cầu về truy cập ứng dụng từ định dạng ban đầu của nó sang định dạng theo chuẩn trên Mấu chốt XACML là xác định các cú pháp cho một ngôn ngữ chính sách bất kỳ, ngữ nghĩa cho các quy tắc chính sách và giao thức nhằm đáp ứng các yêu cầu giữa PEP và PDP

2.1.2.2 Security Assertion Markup Language (SAML)

SAML là sự kết hợp giữa S2ML và AuthML, được phát triển thông qua OASIS SAML là một tiêu chuẩn dựa trên XML, được hình thành như một khuôn khổ cho việc trao đổi thông tin liên quan đến an ninh, thể hiện dưới các xác nhận và sự tin tưởng giữa các bên tham gia trao đổi, nhằm xác thực giao tiếp người dùng, quyền lợi và các thuộc tính thông tin

Hoạt động của SAML

Hỗ trợ việc khẳng định các chứng thực gốc duy nhất giữa các domain với nhau Việc khẳng định có thể truyền đạt thông tin về các thuộc tính của đối tượng và có thể quyết định ủy quyền cho đối tượng được phép truy cập tài nguyên nhất định

- Xác thực tin tưởng

- Chứng thực các vấn đề liên Domain

- Tập trung các vấn đề xác thực liên SAML hỗ trợ ba loại hình xác nhận:

o Xác thực: Các đối tượng quy định được chứng thực tại thời điểm cụ thể

o Thuộc tính: Các đối tượng quy định có liên quan tới thuộc tính được cung cấp

o Quyết định ủy quyền: một yêu cầu cho phép đối tượng quy định để truy cập vào tài nguyên quy định đã được cấp hoặc từ chối

Đặc điểm của SAML

Một SAML duy nhất khẳng định có thể chứa một số báo cáo khẳng định về chứng thực, ủy quyền và các thuộc tính Khẳng định là do cơ quan SAML, cụ thể là cơ quan thẩm định, cơ quan thuộc tính, hoặc là một điểm quyết định chính sách.Tuy nhiên, nó không cung cấp cơ chế để kiểm tra, thu hồi chứng trỉ SAML cung cấp bối cảnh chứng thực, được truyền đạt (hoặc tham chiếu) một sự khẳng định của chứng thực đó Khuôn khổ quy định của SAML là nhằm hỗ trợ nhiều tình huống kinh doanh thực trên thế giới, từ những người mà trong đó khách hàng là một trình duyệt để thêm những phần phức tạp nơi mà Web Service có liên quan Bảo mật thông tin SOAP, khẳng

định SAML có thể được sử dụng trong thông điệp SOAP để thực hiện vấn đề

an ninh và nhận dạng thông tin giữa các hành động 48 trong giao dịch.Các SAML Token của tổ chức WSS OASIS quy định cách xác nhận SAML nên được sử dụng cho mục đích này The Liberty Alliance’s Identity Web Service Frameword (ID-WSF) cũng sử dụng SAML xác nhận như là thẻ an ninh cơ sở để cho phép việc an toàn và tôn trọng sự riêng tư khi tiếp cận với các Web Service

2.1.2.2 XML Key Management Specification (XKMS)

Các khóa công cộng là các khối cơ bản xây dựng cho chữ ký và chứng nhân kỹ thuật số Khóa công khai quản lý bao gồm việc tạo ra, lưu trữ an toàn, phân phối, sử dụng và hủy bọ chúng Các khóa công cộng có thể được tạo ra bởi một gói phần mềm chạy trên nền tảng của các ứng dụng khách hàng và sau đó đăng ký một khóa cơ sở hạ tầng công cộng , chứng nhận ủy quyền hoặc ứng dụng khách hàng có thể yêu cầu một chứng nhận tham gia đến một cơ sở hạ tầng để tạo ra các khóa này Khi một bên sử dụng một khóa công khai, nó có nhu cầu để xác định tính hợp lệ của nó, nghĩa là, nó cần phải xác minh các khóa công cộng chưa hết hạn hoặc đã bị thu hồi bởi nhà cung cấp Web Service Khóa công cộng có thể được cấp bằng nhiều cách khác nhau, có thể có nhiều hơn một khóa công khai liên quan tới khóa công cộng Tuy nhiên, các khóa cơ sở hiện nay dựa trên bộ công cụ độc quyền, làm cho tương tác giữa các ứng dụng khách hàng và các hạ tầng trờ nên tốn kém và khó khăn hơn Hơn nữa, các ứng dụng khách hàng phải tự thực hiện rất tốn kém các hoạt động như xác nhận chữ ký, xác nhận dây chuyền và kiểm tra thu hồi Do đó cần phải đơn giản hóa các nhiệm vụ của các bên khi chúng ta công khai khóa công cộng, cũng như cho phép các chứng thực khác nhau, hoặc thậm chí khóa khác nhau Hơn nữa, các khóa công cộng có thể được đại diện trong XML, và là cơ sở của XML Encryption và XML chữ ký Những vấn đề mô tả ở trên đã dẫn đến việc định nghĩa các chuẩn đối với XML Key Management [19] Hơn nữa,WS-Security xác định các cơ chế cơ bản cho việc cung cấp thông điệp an toàn, thông điệp SOAP được bảo vệ bởi

WS-Security trình bày ba vấn đề chính đó là: tính không tương thích định dạng bảo mật thẻ;sự khác biệt không gian tên và sự tin cậy an ninh thẻ Để khắc phục những vấn đề trên, cần thiết phải xác định tiêu chuẩn mở rộng để WS-Security cung cấp các phương pháp nhằm đưa ra, đổi mới và xác nhận thẻ bảo mật và để thiết lập và đánh giá sự xuất hiện, mối quan hệ tin tưởng lẫn nhau XKMS là một giao thức được phát triển bởi W3C để mô tả sự phân phối và đăng ký khóa công cộng, nó làm giảm các ứng dụng phức tạp cú pháp của nền tảng được sử dụng để thiết lập các mối quan hệ tin tưởng

Trong hình vẽ sau, một dịch vụ X-KISS cung cấp cho khách hàng hai chức năng và có thể thực hiện bởi chính các dịch vụ X-KISS hoặc của một khóa cơ sở cơ bản Đó là chức năng: xác định ví trí và tính xác thực Đối với mục đích mã hóa, các chức năng cho phép một người gửi không cần biết chính xác liên kết với người nhận để có được thông điệp đó Các dịch vụ X-KISS không thực hiện bất kỳ sự khẳng định về tính hợp lệ của các liên kết giữa dữ liệu và khóa[7]

Đối với việc xác thực của một khóa, những thông tin được cung cấp bởi người ký có thể là chưa đủ cho người nhận có thể thực hiện việc xác minh mật mã và quyết định có nên tin tưởng vào khóa ký kết này hay không, hoặc là các thông tin không thể thực thi trong một định dạng người nhận có thể sử dụng được Các chức năng xác nhận cho phép các khách hàng để có được từ các dịch vụ X-KISS một sự khẳng định rõ ràng, đó là hiệu lực của sự ràng buộc giữa các khóa và các dữ liệu công cộng, ví dụ: một danh từ hoặc một tập hợp các thuộc tính mở rộng Hơn nữa, các dịch vụ X-KISS đại diện cho tất cả các yếu tố dữ liệu mà được liên kết với cùng một khóa công khai XKRSS định nghĩa một giao thức cho việc đăng ký và quản lý các khóa thông tin quan trọng Bạn có thể đăng ký các khóa với một dịch vụ XKMS bằng cách sau: Các dịch vụ XKMS tạo ra một cặp khóa cho khách hàng và đăng ký các khóa công khai của chính cặp khóa đó và gửi các khóa riêng của cặp khóa này cho khách hàng của mình sử dụng chúng Các khách hàng cũng