共用方式為

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:

  1. 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.
  2. 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

Comments

  • Anonymous
    May 21, 2007
    The authorization stuff is actually orthogonal to Astoria, isn't it? We'll need something like that in most scenarios. It's probably outside the current scope of the EF today, but when you start adding layers on top of it, one of the obvious ones is the authorization layer..

  • Anonymous
    May 22, 2007
    When it comes to Security, it must be kept simple, even if it means shipping a single Authorization/Authentication mechanism, as the product mature and the developers give feedback we can will be able to see how would they be using Astoria and what kind of new Authorization/Authentication Mechanism should be added, in this kind of disconected scenarios I usually think of kerberos, but we will not know what would be more appropriate until developers start using the product and asking for features and means to do something. I thik that it should be simple to setup, either using an existing asp.net application authentication mechanism or just configuring a particular instance of astoria on the server to use XYZ Authentication/Authorization. that way it does not have to depend on asp.net applications etc.

  • Anonymous
    May 22, 2007
    Andres, Once the Entity Framework has a built-in authorization model you could think about authorization as somewhat orthogonal to Astoria. However, I still think there will be certain aspects that are intrinsic to the nature of the interface, so some tweaks on top of whatever the EFx security model ends up being will be required. Also, I will want a working version of Astoria before future revs of the Entity Framework, so we will probably include something in Astoria, and later on integrate with future versions of the EFx. -pablo

  • Anonymous
    May 26, 2007
    Hey Pablo! Increible, recuerdo ir a tus charlas en Bouchard 710 y ahora te veo x Channel9. Congrats! Saludos!