Data Access has been discontinued. Please refer to this page for more information.

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 Plain 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. This topic covers the different mechanisms that exist to enable the client and the service to support authentication.

Authentication Options for a WCF Plain Service

WCF offers a variety of authentication mechanisms. For example:

  • Anonymous authentication - any principle is able to connect to the service. Credentials are not required for anonymous access.
  • 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. For more information, see ASP.NET Forms Authentication.
  • Username and password - a set of credentials, typically a username and password, are provided to the service. The username and password must be provided through code by assigning the UserName and Password properties of the UserName property on the proxy's ClientCredentials property.
  • X.509 certificate - the client identifies itself by using a certificate, which is known by the service in advance so that it could properly connect it to a set of user information. The ClientCredentials property on the proxy exposes a ClientSertificate property. By calling the SerCertificate method, the certificate could be retrieved from a certificate store.
  • Issued token - the client passes a token to the service to identify the requester. The client provides credentials (username and password) to a token service. After validation, the token service returns a token to the client. After it is received, the service uses the token subsequent requests.

Custom Authentication

In most of the cases the standard options that WCF offers for authentication will be enough. However, it is not possible to guarantee that the available choices will cover all possible requirements. You can extend the authentication process with your own custom mechanisms. For more information, see Creating Custom Client and Service Credentials.


When developing WCF applications, another aspect you should consider is the authorization. It determines the access that is allowed to various resources. This is related to granting access on the service side.

Process Identity

WCF services run in a service host. This host runs in a process, and this process has a security context (process identity) that controls the access rights. So when a WCF Service is hosted within IIS, its access is limited to whatever rights have been granted to the ASP.NET user.

Security Principal

The principal is a container for the caller's identity and the roles that are associated with it. The main difference between the security principal and the process identity is the level of control that is possible. In many scenarios, the principal can be related to a Windows account. Also you are allowed to create a new security principal object with its own identity and set of roles. The principal object can then be associated with a running thread. You can use the PrincipalPermissionAttribute to control access to method through the roles associated with a principal. In the following example, the current principal is verified whether it belongs to a role called "Readers".

[PrincipalPermission( SecurityAction.Demand, Role = "Readers" )]
public IEnumerable<RentalRateDto> ReadRentalRates()
   return this.RentalRateService.GetAll();
<PrincipalPermission(SecurityAction.Demand, Role := "Readers")>
Public Function ReadRentalRates() As IEnumerable(Of RentalRateDto)
 Return Me.RentalRateService.GetAll()
End Function


The ServiceSecurityContext class provides information about the security context for a request. It exposes identity information and a set authorization policies and claims.


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 who is making the request. For more information, see ASP.NET Impersonation.