How DCS Authenticates Requests
The DCS message bus supports the WS-Trust protocol to authenticate user requests. The WS-Trust specification defines methods for issuing and validating security tokens, and provides support for implementing brokered authentication.
The Token Issuer Service provided with DCS implements a security token service (STS) that follows the WS-Trust specification. It can authenticate users and issue Secure Application Markup Language (SAML) tokens that contain authenticated claims. An administrator can configure the security policy for a DCS service to authenticate requests by using the Token Issuer Service provided with DCS, or by using a third-party STS.
By default, the STS in the Token Issuer Service authenticates users by using account information in Active Directory. If the user is currently logged on to the same domain as that used by the Token Issuer Service, the STS uses Kerberos authentication. If the user is not logged on to the same domain, an administrator can configure the STS to authenticate the user by exchanging digital certificates. The Token Issuer Service implements a customizable model for generating SAML tokens, and a developer can build a custom claim provider to validate the claims for a client application. For information about how to configure the Token Issuer Service to issue different SAML tokens and use a custom claims provider, see the DCS Deployment Guide.
Message Flow with the DCS STS
The following image shows the flow of messages between a client application and a service that uses the STS to authenticate users.
.png "Dd631948.8b77b4b2-2e8f-4cd6-8376-bd0cfc13311d(en-us,MSDN.10).png")
Using the DCS Security Token Service to authenticate request messages
When a client application issues a request to a DCS service, the proxy sends a Request for Service Token (RST) message to the STS in the Token Issuer Service The RST includes information that specifies the types of claims that the client application uses to authenticate the user, together with information that the STS can use to verify that the user running the client application is valid. The STS authenticates the user by using the information in the RST message. If the authentication is successful, the STS issues a Request for Service Token Response (RSTR) message to indicate that the user was authenticated, together with a SAML token confirming the identity of the user.
When the user running a client application is authenticated by the STS, the client proxy transparently includes the authenticated SAML token in the security header of request messages sent by the client application to the DCS service instance, following the WS-Security specification. The DCS service can use the identity information in the SAML token to authorize the user request. The DCS service can use the token issuer interface of the claim provider component to extract the claims information from the SAML token to help perform this task. For more information about authorizing requests, see How DCS Authorizes Requests.
A DCS service can implement additional protection by implementing the WS-SecureConversation protocol to encrypt request and response messages transmitted between the client application and the DCS service instance. For more information about how to configure the security policy for a service, see Configuring Security Policy for a Service.
Note
As an optimization mechanism, the SAML token issued by the STS is cached by the client proxy, and attached to each request sent by the proxy to the DCS service instance. An STS can be configured to issue SAML tokens that are valid for a specified period. When this period expires, the client has to authenticate with the STS again. The client proxy manages this process automatically.