o Xác thực người dùng
o Lưu trữ các tài khoản và mật khẩu
o Gọi tới các thư mục tổ chức để lấy các chi tiết định danh người dùng. o Tích hợp với các hệ thống định danh từ những nền tảng và công ty khác.
Định danh dựa trên yêu cầu.
Có một số thành ngữ sử dụng nhiều để mơ tả định danh dựa trên yêu cầu bao gồm: định danh, yêu cầu, token bảo mật, nơi đưa ra xác thực (issuing authority), dịch vụ token bảo mật (Security Token service – STS), và ứng dụng (relying party).
Định danh: Thuật ngữ định danh là một thuật ngữ được dùng nhiều. Cho đến giờ nó đã được sử dụng để mơ tả khơng gian bài tốn bao gồm sự xác thực, sự ủy quyền, v.v…Nhưng đối với mục đích mơ tả ACS, thuật ngữ định danh để mơ tả một tập các thuộc tính (gọi ngắn gọn là các yêu cầu) mà mô tả một người dùng hay một số thực thể khác trong hệ thống từ quan điểm bảo mật.
Yêu cầu: Một yêu cầu như một phần tử nhỏ của thông tin định danh như là tên, địa chỉ email, tuổi, địa vị hội viên trong vai trị bn bán, v.v…Càng nhiều các yêu cầu mô tả, ứng dụng biết nhiều về người dùng đã tạo yêu cầu. Các yêu cầu được ký bởi một nhà cung cấp (issuer), và ứng dụng sẽ tin tưởng tập các yêu cầu đó như là bạn tin tưởng nhà cung cấp. Một phần của chấp nhận một yêu cầu là xác thực rằng nó đến từ một nhà cung cấp đáng tin cậy. Điều này bao gồm một số kĩ thuật mã hóa sử dụng trong .Net Framework như là WCF, Geneva Framework, và ACS sẽ giúp làm trong suốt đối với ứng dụng, cho phép chỉ tập trung vào xác thực nhà cung cấp định danh.
Token bảo mật (Security Token): Người dùng phân phối một tập các yêu cầu tới ứng dụng cùng với công việc cần làm. Trong một dịch vụ web, những yêu cầu này được chứa trong phần header bảo mật của thông điệp SOAP. Trong một ứng dụng web, các yêu cầu đến thông qua một HTTP POST từ trình duyệt của người dùng, và có thể được sử dụng để thiết lập một phiên đăng nhập dựa trên cookie. Dù sử dụng cách nào, các yêu cầu phải được serialized theo cách nào đó, và đó chính là token bảo mật. Một token bảo mật là một tập các yêu cầu đã được serialized thành XML (hầu hết ở dạng SAML) và được ký điện tử bởi một đơn vị xác thực. Chữ kí rất quan trọng-nó đảm bảo tính đúng đắn của ứng dụng.
Đơn vị xác thực và nhà cung cấp định danh (issuing authority & identity provider): Một đơn vị xác thực có hai đặc tính chính. Thứ nhất là nó tạo ra các token bảo mật. Đặc tính thứ hai, rất quan trọng nhưng thường không thấy theo nghĩa đen, là sự logic mà xác định loại yêu cầu nào được tạo ra. Điều đó cịn dựa trên định danh của người dùng, ứng dụng đang được sử dụng,và những ngữ cảnh khác như thời gian trong ngày. Kiều logic này thường tham chiếu tới như là chính sách.
Có nhiều đơn vị xác thực, bao gồm Windows Live ID, Geneva Server (một sản phẩm sử dụng Active Directory lưu giữ người dùng của nó), PingFederate của Ping Identiry (một sản phẩm đưa ra các định danh người dùng bằng công nghệ Java).
Một số đơn vị xác thực, như là Windows Live ID , tập trung hoàn toàn vào việc xác thực người dùng. Công việc của chúng là xác thực một người dùng và tạo ra một SAML token với ID của người dùng và có thể có những thuộc tính định danh khác. Những kiểu của đơn vị xác thực này gọi là các nhà cung cấp định danh (identity provider), viết tắt là IdP. Nhiệm vụ của chúng là trả lời câu hỏi ―người dùng là ai?‖ và đảm bảo rằn người dùng biết mật khẩu của họ, là chủ sở hữu của smart card, biết mã PIN, có xác thực đúng tế bào võng mạc, v.v…
Dịch vụ token bảo mật (STS-Security Token Service): Một dịch vụ Security Token dùng để tạo, ký và đưa ra các security token theo các giao thức tương tác mà sẽ được bàn tới trong phần được gọi là các chuẩn.
Relying Party (RP): Khi xây dựng một ứng dụng dựa trên các yêu cầu, bạn đang xây dựng một relying party. Ứng dụng này hiểu các yêu cầu, hay ứng dụng làm việc dựa trên các yêu cầu.
Các chuẩn: Để tạo mọi sự tương tác, một số chuẩn WS-* được sử dụng trong kịch bản trên. WSDL có thể nhận được sử dụng WS-MetadataExchange hoặc một HTTP GET đơn giản, và chính sách bên trong WSDL được cấu trúc theo đặc tả WS-Trust. STS của đơn vị xác thực đưa ra một điểm cuối mà cài đặt đặc tả Web-Trust, mà được mô tả làm thế nào để yêu cầu và nhận các token bảo mật.
Một chuẩn quan trọng khác là SAML, ngôn ngữ đánh dấu xác nhận bảo mật, là một từ điển XML theo chuẩn cơng nghiệp có thể được sử dụng để biểu diễn các yêu cầu trong một cách tương tác. ACS chấp nhận các token SAML như đầu
vào từ nhà cung cấp định danh, và tạo ra các token SAML như đầu ra cho các ứng dụng của bạn để sử dụng.
Ứng dụng dựa trên trình duyệt: Các smart client khơng phải là thứ duy nhất có thể tham gia vào thế giới của định danh dựa trên các yêu cầu. Các ứng dụng dựa trên trình duyệt (có thể gọi là các passive client) có thể cũng tham gia. Hình bên dưới chỉ ra cách hoạt động của loại ứng dụng này. Người dùng chuyển trình duyệt của họ tới ứng dụng web hiểu các yêu cầu. Ứng dụng web thấy rằng người dùng chưa đăng nhập vào và chuyển tới một trang web đưa ra bởi đơn vị xác thực mà ứng dụng tin tưởng.
Một khi người dùng được xác thực, đơn vị xác thực chỉ ra những yêu cầu nào đưa ra, và gói chúng trong token SAML, mà được ký với một khóa riêng (private key). SAML token được mã hóa trong phần trả lời với một đoạn javascript để khi trình duyệt của người dùng nhận được trả lời này, nó tự động gửi token tới ứng dụng sử dụng HTTP POST. Nếu ứng dụng muốn thiết lập một phiên đăng nhập cho người dùng ở thời điểm này, nó sẽ tạo một cookie để người dùng không phải quay ngược trở lại nhà cung cấp định danh với mỗi yêu cầu. Web Page Browser Application (Web App) Issuing Authority 2 . R e d ir e c t 1. HTTP GET 3. HTTP POST Passive Client (WS-Federation)