FEATURE REQUEST: be able to conditionally omit properties from response payloads

[corranrogue9]

trafficstars

This request is coming from AGS workload teams, but likely is generalizable to other customers as well. For these workload teams, properly authorized clients are able to access hidden properties that other clients are not able to access. Because of this, these teams would like to "conditionally" omit these hidden properties from their response payloads. Currently, doing this requires implementing a custom serializer; it would be good to have an "out-of-the-box" solution for something like this, and possibly it would be beneficial for this to be generalized to other use-cases as well.

[julealgon]

@corranrogue9 I know this is not exactly the same, but I would also suggest looking into a possible integration between OData and Microsoft.Extensions.Compliance.Redaction, which provides a general-purpose redaction framework based on custom access levels etc.

Would be nice to see Microsoft integrating this more broadly including in OData:

• Microsoft.Extensions.Compliance.Redaction

Another area which I'd also like to see further integration is RBAC:

• Resource-based authorization in ASP.NET Core

Even with EntityFrameworkCore there is not any "native" support (for example, to perform authorization checks at the database level and only return/access "authorized" data).

Would also be great to see native RBAC integration with OData.

[xuzhg]

Similiar use case is to omit the null value properties. (See details at here using the customized serializer).

Question is that we'd figure the common/generic cases out and make a good design to support those cases. Maybe providing the services, maybe expose the vocabulary annotations, etc.

Besides, we'd also need to distinguish the properties omitted conditionally from the properties excluded using $select.

[anasik]

@xuzhg, @julealgon, @ElizabethOkerio We built a very detailed implementation of RBAC in our project that combines policies, action filters, custom serializers and dynamic EDM and EF models to achieve a bunch of different but similar use-cases.

We were able to achieve:

• Filtering out fields based on the request
• Filtering out rows based on request, and naturally, said records cannot be accessed from other HTTP Methods either unless explicitly allowed.
• Preventing users from updating certain fields based on their auth.
• Preventing users from inserting certain values based on their auth.

What's funny is that we started building it around the same time as this issue being opened. Lately I had been thinking about making a proposal and a POC with some of that.

At this point, I guess I am curious about what progress has been made on this since then? I would be more than willing to contribute here.