I have an OData endpoint defined at ~/odata/
, which doesn\'t need to be accessed unless a user has been authenticated (in fact, how would you secure this for no
So the major hurdle to get past is thinking that all WebAPI requests (using the OData syntax) are stateless. Of course, in a stateless environment this makes this more difficult.
However, with the WebAPI endpoint secured through web.config
requiring an authenticated (stateful) request, we should be able to grab the UserName (or UserID or any other custom property when using a custom membership provider), by something like var userId = ((CustomIdentity)HttpContext.Current.User.Identity).UserId
.
Once this is established, we will need to add something like "WHERE UserID = userId;" before the request is issued:
var unitOfWork = new Repository.UnitOfWork(_db);
var users = options.ApplyTo(unitOfWork.Repository<MyTable>().Queryable
.Include(w => w.NavigationProperty1)
.Where(u => u.UserId == UserContext.Identity.UserId)
.OrderBy(o => o.SomeProperty))
.Cast<MyTable>().ToList();
Additional suggestions welcome.
At your API layer, you want to implement authorisation schemes that allow you to generate claims. For Web API, you can use the new OAuth 2.0 OWIN Middleware if you are using Web API 2.0 for this. Although not too well documented, it is fairly straightforward to use.
You then want to implement a Services layer that handles authorisation rules based upon claims about the identity accessing it (e.g. roles or other types of claim information). You can pass Claims Principal or similar objects from your API layer to the Services layer, and if once authorised, you need further auditing at lower levels of your code, you can always pass the claims principal around as your "user context".
Within your services layer, you'll generally want to take an approach where you have an Authorization Manager or similar that moves assessment and enforcement of authorisation logic to a central place, whilst defining your authorisation rules declaratively - have a look at this article for more information: http://visualstudiomagazine.com/Articles/2013/09/01/Going-Beyond-Usernames-and-Roles.aspx?Page=1