Một thành phần chính của Microsoft.Net là nền tảng tự định danh Windows (Windows Identity Foundation – WIF). Về bản chất, WIF cho phép lập trình viên.Net sử dụng các cơ chế xác thực và định danh ở bên ngoài, bên trong ứng dụng của họ. Điều này nghĩa là khi mô hình xác thực thay đổi, ứng dụng khác của bạn không phải thay đổi theo. Do đó, cho dù là định danh Windows, định danh Live ID (một tài khoản của Microsoft) hay một định danh khác đều không thành vấn đề.
WIF xoay quanh khái niệm định danh dựa tren claim. Các định danh trên claim là một ý tưởng rất đơn giản, xoay quanh một số khái niệm như token (mã) và identity provider (dịch vụ cung cấp định tính).
Hãy dừng việ suy nghĩ về công nghệ để xem xét xem định danh thực là gì. Giả sử bạn đã từng gặp tôi tại một hội nghị trước đây. Rồi vào một ngày đẹp tời, bạn gặp tôi trong tình cảnh vô gia cư và đang phải đi xin ăn. Có lẽ bạn sẽ nhìn vào tôi và cố nhận ra một số đặc điểm riêng mà bạn sẽ cho rằng không thể giả mạo, đó là một số đặc điểm bạn có thể tin tưởng như đôi mắt, chiều cao, giọng nói và bạn kết luận rằng “chắc chắn tôi là người đã gặp là diễn giả về SharePoint”. Những đặc điểm đó cho phép bạn thiết lập một đặc điểm nhận dạng về tôi trong tâm trí bạn. Với đinh danh đó, bạn có thể cho tôi tiền để mua thứ gì đó để ăn. Tuy nhiên, nếu với định danh đó, tôi yêu cầu bạn xuất trình giấy phép lái xe, có lẽ bạn sẽ làm tôi thất vọng. Trừ khi tôi đưa ra được những khai bảo về bản thân mà bạn có thể tin tưởng. Đến lúc đó, tôi sẽ phải củng cố thêm định danh của tôi với bạn bằng cách cung cấp them các khai báo về bản thân theo cách mà bạn có thể tin tưởng. Ngoài ra, khi những nhu cầu và đồi hỏi của tôi thay đổi, bạn có thể yêu cầu tôi khai báo them thông tin. DO đó, định danh của tôi có thể tăng lên khi làm việc qua hệ thống của bạn; đôi khi bạn không thể thực hiện với chỉ một mô hình xác thực thuần túy.
Tuy nhiên trong các trường hợp này, bạn là người yêu cầu các khai báo đồng thời là người xác nhận những khai báo đó. Hãy hình dung một ví dụ mà trong đó, bên kiểm tra khác với bên yêu cầu khai báo. Giả sử tôi bị tạm dừng lưu thông vì lái xe quá tốc độ. Tôi không sinh sống tại địa phương đó, do đó nhiều khả năng tôi phải xuất trình giấy phép lái xe nơi tôi dăng ký cho nhân viên cảnh sát, đó là một định danh để viên cảnh sát đố tin tôi. Hay nói cách khác, cảnh sát ở đó tin tưởng vào nơi cấp giấy phép lái xe của tôi. Trong trường hợp nay, chừng nào viên cảnh sát còn tin rằng cac khai bá của tôi là hợp lệ và không giả mạo, định danh của tôi có thể được củng cố. Đây là ví dụ trong đó bên phụ thuộc, phụ thuộc vào một dịch vụ bảo mật token đẻ cung cấp cho người dùng một số dịch vụ.
Tương tự trong máy tính, chừng nào bạn còn có thể truyền một token tin cậy kèm theo một hoặc nhiều claims để khai báo cho biết bạn là ai, các dịch vụ sẽ cấp cho bạn những quyền truy cập cần thiết. Ngoài ra, vẫn với ứng dụng đó, khi cần thêm các quyền truy cập ở mức độ cao hơn, bạn có thể tiếp tục cung cấp them các claims khác. Những claim này có thể biểu diễn bất cứ điều gì về người dùng. Tuy nhiên trên thực tế, một server có thể yêu cầu chính xác tuổi của người dùng sau đố mới cho phép họ trình bày các claims để khai báo khác, có thể từ cơ quan cấp giấy phép lái xe. Do đó, các claims để khai báo có thể biểu diện khá nhiều thông tin về người dùng và dứng dụng có thể tiếp tục yêu cầu thêm các claims khai báo mà không cần quan tâm tới nguồn gốc của những claims khai báo đó, miễn là chúng không phải giả mạo.
Trong hệ thống máy tính. Cơ chế này hoạt động ra sao? Thông thường, khi người dùng thực hiện mộ tyêu cầu tới server, và nếu server được bảo vệ bởi một số kiểu xác thực, người sử dụng trình duyệt hoặc một client khác được yêu cầu cung cấp một Security Token Service (Dịch vụ cung cấp mã bảo mật - STS) cho một token chứa các claim khai áo về người dùng. Yêu cầu đó được tạo ra bằng cách sử dụng các giao thức WS-Trust chuẩn. Yêu cầu này sẽ được xác thực theo một số phương thức khác nhau, ví dụ như cung cấp một ticker Kerberos hoặc có thể là một mật khẩu. Phương thức xác thực được thực hiện bởi STS sau đó sinh ra token và trả token đó về cho người yêu cầu. Tiếp theo, bên yêu cầu có thể trình token thường được mã hóa dưới hạng Security Assertion Markup Language (SAML) đó cho server cung cấp dịch vụ.
Hãy hình dung nếu site SharePoint được bảo vệ bởi Windows Live ID. Và bạn là một người dung đang cố truy cập vào site SharePoitn đó; SharePoint sẽ thông báo cho trình duyệt của bạn biết loại token mà nó yêu cầu và nơi bạn có thể lấy được token đó. Sau khi được chỉ dẫn, bạn cần tiếp cận STS của Windowns Live ID và cung cấp token đó cho SharePoint để có thể nhận được quyền truy cập tới site SharePoint.
Bây giờ, giả sử site SharePoint chấp nhận hai kiểu claims khai báo. Nó chấp nhận Windows Live ID hoặc định danh Windows (windows indentity). Với cả hai trường hợp, ban sẽ phải truy cạp vào STS phù hợp và cung cấp cho SharePoint định dạng tương ứng. Điều thú vị là ứng dụng thực sự, hay bản thân SharePoint không quan tâm đến việc bạn lấy token nó từ đâu, nếu như SharePoint tin tưởng token đó hợp lệ. Điều này nghĩa là một website có thể hỗ trợ nhiều cơ chế xác thực; giữa các cơ chế xác thực không có sự khác biệt, do đó các ứng dụng như tích hợp client vẫn tiếp tục làm việc mà không cần biết kiểu xác thực nào đang được sử dụng.
nhiều web site. Sau đó, mỗi ứng dụng phải được cấu hình để sử dụng một kiểu cơ chế xác thực khác nhau. Nghĩa là bạn sẽ có nhiều URL chứa cùng một nội dung, điều này gây ra rất nhiều nhầm lẫn. Ngoài ra, tùy thuộc vào kiểu xác thực mà bạn đang sử dụng, một số feature có thể sẽ không hoạt động.
Hệ quả tất yếu của vấn đề này là một người dùng có thể truy cập vào một hệ thống từ bên trong cũng như bên ngoài firewall theo những cơ chế xác thực khác nhau. Với SharePoint 2007, Vấn đề này làm xuất hiện hai định danh riêng biệt. Đây là một vấn đề rất lớn về chức năng. Các định danh dựa trên claims còn cho phép thực hiện hòa giải định danh. Tuy nhiên, trong SharePoint 2010, hòa giải định danh không phải là một phần của SharePoint. Bạn có thể thực hiện hòa giải định danh từ bên ngoài SharePoint, thông qua framework định danh dựa trên claims.
Định danh dựa trên claim trong Sharepoint:
Hình 2.6 Các bước xác thực dựa trên claim
Các bước theo thứ tự được mô tả như dưới đây:
• 1. Yêu cầu tài nguyên: tất cả đều bắt đầu bằng một yêu cầu sử dụng tài nguyên (resource request). Người dùng tạo một yêu cầu thông tin client. Client đó có thể là một tình duyệt web hoặc một ứng dụng phía client ví dụ như Office. Một yêu cầu sử dụng tài nguyên có thể đơn giản chỉ là một yêu cầu “GET”, truy xuất tới một tài liệu Word.
• 2. Chuyển hướng xác thực: SharePoint thông báo cho người dùng rằng họ chưa được phép truy cập tài nguyên, đồng thời phản hồi bằng một URL cho phép người dùng có thể truy cập vào địa chỉ tại URL đó để thực hiện xác thực.
• 3. Yêu cầu xác thực: Đến lúc này, người dùng gửi một yêu cầu xác thực tới một dịch vụ cung cấp định danh security token (identity provider security token service IIP-STS). • 4. Security token: Sau khi người dùng đã cung cấp các thông tin xác thực, IP-STS sẽ
kiểm tra hợp lệ những thông tin đó trong kho lưu trữa của chúng.
• 5. Yêu cầu service token: Với security token nhận được, client phải cung cấp token này cho STS SharePoint.
• 6. Phẩn hồi security token: STS SharePoint sẽ quyết định có tin hay không tin security token mà client cung cấp.
• 7. Yêu cầu tài nguyên với service token: Cuối cùng, một yêu cầu được tạo ra cùng với gói sau cùng, phản hồi security token bổ sung, một yêu cầu sử dụng tài nguyên được lặp lại với phản hồi security token. Tại thời điểm này, yêu cầu được chuyển đổi thành một đối tượng SPuser và được truyền vào hạ tầng xác thực Sharepoint.
Như chúng ta thấy, mọi vấn đề phức tạp liên quan tới việc định danh người dùng hoàn toàn được tách riêng khỏi phần xác thực. Điều này nghĩa là chúng ta có thể có nhiều identity provider và những identity provider này có thể là các tổ chức khác nhau. Chừng nào những identity provider đó còn tin tưởng lẫn nhau, token dựa trên SAML vẫn có thể được truyền qua firewall hay thậm chí qua internet. Hay nói một cách khác, chúng ta có thể định danh người dùng trên Internet. Định danh của người dùng còn có thể được sử dụng định danh tổ chức của họ để sác thực với hệ thống của một tổ chức khác, chừng nào mối quan hệ tin cậy đã được thiết lập giữa hay tổ chức từ trước.