SDS and .NET Access Control Service Integration

[This document supports a preliminary release of a software product that may be changed substantially prior to final commercial release. This document is provided for informational purposes only.]

The .NET Access Control Service is a hosted, secure, standards-based infrastructure for multi-party, federated authentication and rules-driven, claims-based authorization. SQL Data Services (SDS) supports authentication and authorization via tokens issued by the .NET Access Control Service. This allows applications secure not only their own web service layer, but also their SDS-based data layer using the same, declarative access control mechanism. This feature requires a .NET Services solution account, which is available through the .NET Services Developer Center.

Background

SDS uses a basic authentication scheme in which the user name and password are sent as part of the request. SDS authenticates the user by checking the user password.  The disadvantages of this scheme are:

• You must share your password with SDS.  Instead of sending your password to every service that you interact with, such as SDS, it would be better if a central identity service processed these passwords.
• On every request, SDS authenticates the user.  This adds extra processing on every request.

Token-based Authentication

SDS supports an alternative authentication scheme which uses token-based security that solves these problems. Rather than passing credentials directly to SDS service, credentials are passed to a separate identity provider, which authenticates the credentials and returns a security token. The user then passes this token to SDS with each request. The same token can be reused across multiple requests to SDS.

The token does not contain the user password because the identity provider has already authenticated the user. The token is cryptographically signed and encrypted by the identity provider so that only SDS can read it, and SDS knows that only the identity provider could have produced it.

Other forms of credentials, besides username/password, can be used to obtain a token from the identify provider. They are:

• X.509 certificate
• InfoCard

In this release, using token-based authentication scheme with SDS has the following limitations:

• When communicating with SDS, the token-based security is available only when using the SOAP protocol. For applications using the REST protocol, only the basic authentication is supported (username/password).
• Requires a .NET Services solution account. That is, in order to use the token-based authentication provided by .NET Access Control, a .NET Services account is required in addition to the SDS account. For more information, see .NET Services which at this time is in private CTP (Community Technology Preview).

For a working sample see, Accessing SDS with the .NET Access Control Service.

Endpoint names

In SOAP applications, depending on the authentication scheme you use, the appropriate endpoint name must be specified. These endpoint names are defined in the app.config file. The following table lists the endpoint name

Authentication Schema	Endpoint name
basic authentication	BasicAuthEndpoint
Token-based authentication (username, password)	UsernameTokenEndpoint
Token-based authentication (X.509 Certificate)	CertificateTokenEndpoint
Token-based authentication (Infocard)	CardSpaceTokenEndpoint

See Also

Concepts

Accessing SDS with the .NET Access Control Service