asp.net mvc 4 - How to use a MVC WebAPI OData endpoint securely?

Question

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 non-authenticated users).

I setup role-based authentication to this path in the web.config with:

  <location path="odata">
    <system.web>
      <authorization>
        <allow roles="WaitConfirmation, etc...."/>
      </authorization>
    </system.web>
  </location>

When a user logs in, I don't use the OData endpoint for authentication (primarily because I need to figure out how to secure this).

I use EntityFramework to validate the user, return the user object, and hydrate the membership/role details.

Is this the standard method to follow to allow users' data calls to go through WebAPI paths, and if so, how do you ensure that any requests WebAPI requests (remember, I'm using OData) only return data related to the logged in user?

I have only read about "securing" OData services by means of decorating controller methods (ie. [Queryable(PageSize=10)]) in order to limit DOS attacks, etc, but not how to ensure that a if a common parameter, (ie. UserID=[this logged in user id]) is not included, to include it on all EF requests.

Answer 1

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