html>
Exploring ASP.NET & Web Development
Securing ADO.NET Data Services
By Don Kiely
At DevConnections Orlando this spring, I made my second appearance on .NET Rocks. .NET Rocks is Carl Franklin and Richard Campbell's marvelous .NET podcast. Besides talking a fair bit about Alaska and sled dogs (two of my favorite topics), we spent the time on the show talking about what's coming in AJAX 4.0. That's the update that will be part of Microsoft Visual Studio 2010 and .NET Framework 4.0, due out later this year or early 2010.
I gave Carl and Richard a rundown of my favorite new features, and the talk turned to the data-binding and client-template features. I made the comment that it's easy to make client-based, full-featured data-maintenance applications using AJAX 4.0 and ADO.NET Data Services. Being a security guy, I mentioned that I hadn't really explored the security features of ADO.NET Services and was concerned that, as easy as they are to implement, there are probably a lot of unsecured data services floating around, just waiting to be hacked. I was confident that in this day and age Microsoft would only implement a technology with strong security; I just hadn't explored the issue.
That sparked an interesting discussion of what the options might be. Not having .NET Framework on the client we were talking about general-purpose web applications, so we couldn't count on the client even running on Windows precludes using any of the Framework's security features. Fortunately, help soon came from the audience: one person who was in the live audience and another who listened to the podcast after it appeared in the podcast feeds.
Overriding the CreateDataSource Method
Rusty Plant of National Healing was in the audience on the day we recorded and came up afterward with some code loaded on his laptop. He and his team approached the security issue by overriding the data service's CreateDataSource method. This method creates an instance of the underlying template class that connects the service to the data. In the sample code below, based on Rusty's code, I'm using an Entity Data Model (which is part of the Entity Framework) of the Northwind database. If the user is authenticated using ASP.NET's rich support for authentication, the code creates the data source. But if the user is not authenticated, it returns an Unauthorized status code and a null.
protected override NorthwindEntities CreateDataSource()
{
if (!HttpContext.Current.Request.IsAuthenticated)
{
WebOperationContext ctx = WebOperationContext.Current;
ctx.OutgoingResponse.StatusCode =
System.Net.HttpStatusCode.Unauthorized;
return null;
}
else
{
return base.CreateDataSource();
}
}
Very nice. It may not work for all scenarios, though, because you might have to jump through some hoops to make sure the user is authenticated. But if you're already using ASP.NET authentication, this is largely a no-brainer.
A couple of weeks after we recorded the .NET Rocks show and it had appeared in the various feeds, Carl forwarded an email he received from Aaron Armstrong, senior manager at SunGard Consulting Services. After listening to the show, Aaron wrote to let us know that Mike Taulty had a nice "Authenticating with ADO.NET Data Services" blog post about the issue. I don't know Mike, but he is with Microsoft in the United Kingdom and is a prolific creator of screencasts about ADO.NET and web technologies. (Check out his MSDN and Silverlight 2.0 screencast series; the guy's a machine!)
Mike's ADO.NET Services authentication blog post is a bit dated, almost a year old. The main thing that dates it is that some of the techniques he discusses are easier now because Visual Studio has support for some techniques, saving the work of writing some code. Nevertheless, it's an interesting exploration of the issues and options.
Using Page Templates and Authenticating via JavaScript
One of the interesting options that I haven't worked with much yet is Client Application Services. It lets you call various ASP.NET features as web services, such as Membership, logins, roles, and profiles. It was originally part of the ASP.NET 2.0 AJAX Extensions and lives on in later versions. Once you activate it in web.config in the Data Services application and on the client, you can use the Membership.ValidateUser method and instantiate the service only if the user is authenticated. Very slick.
But the original question during the Dot Net Rocks show was securing an ADO.NET Data Service from a client-based AJAX application. Mike Taulty covers that as well, suggesting two ways to accomplish authentication. One way uses two page templates, based on whether the user is logged in or not, using usual ASP.NET techniques. You display the logged-in template with a Get Data button if the user is logged in. Otherwise you show the other template that requires the user to log in. Easy and straightforward, always good attributes of an application feature.
The other technique is to authenticate the user from the client using JavaScript. This requires writing client-side code to authenticate the user and get data from the data service only if the user is authenticated. Mike's blog post has sample code for both these scenarios.
It turns out that securing ADO.NET Data Services is not trivial, but security never is. You'll have to do a little work to keep your data service secure, but you'll be far safer in the long run if you make the effort.
Don Kiely ([email protected]), MVP, MCSD, is a senior technology consultant, building custom applications and providing business and technology consulting services. His development work involves tools such as SQL Server, Visual Basic, C#, ASP.NET, and Microsoft Office.
