How can we validate a third party Amazon Resource Name (ARN) and get all applied IAM permissions or validate certain IAM permissions with the AWS SDK for Java?
I'm not aware of an option to actively retrieve all AWS IAM Permissions applied to an ARN for Cross-Account API Access Using IAM Roles (assuming that's what you are after).
However, you can use the AWS Security Token Service's (STS) DecodeAuthorizationMessage API action (resp. the AWS SDK for Java's decodeAuthorizationMessage(...) method) to get additional information about the authorization status of a request from an encoded message returned in response to an AWS request:
The decoded message includes the following type of information:
Whether the request was denied due to an explicit deny or due to the absence of an explicit allow. For more information, see Determining
Whether a Request is Allowed or Denied in Using IAM.
The principal who made the request.
The requested action.
The requested resource.
The values of condition keys in the context of the user's request.
This should at least allow you to validate certain permissions upfront and/or provide better guidance to your users for exceptions on request failures due to lack of permission.
Related
AWS has a large number of buckets that different users have access to. And there is a lambda function that selects data from s3 and gives it to the client via the Api Gateway. The client has the opportunity to specify in the api request from which bucket lambda should make a selection. But how to check that he is requesting exactly the bucket to which he has permission?
In the iam policies, I can only indicate that it can access a specific api resource, but the resource is shared by everyone. In lambda authorizer, I can't get information about the user's rights and permissions (or can I?).
Please tell me how you can solve this issue. Which way to move?
P.S. This should be the authorization of users in amazon, I can't give them my JWT with my data.
It would be your responsibility to code the authentication and permission requirements in your own code. The person making the request via API Gateway is not an IAM User, so AWS does not recognise them and cannot grant access based on the normal AWS permission model.
Your code would need to:
Recognise and authenticate the user
Determine what resources (buckets) that user is permitted to access
Only provide access to permitted resources
How to do this is your decision. You should start with a way of identifying and authenticating the user.
here is my problem: I have different users that can access an API using IAM authentication.
Every user send some data, that have to be put in a kinesis stream.
Every user has its own kinesis stream.
The gateway put the data on the correct stream based on a "streamName" field present in the request.
The stream consumers discard every data eventually put in the wrong stream (for instance in the case "user A" has specified "stream B").
This system is working fine, but it is not efficient.
I would like to enforce the right utilization of the streams to the api gateway level using IAM roles/policies.
If every user has a policy that grant him the access only to its kinesis stream, is there a way to configure the system to have the bad requests rejected without the put to the streams are performed?
In other words, I would like to have the API gateway to be granted the access to a particular kinesis stream based on the policy of the caller user.
Thank you for your help.
Gabriele
EDIT:
I think I found an hint for the solution. Here: https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html
In the light blue box at the and it states:
To enact access control to an AWS service, you can use either the caller-based permissions model, where a permissions policy is directly attached to the caller's IAM user or group, or the role-based permission model, where a permissions policy is attached to an IAM role that API Gateway can assume.
I think that the "caller-based permission model" could be the right way to do it.
You can setup a lambda authorizer at your API Gateway which will assign an IAM role to caller. I've attached the lambda authorizer docs and blueprint repo for your reference which will give you a better idea!
Lambda Authorizer Docs
Sample Lambda authorizers
I am using Terraform and I am trying to limit the access as much as possible, but I want to know what those limits are.
Terraform provides me a request ID for the request that had failed, but I am not sure where in the AWS console to go to put in that request ID and see what it was trying to do and what IAM policy it failed on.
In Given a failed AWS API request, how can I debug what permissions I need? they are looking for something more specific to S3, but I am doing a broader one with Terraform and I'm dealing with IAM resources and EC2 creation.
To check the request that was made and all detailed information, just use Cloudtrail, which let you check all the requests made to your account.
Go to https://console.aws.amazon.com/cloudtrail/home?region=us-east-1#/events
In the filter dropdown of Event choose "Event ID" and next type in the ID given from Terraform.
Let's say I have this usecase where the user is allowed to read from certain dynamodb table and getObject and putObject privileges in the S3.
Following items I have been able to establish-:
1. User is authenticated against cognito user pool
2. On successful auth, access token sent to API gateway
3. custom auth blueprint is used to validate and generate policy doc
Now what I am not able to understand is where and how do I mention the table/S3 permission specifics.
I went through the following documents/blogs
https://aws.amazon.com/blogs/compute/introducing-custom-authorizers-in-amazon-api-gateway/
http://docs.aws.amazon.com/apigateway/latest/developerguide/use-custom-authorizer.html
https://mobile.awsblog.com/post/Tx3JK25U7Z9EUIU/Integrating-Amazon-Cognito-User-Pools-with-API-Gateway
However, I am still confused as to how and when will the policy document, created by the custom auth lambda, be used? and a clarification on the flow would be highly appreciated.
We actually just launched native support for Cognito User Pools, which will validate the JWT vended by Cognito. However this will just do a simple ALLOW/DENY decision (allowing if the token is valid), so there is no concept of fine-grained permissions.
For custom authorizers, the policy that you generate is cached and can apply to the entire RestApi (or all methods that use the same authorizer). The policy allows you to set up fine-grained permissions just like you would with an IAM User/Role.
One use case would be a group-based permissions setup where the custom authorizer determines who the caller is and assigns a group policy (ex. admin, readonly, blocked, etc.) in the response to the first API call with that token. Those policies would set fine-grained permissions on specific resource/methods in the API. Then on subsequent API calls to any other resource/method in that share the same authorizer, the group policy would be applied.
So the benefits are:
Fine-grained permission policies associate with users, like IAM Users/Roles.
Caching the policy for the entire RestApi reduces Lambda invocations (cost and latency benefit).
Anybody could explain why the operation assume-role-with-saml needs some parameters that are already in the saml-assertion such as role-arn and principal-arn?
After some research I'm able to answer. I was asking why send the --role-arn parameter if it is already in the saml assertion. In fact the saml assertion can have more than one role so in the api request is necessary to identify which role should be assumed. I found the answer in this link
The Amazon documentation for assume-role-with-saml provides the information:
The --role-arnstring option identifies the role that the caller is assuming.
The --principal-arnstring option requires closer reading. Amazon says
The Amazon Resource Name (ARN) of the SAML provider in AWS IAM that describes the IdP.
The explanation for the latter is given a few paragraphs before:
Before your application can call assume-role-with-saml , you must configure your SAML identity provider (IdP) to issue the claims required by AWS.
The same page provides a link to Using Identity Providers, which explains the term:
Using identity providers, you can manage user identities outside of AWS, and you can give these external user identities permissions to use AWS resources in your account.
That is, you could associate an external user identity with a role using the --principal-arn option. The --role-arn option is not really optional, but a required parameter.
The saml-assertion (--saml-assertionstring) option) is additional "glue" which may be used to check permissions. Following the link in the description for this option to Configuring a Relying Party and Adding Claims, Amazon says
You also need to create appropriate claim rules in your IdP with AWS as a relying party. These rules map information about users and groups in your organization into appropriate SAML attributes. This lets you make sure that SAML authentication responses (assertions) from your IdP contain the necessary attributes that AWS uses in IAM policies to check permissions for federated users.
and in turn, that links to a page describing the assertions: Configure Assertions for the SAML Authentication Response