We have the Web Api 2 OData v3 service, for which we need to implement a rather complicated authorization. We use Breeze in our client code, and when the version of Breeze OData v4 is released, we upgrade our API to OData v4, so the solution should be able to work with both versions of OData.
This diagram gives a very simple view of the type of entity model we are working with (sorry, not enough reputation points for the image):
ServiceCompany | | /|\ Manufacturer | | /|\ Site | | /|\ SiteArea ------- | | | | /|\ /|\ Equipment Instrument | | /|\ Channel
A SiteArea has the "OperatingFunction" property - it shows what stage of the production process takes place at this place.
User may be
- a person sitting at the manufacturer’s level and having access to all his site data.
- a person sitting at the level of the Manufacturer and having access to some, but not all of their SiteAreas sites, and therefore only a subsection of their SiteArea data
- a person sitting at the ServiceCompany level who has access to some manufacturers, and within that, only some Sites within these Manufacturers, and possibly only certain SiteArea Operations.
A request will be requested for channel data, and we must necessarily return or update (depending on the type of request) data that a person can influence.
At the initial research, the obvious choice for implementing this was QueryInterceptors and ChangeInterceptors, which means that we could add additional filter preferences based on the claims sent with the request. However, it seems that Query / ChangeInterceptors are part of Wcf, not WebApi, and in addition, they are only part of the implementation of OData v1-3 Wcf, while there is no OData v4.
Of course, we could write filter code in each method, but it really seems like it would be a nasty way to implement something, which in fact is a cross-reference problem.
We examined EF6 interceptors, but came to the conclusion that they are too far from the stack, ideally we do not want to deal with SQL command code.
We briefly examined the question of whether to use an authorization template based on the role / task and came to the firm conclusion that this will not work for us, since it will be too compressed for future developments and will not work in our scaling plans.
In fact, we came to the conclusion that we need to implement our own QueryInterceptorAttribute, but thought it was worth asking if we had missed something before trying to invent the wheel.
Thanks.
Edit: I forgot to mention that another option might be to use the Decorator template, we use Unity and with this we can add the functions we need: Interception Unity