Cơ chế xác thực cải tiến từ Oauth đã được phát triển và sử dụng thí điểm cho 3 bài toán trong hệ thống phần mềm quản lý viễn thông. Tuy nhiên, trong tương lai, hệ thống mở rộng môi trường làm việc trên các thiết bị di động. Đây là một môi trường có đặc thù riêng, không giống môi trường ứng dụng trên desktop. Trong quá trình phát triển chúng tôi đã gặp phải một số vấn đề phức tạp cần giải quyết.
Có 3 vấn đề chính nổi lên khi ta bắt đầu phát triển ứng dụng với các thiết bị di động (ở đây ta xét tới các thiết bị di động sử dụng nền tảng hệ điều hành Android):
Vấn đề thứ nhất:
Các yêu cầu theo giao thức HTTP không được chứng thực, vậy bằng cách nào ta biết được những yêu cầu này được gửi từ một user nào đó?
Nếu đưa trực tiếp username và password trong HTTP request thì không an toàn. Để giải quyết vấn đề này, Twitter sử dụng OAuth để xác thực yêu cầu của người dùng tới dịch vụ. Tương tự như vậy Yahoo sử dụng OpenId cho cùng mục đích này.
Nhưng cả 3 giải pháp OAuth và OpenId đều không khả thi với bài toán hiện tại vì nó quá phức tạp.
53
Ví dụ như giải pháp OAuth, giải pháp này cần tới 2 bước để truy cập vào token Theo quy trình xử lý trên, User sẽ bị redirect từ ứng dụng hiện tại tới trình duyệt để cấp xác thực cho ứng dụng đó sau đó lại redirect lại. Nếu trường hợp là trên trình duyệt máy tính, điều này là hợp lý .Nhưng khi xử lý trên môi trường các thiết bị di động, nơi tốc độ truy cập mạng thường bị giới hạn điều nay sẽ ảnh hưởng rất lớn tới trải nghiệm của người dùng. Đây là vấn đề quan trọng yêu cầu phải giải quyết.
Vấn đề thứ hai:
Các URL của dịch vụ WCF thường không đủ tường minh cho các lập trình viên di động sử dụng. Chúng ta cần phải làm tất cả các dịch vụ WCF minh bạch hơn, từ đó các lập trình viên di động có thể sử dụng nó như các phương thức cục bộ. Điều này sẽ làm cho việc phối hợp nhóm thuận tiện hơn và đảm bảo duy trì các dịch vụ mở.
Vấn đề thứ ba:
Trong vấn đề xác thực User, mặc dù nền tảng .Net đã hỗ trợ các giải pháp xác thực như: Windows User Authentication, X509 certificate, Issued Token, vv.. Vẫn chưa có giải pháp nào phù hợp hoàn toàn với các ứng dụng mobile hoặc chưa mềm dẻo để mở rộng. Các phiên bản trước .WCF 4.0, RequestInterceptor là một giải pháp hoàn hảo tuy nhiên tới WCF 4.0 RequestInterceptor không còn được hỗ trợ.
4.7.Giải pháp XAuth và Service Authorization manager
Để giải quyết 3 vấn đề gặp phải, ta cần phải giải quyết từng vấn đề. Vấn đề đầu tiên, làm thế nào để ta có thể phân biệt các xác thực User?
OAuth quá nặng nề và thường được sử dụng trong môi trường thương mại vì OAuth hầu như phù hợp cho các API từ bên thứ ba.
XAuth kém an toàn hơn nếu sử dụng cho bên thứ ba, nhưng ở hoàn cảnh này, ta đang xây dựng các dịch vụ cho các ứng dụng riêng không có sự tham gia từ bên thứ ba, và trong tương lai cũng vậy. Do vậy, XAuth là sự lựa chọn tốt.
54
Hình 23: Xử lý xác thực theo cơ chế XAuth [4]
Vấn đề thứ hai, REST (Representational State Translate) là một lựa chọn tốt để xây dựng những dịch vụ thỏa mãn cả 2 tiêu chí tường mình và dễ sử dụng. REST là một kiểu kiến trúc để xây dựng những các ứng dụng phân tán lai trong đó bao gồm kiến trúc hướng dịch vụ bằng cách định nghĩa những bộ công cụ sử dụng chuẩn HTTP (GET, POST, PUT, DELETE) và có thể định vị bởi một URL. Và kể từ .Net 3.5, WCF đã hỗ trợ xây dựng kiểu dịch vụ REST.
Vấn đề thứ 3 là về việc Host cho dịch vụ XAuth. ServiceAuthorizationManager là công cụ thích hợp cho yêu cầu này. ServiceAuthorizationManager cung cấp một phương thức là CheckAccessCore, phương thức này hỗ trợ chúng ta can thiệp vào từng lời gọi tới dịch vụ WCF. Mặc dù ServiceAuthorizationManager không được thiết kế dành riêng cho những ứng dụng loại này. Sau khi thực hiện xác thực, chúng ta cần phải đăng ký nó với file cấu hình, sau đó xác thực này sẽ có hiệu lực với tất cả các lời gọi tới dịch vụ.
Hình 24:Cơ chế làm việc của AuthorizationManager [4]