Secondly, this question too. But to add some features on the questions that Ward asked:
When protecting the requested services, two traditional questions arise:
1) Vertical security: which elements are currently registered users (based on user ID or roles), which is NOT allowed to be seen in the user interface. They must be removed from the request list. IMO, this can be done as part of the requested magic of ActionFilter by associating some exclusive logic with the returned IQueryable. 2) Horizontal security. Some models contain fields that are not suitable for user login to see (and / or edit). This is more difficult to handle since it is not just removing instances from the returned IQueryable. The returned class has a different form and therefore can be processed either by a json formatter that omits the fields based on security (which AFAIK tightens the breeze metadata), or you return the DTO, in this case, since the DTO does not exist in the metadata, this is not a complete (updated) class life cycle ? (I ask you not to state this)
I would like to see the built-in support or just implement the recipes for number 2). Perhaps some kind of sample code to modify client-side metadata to make DTOs perfectly executed with model objects. The VS 2012 SPA news templates (in the TodoList app) seem to be pushing DTO variants of the model object on both the request side and the insert / update. This is similar to traditional MVC models ...
Finally - I would add a request to automatically handle overflow security problems for inserts and updates. This is a response aspect 2). Some users do not have to edit some fields.