Security Considerations

This article is relevant to entity models that utilize the deprecated Visual Studio integration of Telerik Data Access. The current documentation of the Data Access framework is available here.

When planning how to secure a WCF Data Services-based OData service, you must address both authentication, the process of discovering and verifying the identity of a principal, and authorization, the process of determining whether an authenticated principal is allowed to access the requested resources. By default, the client library does not supply credentials when sending a request to an OData service. However, you can specify that credentials might be sent to authenticate requests to the data service by supplying a NetworkCredential for the Credentials property of the DataServiceContext.

The following example shows how to explicitly provide credentials that are used by the WCF Data Services client when requesting data from the data service:

wcfDataServiceContext.Credentials = new NetworkCredential( UserName, Password, Domain );

dataManager.Credentials = new NetworkCredential( UserName, Password, Domain )

Authentication Options for a WCF Data Service

The following mechanisms are available to help you authenticate requests to a WCF Data Service:

• Anonymous authentication - any principle is able to connect to the data service. Credentials are not required for anonymous access.
• Basic and digest authentication - credentials consisting of a user name and password are required for authentication. When you want to have your data service use basic authentication based on some custom authentication service and not Windows credentials, you must implement a custom ASP.NET HTTP Module for authentication. For more information, see Digest Authentication Technical Reference and Custom Basic Authentication.
• Windows authentication - Windows-based credentials are exchanged by using NTLM or Kerberos. If the service is deployed in an environment in which a Windows domain server is used, Kerberos is used. If the service is deployed in a workgroup environment, NTLM is used. This mechanism is more secure than basic or digest authentication. For more information, see ASP.NET Forms Authentication.
• ASP.NET forms authentication - lets you authenticate users by using your own code and then maintain an authentication token in a cookie or in the page URL. You authenticate the user name and password of your users using a login form. If the application authenticates the request, the system issues a key for re-establishing the identity for subsequent requests. For more information, see Forms Authentication Provider.
• Claims-based authentication - the data service relies on a trusted “third-party” identity provider service to authenticate the user (e.g. OAuth 2.0). For more information, see OData and OAuth.

Impersonation

Impersonation is a commonly used approach within distributed applications. The purpose of impersonation is to extend the access of a service to resources. It does this by taking the rights of the consumer into consideration. Impersonation enables the service to assume the security context of the requester when it must determine if access to a resource is to be allowed. The data service could access required resources, such as files on the server, by using the credentials of the worker process that is hosting the wcf data service. When using impersonation, ASP.NET applications can execute with the Windows identity of the user making the request. For more information, see ASP.NET Impersonation.

Restricting Access to Data Service Resources

By default, the Service Wizard allows you to grant common read and write access against the exposed entities to any user that is able to access the data service. It is recommended to limit both read and write access to only the resources that are required by the client application. For example:

public static void InitializeService(DataServiceConfiguration config)
{
config.SetEntitySetAccessRule("RentalRates",
                                EntitySetRights.AllRead | EntitySetRights.WriteMerge |
                                EntitySetRights.WriteReplace | EntitySetRights.WriteDelete);
config.SetEntitySetAccessRule("RentalOrders",
                                EntitySetRights.AllRead | EntitySetRights.WriteAppend |
                                EntitySetRights.WriteDelete);
config.SetEntitySetAccessRule("Employees",
                                EntitySetRights.AllRead | EntitySetRights.WriteAppend |
                                EntitySetRights.WriteMerge | EntitySetRights.WriteReplace);
config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V3;
}

Public Shared Sub InitializeService(ByVal config As DataServiceConfiguration)
    config.SetEntitySetAccessRule("RentalRates",
                                    EntitySetRights.AllRead Or
                                    EntitySetRights.WriteMerge Or
                                    EntitySetRights.WriteReplace Or
                                    EntitySetRights.WriteDelete)
    config.SetEntitySetAccessRule("RentalOrders",
                                    EntitySetRights.AllRead Or
                                    EntitySetRights.WriteAppend Or
                                    EntitySetRights.WriteDelete)
    config.SetEntitySetAccessRule("Employees",
                                    EntitySetRights.AllRead Or
                                    EntitySetRights.WriteAppend Or
                                    EntitySetRights.WriteMerge Or
                                    EntitySetRights.WriteReplace)
    config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V3
End Sub

Role-Based Interceptors

Interceptors enable you to intercept requests against data service resources before they are acted on by the data service. You could use them to make decisions based on the authenticated user that is making the request.