User calling REST APIs on behalf of a different user

Question

Here's an example:

GET /posts
POST /posts
GET /posts/{post_id}
PUT /posts/{post_id}

This api is being used by SUPER_ADMIN as well as CONTENT_WRITERS. Its working great. If user is logged in as a SuperAdmin, he sees all the post, and if user is logged in as ContentWriter he sees only his post.

But, now the requirement is added, where SuperAdmin should be able to do CRUD opertations on behalf of any ContentWriter.

I added these APIs for that:

GET /user/{user_id}/posts
POST /user/{user_id}/posts
GET /user/{user_id}/posts/{post_id}
PUT /user/{user_id}/posts/{post_id}

Its working fine too. But the problem here is, now there are too many APIs/Controllers to maintain. Although, the controllers use the same service for that.

My question is, am I going to a right direction? Or is there any other best practices for this?

UPDATE 1

The idea here is somewhat similar to impersonation.

Answer 1

But as far as I can tell, what you are really trying to do is analogous to having Alice invoke

sudo -u bob ls /home/bob

I think you can reasonably argue one of two ways

First, that this is a different resource; it shares a common set of representations with ls /home/bob, but the authorization rules are different. On the web, that would mean two different identifiers

/home/bob
/su/bob/home/bob

In effect, we have a new protocol, so we create new resources to support that protocol.

The other argument is that these are the same resource, and the difference between the two cases is the Authorization header. That feels right? but I can't find any examples that do this.

You can find some examples where people have implemented a similar idea using custom http headers. For example https://www.linkedin.com/pulse/jira-rest-api-user-impersonation-marjan-sterjev/

Because of the lack of clear precedent, I would recommend continuing with the first approach.

Answer 2

I'm not an expert at this, but since you are trying to make requests on another users behalf, from the APIs point of view the requests come from that user, not from the Admin.

Have you considered adding an admin route that allows the admin user to obtain a session token for another user? That will allow the admin to send the requests to the endpoints you already have using that other users token.

Answer 3

A requirement to allow admins to impersonate users shouldn't require any more API endpoints than already exist in the system. This should be handled with additional form fields on your create/edit POST/PUTs rather than entirely different endpoints. You would need to add some validation that these fields are only populated when the request comes from an admin, or to ignore them for non admins. You should already have the authorization mechanism in place to recognize an admin request from a non admin, this functionality can be viewed as a slight extension to that. While not required for fulfilling the business need, it would also be a good idea to modify your database/persistence layer to track both who made an update and who should be displayed as an update. This will prove useful should an admin abuse their power.

Answer 4

I think a key thing will be your exact requirements around what it means to "post on behalf of another user"

But, assuming its just the author byline I would simply have a property on the Post object

class Post
{
    public string AuthoredByUserId {get;set;}
    ....
}

Now in your controller you can check whether AuthoredByUserId is the same as the user submitting the post and either allow it for super users or disallow it from normal users.

Having said that, personally I would still add a seperate endpoint simply so I can use built in authentication per endpoint methods, rather than having to code an authentication check eg.

[Authorise(Roles="ContentWriter")]
public Action AddPost(Post)
{
    ...error if AuthoredByUserId != the users Id
}

[Authorise(Roles="SUPER_ADMIN")]
public Action AddPostForAnotherUser(Post)
{
    ..ignore the userid validation
}