question

christian-heckelmann avatar image
0 Votes"
christian-heckelmann asked christian-heckelmann commented

ASP.NET Core WebAPI | Remove attributes from response according to the user's permission

Hi all,

we implement an ASP.NET Core WebAPI and get struggled with the following requirement: in addition to a record-based security trimming to ensure that only those records are returned the API caller is allowed to view, we need to implement a attribute-based security trimmng too.

 pulic class Dto {
     public string AttributesThatEveryoneCanSee { get; set; }
     public string AttributesThatNotEveryoneIsAllowedToSee { get; set; }
 }

The AttributesThatNotEveryoneIsAllowedToSee property should only be visible to specific users. The user interface shows or hides the attribute according to the user's permissions. But also the WebAPI should (not)deliver the attribute according to the user permissions.

So how to remove an object attribute from a WebAPI response? Is there any build-in ASP.NET Core WebAPI functionality or a stable/known library that could be utilized to achieve this requirement?

Regards,
Christian

dotnet-aspnet-core-webapi
· 2
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

I'm not sure I understand your requirement as the DTO you shared does not have an attribute and you have not shared how the DTO is populated.

But, it seems like you need a basic "if". If the user's role does not have access to the AttributesThatNotEveryoneIsAllowedToSee then do not populate the property, use a nullable property and set the property to null, or return a different DTO.

1 Vote 1 ·

Sorry I got attribute and property mixed up at the same time. I mean a class property.
'

But, it seems like you need a basic "if". If the user's role does not have access to the AttributesThatNotEveryoneIsAllowedToSee then do not populate the property

We want to avoid doing it by hand ourselves. Hence the question of a built-in functionality or a library. But yes that might be an option.


use a nullable property and set the property to null, or return a different DTO.

Unfortunately is not possible to use different DTO's because a configuration is used to dynamically determine which properties a user is allowed to see.

Using a nullable property does not remove the property from the response if its null or can this be specified? If so, I would be interested in a hint (to documentation for example).
0 Votes 0 ·
cooldadtx avatar image
1 Vote"
cooldadtx answered christian-heckelmann commented

For simple cases with one-off properties we just set the property to null if it shouldn't be visible. We also have configured out JSON serializer to not return null objects. Hence the property isn't sent back to clients that shouldn't see it. For this to make sense though we actually have a nested object that contains the sensitive data and hide the entire object. Note that if the property name itself isn't sensitive then just sending it back as null would be fine as well.

An alternative approach is to create a derived type that has the additional properties added. Then when you create your model to be returned you create one vs the other. This complicates the creation as you also need to convert your data to the model and know when it is one vs the other but it is doable. This is actually where models (not using business/data objects) comes in handy actually.

To make this more generally reusable I would probably consider creating a custom attribute that can be applied on properties based upon the "role" of the user. Note that there is already a Role attribute but I'm not sure you want to use it here. Irrelevant you could attribute the property(ies) that shouldn't be included. You then would need to create a custom type converter for the JSON serializer that takes the user roles and the type and doesn't write properties that it shouldn't.

Finally note that if the data is too different then you might consider creating a separate endpoint for the specialized data instead. This would greatly simplify things and avoid confusion and potential for someone accidentally exposing data they shouldn't.

· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

The use of nullable properties combined with the distinction between domain model and API model sounds good. Thank you for the detailed answer and for the input !

0 Votes 0 ·
AgaveJoe avatar image
1 Vote"
AgaveJoe answered christian-heckelmann commented

We want to avoid doing it by hand ourselves. Hence the question of a built-in functionality or a library. But yes that might be an option.

I'm not sure I understand the reluctance to use an "if" or filter. Typically access to secured data is handled in your database design, a query, business logic, etc. The community cannot see your code so we can only respond with vague approach ideas.

Using a nullable property does not remove the property from the response if its null or can this be specified? If so, I would be interested in a hint (to documentation for example).

That's not exactly true. You can configure the serializer library you're using to not include null properties.

Ignore all null-value properties


· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thank you for the link to the serialization configuration documentation. I will review the entire section of the documentation.

0 Votes 0 ·