Access control based on data filtering instead of request authorization

3
votes

Standard way to control access in a multi user service is to provide as many service methods as necessary, where each service method has concrete results and access permissions.

For example,

  1. Moderator is authorized to call GetModerationAwaitingPosts service method to access posts from any visitor awaiting for moderation

  2. Visitor is authorized to call GetOwnedPosts service method to access only his own posts including draft and moderation awaiting posts

  3. Visitor is authorized to call GetModeratedPosts service method to access only moderated posts from all visitors

But there may be another approach - single service method GetPosts to request posts that the requester is allowed to see.

  1. Any logged in user is authorized to call this method.

  2. Posts are first filtered according to the role of the caller.

  3. Then posts are filtered according to parameters passed in GetPosts method or filtered on client side.

This approach is used, for example, in WCF Data Services through Query Interceptors.

How is approach to filter data based on user inside service method named and treated in different architectures and methodologies, like SOA, REST, CQRS? Is it a solid solution?

Are there any books / articles where difference between these approaches is considered in details?

As for me, I find it really strange and unusual when results of a request depend on the requester.

1
restlanguage-agnosticauthorizationsoaaccess-control
what did you end up doing? Did you end up creating a single endpoint that shows the requester what they are allowed to see? Or did you create separate endpoints with separate access control policies, and implement the logic on the client side? - alexw

1 Answers

1
votes

Yes, there is an access control paradigm called attribute based access control (ABAC, ) which implements data-based, context-based authorization that uses information about the user (role, department, age, location...) about the resource (owner, classification, type...) action (view, edit, delete), and context (time, IP address...)

ABAC will let you implement policies e.g.:

  • Medical use cases
    • doctors can view the medical records of patients they are assigned to
    • nurses can edit the medical journal of a patient in the same deparment
  • Finance use cases
    • A teller can view the accounts of those customers in their branch
    • A teller can approve a transfer up to their approval limit

ABAC provides an architecture as depicted below.

ABAC Architecture - Axiomatics

In the architecture you have the notion of a PEP or policy enforcement point which you can use to secure anything from GUIs, APIs, web services, micro-services, ESBs, and databases.

The PEP calls out to the PDP or policy decision point which is at the core of the architecture. The PDP uses a set of policies to determine whether access should be granted or denied. It can also use external sources of attributes, PIP or policy information points, to help in determining whether access should indeed be granted.

There is one language which implements ABAC today. This language is called XACML (). XACML gives you:

  • the architecture
  • a policy language
  • a request / response scheme

With XACML you can create JSON authorization requests, send them off to the PDP and get a JSON response back. It's an extremely lightweight way of getting a response back.

This means you can either

  • grant or deny access to a given record, or
  • filter those records a user can get access to as stated in your requirement