ADO.NET Data Services Dec2007 CTP – Validation and Access Control

Note: This post refers to the CTP available here.

When building frameworks to expose and consume data on the web, access policy and data validation are always one of the first topics discussed during the design process, at conferences, etc.  Given this, we thought the topic would be a good one to kick off a series of blog posts about the feature set of the recently announced Dec 07 CTP of the product.  If you haven’t seen ADO.NET Data Services / “Project Astoria” before, I suggest checking out for an overview and “getting started” style walkthroughs of the product. 


Before getting into access control and validation, I need to put in a quick note about authentication to set the stage.  Data services do not directly implement an authentication scheme. Instead, they rely on the authentication infrastructure of the technology (ex. WCF+ASP.NET, WCF, etc) hosting the data service. If you have an ASP.NET site that uses authentication (either one of the built-in authentication schemes or a custom one that sets the HTTP context principal appropriately), Astoria will simply leverage that mechanism to establish the current identity (principal) for a given request.  Ok, now that we know how data services determines who is making a request, its’ time to look at how to implement access control and perform validation based on this information.

Service-wide Access Control

By default all entities, Service Operations and metadata describing any resources in a data service cannot be retrieved.  Said another way, by default a data service is completely locked down with no read or write access.  This is one of the significant differences from previous (prototype) releases of Astoria.  In prior releases, a data service was fully open by default to enable easily creating and evaluating our ideas for what data services on the web might look like.  Now that the project has moved out from incubation and into an official product release, we changed such that services are locked down out of the box to align with typical security requirements of production web infrastructures.

One of the first steps a data service developer needs to take is to open up access to the appropriate resources in the data service.  One way to do this is to set service wide, access control policy by adding a data service initialization method.  The code below shows what a typical data service created over the northwind sample database would look like if only the Customers, Orders and Products sets were exposed. 

public class MyDataService : WebDataService<Northwind>


public static void InitializeService  

   (IWebDataServiceConfiguration configuration)


   // URI ‘/Customers’ entities is enabled for all   

   //read and write operations


       ("Customers", ResourceContainerRights.All);


     //  URI ‘/Orders’ is disabled, but ‘/Orders(1)’

     // is enabled for read only


      ("Orders", ResourceContainerRights.ReadSingle);


    //  Can insert and update, but not delete

    // Products



              ResourceContainerRights.WriteInsert |




The access policies in the snippet above are applied to all requests to the data service and are related to entity sets, not particular URIs.  For example, the policy described by the call: ‘SetResourceContainerAccessRule("Customers",ResourceContainerRights.All)’ would apply to a request sent to  ‘/Customers(‘ALFKI’)’ as well as  ’/Orders(1)/Customers’.  Basically, the rule is no matter how you address an entity or entity set, the rules in the init method apply equally.  All other entities not explicitly enabled in the initialize service method will not be exposed by the data service.  For example, the northwind db also includes Employee entities.  Since the initialization method does not say anything about Employees, any request to retrieve an employee entity will result in an HTTP 404 (Not Found) response.  In addition accessing the endpoint to retrieve the service’s metadata (ex. http://host/service.svc/$metadata) will return a document which only describes those resources where were explicitly made visible.

Per Request Access Control & Validation

Many data services will need to need to run validation logic when entities enter the data service (for inserts, updates or deletes) and/or restrict access to entities on a per request basis.  For these scenarios Interceptors are used which enable a data service developer to plug in custom validation or access policy logic into the request/response processing pipeline of a data service.  We decided to take the approach of providing infrastructure to build out custom per request access policy instead of defining an access policy model specific to ADO.NET Data Services because we recognize that each application, business, etc have different requirements in this space and that we could add value by providing comprehensive infrastructure elements for one to build custom access policy. 

For example, assume you want to implement a policy which enabled customers to only retrieve their orders and not orders placed by other customers.   The example below shows a query interceptor that implements this access policy.  The important aspect to note about query interceptors is that they accept as a parameter an instance of IQueryable<T> which represents the query the system will push down to the underlying data store to retrieve the requested entity.  As shown in the example, this approach enables access policy to be defined using query composition eliminating any added round trips to the data store to retrieve access control information.  The example assumes the data service is hosted within a WCF+ASP.NET web application with authentication enabled as the ASP.Net HTTPContext object is used to retrieve the principle of the current request. 

using System;

using System.Web;

using System.Collections.Generic;

using System.ServiceModel.Web;

using System.Linq;

using Microsoft.Data.Web;

using NorthwindModel;

namespace TestApplication


public class nw :   WebDataService<NorthwindModel.NorthwindEntities>


public static void InitializeService(

                            IWebDataServiceConfiguration configuration)







                    ResourceContainerRights.WriteInsert |





    public IQueryable<Orders> OnQueryOrders(IQueryable<Orders>



          return from o in orderQuery

             where o.Customers.ContactName ==


             select o;





To hook into update operations (insert, update & delete), change interceptors are used.  The example below validates all the Product entities that are created are not discontinued.   This would also be the place to implement per request access policy to restrict inserts, updates and/or deletes per request.      


public void OnChangeCategories(Products p, ResourceActions action){

if(action == ReceiveEntityOperation.Insert) {

  if(p.Discontinued) {

    throw new WebDataServiceException(400,

                       "Cannot add discontinued products");




To summarize, services created using the ADO.NET Data Services framework are locked down by default and resources must be explicitly exposed.  Once exposed, the service developer has a number of hooks at their disposal to implement per request access control and business rule validation.  

What do you think of this approach?  Is there something we should change/alter/add/etc to better meet your requirements?   We look forward to hearing your feedback and continuing our open design process on this blog.


Mike Flasko

Program Manager


This post is part of the transparent design exercise in the Astoria Team. To understand how it works and how your feedback will be used please look at this post.

Comments (8)

  1. MichaelD! says:

    You guys really need to put this in a ConfigurationSection if you haven’t already. 🙂 🙂 🙂  This is an amazing technology… can’t wait to dig into it!

  2. My blog has been slow over the last few months, but this time its not because I haven’t been blogging

  3. My blog has been slow over the last few months, but this time its not because I haven&#39;t been blogging

  4. Stephen says:


    This seems like an awful lot of work to handle access control and validation. Have you thought about doing this declaratively instead of programmatically? Allow us to create a simple XML file that lists the users and roles that have access to a service. Also, allow us to declare validation elements to handle validating inputs. My worry about the current approach is that it appears to be highly error prone (I wire up the interceptor wrong, and I have a huge security hole). I want to create a file that looks something like this:


     <service uri="orders" allowWriteRoles="Administrators">



    An additional benefit of this approach is that you could supply a tool that allows us to build up our data services.

  5. Today I found Jonathan Carter’s growing series of posts over here on ADO.NET Data Services; ADO.NET…

  6. Corey says:

    This technology looks very promising. I agree with Stephen’s statement on the verbosity of hooking up authentication. Also, given that unit of work pattern is used and changesets are sent for save operations. What happens if my validation rules span more than one entity for the validation to be satisfied? Would I be forced to move this validation into stored procedures and triggers?

  7. Dan Crowell says:

    I am excited about building applications with Data Services. It will make it easy to rapidly develop data access layers.

    I am researching security options. This post was written a year ago. Is the information in this still current?

    Thanks, Dan

Skip to main content