Security in data services
We still have more questions than answers on what is the appropriate security story for data services. The May CTP of Astoria had some ideas built into it, but it was clearly not enough to build real-world applications. There is quite a bit that needs to be explored in this space.
I wanted to take a few paragraphs to make a few problem statements and describe the way we see the problem. I’d be curious to hear what application scenarios you have and how they may affect the security-related requirements for a data service.
Authentication
When running as part of an ASP.NET application, Astoria data services just pick up whatever authentication scheme the application is using. All that matters from the Astoria perspective is that once the client-agent has been authenticated the current principal is properly set; Astoria will just use that principal later on during authorization.
For the online service version things are trickier. There are at least two different players here: the creator/owner of the application or web site, and the user that logs in, the viewer/owner of the data. One trivial approach would be to hand out a set of credentials to the creator of the application, and they could use that to log into the data service. However, there are two big issues with that:
- That works well if the access to the data service happens from the server side, but what if you want to access the service from the client? You'd have to send the credentials to the client so that the code sitting on the client can log-in, probably not a good idea.
- Even if you could protect the credentials, is that the right thing to do? The end-user is probably the owner of the data in the end, so it may not make sense to use the application creator’s credentials for accessing it.
Another approach that addresses these issues would be to say that the end-user has to authenticate against the data service separately from the application or web site. This way, the user owns the data and can secure it. This seems more natural, but has the issue of requiring the user to authenticate twice (with the application and with the data service).
You could take this further and have some sort of secure token service that all parties trust; then users could authenticate once and the client code could present the tokens as needed for both the application and the data service.
Authorization
The key question from the authorization perspective when it comes to data services is, in my opinion, what is the right granularity.
We are thinking of doing the usual principal/role-based authorization, but the thing is what is authorized.
In the May CTP of Astoria the story is super simple, and it wasn't really so you could build real applications, but more to get developers thinking whether that was the pattern that we should grow into a full-blown one or we needed to start from scratch. In that release the unit of authorization was a whole entity-set (e.g. "Customers"); you could say whether you could act on the entity-set if you are anonymous and if you are authenticated. "Act" means whether you can even see it, and separately whether you can write to it.
Moving forward we could extend that so that it is not just whether the client is authenticated, but you can also say which principals/roles are allowed. However, that may still not be flexible enough. Beyond that, I could imagine a couple of options:
- Predicate-based authorization, where each principal/role can be bound to a given filter predicate for each entity-set, and you get to see/modify only those entities that match the criteria given by the predicate.
- Instance-based (row-level) security. This is nice to have, but very tricky to implement if you want the system to scale arbitrarily (say "internet scale").
Maybe there are other strategies for authorization, in particular to describe the units of authorization so that they are useful for building actual applications.
As I said above, more questions than answers in this space for now. I'll keep posting as we make progress on the design in this area.
-pablo