CODEWITHSUNDEEP
amazon-web-serviceslambdaaws-api-gatewayamazon-cognitoserverless-framework
Philipp
Philipp

Reputation: 807

AWS Serverless Protect API Paths for different User Roles

right now my head is exploding from all the information about AWS. :) So I need your help.

I have the following architecture on AWS: API Gateway, Lambda, Cognito. I am using the serverless framework to configure everything. On Lambda several functions are deployed. Let's say the API and functions are like:

GET /user
GET /vehicle
POST /vehicle

I have two types of users A and B. A is an admin and should access everything, but B is restricted to certain paths, e.g.

GET /user >>> only A
GET /vehicle >>> B
POST /vehicle >>> only A

How can I achieve this with Cognito, API Gateway and Lambda.

The information/ideas I've found so far are:

Which is the best way to go? Or is there a better solution? Nevertheless a good example would be nice. So far I've found only examples with like 50 lines of code, which do not suit my case. So actually my problem might be that I don't know how and where to start..

Upvotes: 2

Views: 843

Answers (1)

dege
dege

Reputation: 2949

This might be a bit bias because I've used custom authorizers in the past. But they are probably the most flexible solution, from those you mentioned.

I've actually used the custom authorizer with cognito user pools before there was a cognito authorizer.

At the time this https://aws.amazon.com/blogs/mobile/integrating-amazon-cognito-user-pools-with-api-gateway/ helped me a lot to get started.

Later i found that i should take advantage of the caching of the policies sent by the authorizer once I was doing a lot of validation and since user permissions didn't change that often. For that i had to send as a response a policy that would cover all the endpoints that were allowed to be invoked by the authenticated user.

EDIT: On the custom authorizer you are able to check the user information by calling cognito. After that you can give the policies for the user if it is a default user

{   "principalId": "yyyyyyyy", // The principal user identification associated with the token sent by the client.   "policyDocument": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Action": "execute-api:Invoke",
        "Effect": "Allow|Deny",
        "Resource": "arn:aws:execute-api:{regionId}:{accountId}:{appId}/{stage}/GET/user"
      }
    ]   } }

And for admins you just send another Policies

{
  "principalId": "yyyyyyyy", // The principal user identification associated with the token sent by the client.
  "policyDocument": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Action": "execute-api:Invoke",
        "Effect": "Allow|Deny",
        "Resource": "arn:aws:execute-api:{regionId}:{accountId}:{appId}/{stage}/GET/user"
      },
   {
        "Action": "execute-api:Invoke",
        "Effect": "Allow|Deny",
        "Resource": "arn:aws:execute-api:{regionId}:{accountId}:{appId}/{stage}/*/vehicle"
      }
    ]
  }
}

Upvotes: 2

Related Questions