OData, Entity Framework, and Windows Azure access control

In this article, I'll explain the use of the Entity Framework (with Windows Communication Foundation (WCF) RESTful services exposed and secured by Windows Azure Access Control Service (ACS)) to implement an Open Data protocol (OData )。

Like most developers, I often find myself trying to use a variety of new methods to integrate a variety of technologies to achieve the project as efficiently as possible while providing a flexible, maintainable solution. This can be difficult, especially if the project requires fast and safe disclosure of data.

Recently I need to create a secure Web service for an existing database and Web application. I really don't want to implement all the CRUD (create, read, update, DELETE) operations of the Code. Just creating custom service contracts, operational conventions, and data conventions is tempting, so you can accurately implement how data is exposed and how others use it through services. But I know that a more favourable approach must be adopted. I began to look at the various ways to complete the work and see the potential of OData (which I like to call "Oh Data"). The problem is that OData itself is not safe, which is unacceptable to me, so I need to add a layer of security above the OData service so that I can rest assured that OData is safe. When I started, I found out that Acs,acs is very good for implementing cloud-based federated authentication and authorization services, which is exactly what I need. Then I feel very proud. I realized that if I combined ACS with OData, I'd get a solution.

Now, I do consider implementing a custom service contract, which is feasible to implement, especially if the data model requires an abstraction layer ahead of it and needs to protect the database entity from being exposed directly to the service consumer. However, given its time consuming-creating the right documentation on how to use the service, as well as putting extra effort into setting security ("Messagecredential" and "transportwithmessagecredentials"), So the project could get out of control quickly. I am also concerned about the need or request for additional methods to support the use of these services for this or that reason, which adds time, maintenance, and customization again. Even if the implementation of the service directly uses the Entity Framework and the ado.net, you may still need to do all the CRUD of the code to keep the data layer synchronized. Assuming there are dozens of tables, this work can be very tedious. Moreover, creating and maintaining any additional documentation and implementation details to allow end users to use my services will only make this work a more complex proposition and difficult to manage.

A more convenient way

After I identified the main technologies, I started looking for other technologies to fill the gaps and help build a cohesive solution. The goal is to limit the number of code that needs to be written or maintained while securely exposing my OData WCF RESTful service. The technologies I combine are: ACS, OData, Entity Data Model, WCF data Service (with entity license), and a custom Windows Azure security implementation. Each technology has its own important value, but combined, their value will be greatly increased. Figure 1 shows a general overview of how some of the techniques work.

Figure 1 Brief overview of ACS with security interception

Before trying to incorporate all of these technologies, I have to look back and see how each technology and how these technologies will affect the project. Then I have a clear understanding of how to integrate these technologies, and what else is required for others to use my services through other technologies.