Nigel Ellis Discusses Role-Based Authorization Plans for SQL Server Data Services

SQL Server Data Services (SSDS) relies on Secure Socket Layer (SSL) v3 encryption to secure an authority’s user ID and password for authentication, as well as to protect data transfer from exposure by interception. Delegated authorization is required to restrict additional authenticated users to read-only or read-write access. Several potential SSDS testers (including me) have requested (but not received) details on plans for implementing role-based authorization.

Channel9’s Istvan Cseri and Nigel Ellis: SQL Server Data Services Architecture interview by SSDS evangelist Ryan Dunn posted April 7, 2008 contains quite a bit of useful (and previously unpublished) information about SSDS architecture. My Nigel Ellis Says SQL Server Data Services Will Use the Entity Data Model For Schemas post of July 3, 2008 is a transcript of Nigel Ellis’s comments about SSDS’s future schema model.

Following is a transcript I made of Nigel’s remarks about SSDS security. The transcript starts at 00:31:05, immediately following the schema discussion.

Authentication

[T]he security model that we've basically shared with people so far is relatively simple. A single principal is a single user signed up for an account, and then that account can provision one or more authorities and, as I've mentioned, authorities can have containers to store entities. And usually all the data you have stored beneath a single authority, all of its containers are secured to that user account.

So when we talk about authorization and access to the service, when you send your request to the service, you provide your user ID, you can think of it as an application ID, and your password that was provisioned for you, we validate you that you are indeed the owner of that specific authority or the container you're accessing and, if so, you get what you might think of as "full control." Now, that's a fairly limited model. So it actually speaks fairly well to n-tier deployment where an application owns all of the data, but it doesn't really address the notion of different principals having different roles over the same data.

Role-Based Authorization

For example, I have an owner role over a container, I have a writer role over a container, I have a reader role, and so on. So when you look at actually extending that, we think about adding those roles to containers, … for those of you that are familiar with the NT ACL model, an ACL is essentially an Access Control List, the Access Control List has a set of data elements, and each ACL essentially lets an owner, SID, or actual principal, such as Ryan or Nigel, have a set of rights on that container, such as read access, write access, and so on.

So we're looking at, in some sense, actually extending our security model, and allowing you to have different roles over, say, the authority level and the individual container level. So ultimately, you could enable scenarios where Nigel has full control over a container, but he gives Ryan and Istvan read control on that container. [Emphasis added.]

Unauthenticated (Public) Read-Only Access and Quotas

We talked quite a while ago about this notion of having public read control, that is you can actually come in and you don't have to present any credentials; you're essentially authorized. That's something we could very easily turn on. It actually gets very interesting when you think about the economic model. We will be selling a service, so essentially, in the sense of you're warehousing your data and we're providing storage and basic computation over it, we'll charge you for the resources you consume.

So, if you choose to change one of your containers to public read access, that means that anyone over the Internet can start hammering that container. So while it's easy for us to give that feature, the question is "How would you feel about being billed when, say, people start hammering over that." So that's something we'll have to look into for the right way of doing this.

For example, there might be a case where quotas might come in. There's a quota assigned to this public container. That container's only allowed to have so many operations in a certain time period or transfer so much information, to provide safeguards for those scenarios.

Related posts:

• Nigel Ellis Says SQL Server Data Services Will Use the Entity Data Model For Schemas (7/3/2008)
• SQL Server Data Services Needs an Open Development Process Similar to that for ADO.NET Data Services and Entity Framework (6/27/2008)
• Is the ADO.NET Team Abandoning LINQ to SQL? (5/23/2008)

Technorati tags: SQL Server Data Services, SSDS, Secure Socket Layer, SSL