# How AWS enforcement code logic evaluates requests to allow or deny access
The AWS enforcement code decides whether a request sent to AWS should be allowed or denied. AWS evaluates all policies that are applicable to the request context. The following is a summary of the AWS policy evaluation logic.
+ By default, all requests are implicitly denied with the exception of the AWS account root user, which has full access.
+ Requests must be explicitly allowed by a policy or set of policies following the evaluation logic below to be allowed.
+ An explicit deny overrides an explicit allow.
Policy evaluation can differ depending on whether the request is within a single account or a cross-account request. For details about how a policy evaluation decision is made for an IAM role or user within a single account, see [Policy evaluation for requests within a single account](reference_policies_evaluation-logic_policy-eval-basics.md). For details about how a policy evaluation decision is made for cross-account requests, see [Cross-account policy evaluation logic](reference_policies_evaluation-logic-cross-account.md).
+ **Deny evaluation** – By default, all requests are denied. This is called an [implicit deny](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md). The AWS enforcement code evaluates all policies within the account that apply to the request. These include AWS Organizations SCPs and RCPs, resource-based policies, identity-based policies, IAM permissions boundaries, and session policies. In all those policies, the enforcement code looks for a `Deny` statement that applies to the request. This is called an [explicit deny](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md). If the enforcement code finds even one explicit deny that applies, the enforcement code returns a final decision of **Deny**. If there is no explicit deny, the enforcement code evaluation continues.
+ **AWS Organizations RCPs** – The enforcement code evaluates AWS Organizations resource control policies (RCPs) that apply to the request. RCPs apply to resources of the account where the RCPs are attached. If the enforcement code does not find any applicable `Allow` statements in the RCPs, the enforcement code returns a final decision of **Deny**. Note that an AWS managed policy called `RCPFullAWSAccess` is automatically created and attached to every entity in your organization including the root, each OU, and AWS account when RCPs are enabled. `RCPFullAWSAccess` can't be detached, so there will always be an `Allow` statement. If there is no RCP, or if the RCP allows the requested action, the enforcement code evaluation continues.
+ **AWS Organizations SCPs** – The enforcement code evaluates AWS Organizations service control policies (SCPs) that apply to the request. SCPs apply to principals of the account where the SCPs are attached. If the enforcement code does not find any applicable `Allow` statements in the SCPs, the enforcement code returns a final decision of **Deny**. If there is no SCP, or if the SCP allows the requested action, the enforcement code evaluation continues.
+ **Resource-based policies** – Within the same account, resource-based policies impact policy evaluation differently depending on the type of principal accessing the resource, and the principal that is allowed in the resource-based policy. Depending on the type of principal, an `Allow` in a resource-based policy can result in a final decision of `Allow`, even if an implicit deny in an identity-based policy, permissions boundary, or session policy is present.
For most resources, you only need an explicit `Allow` for the principal in either an identity-based policy or a resource-based policy to grant access. [IAM role trust policies](access_policies-cross-account-resource-access.md#access_policies-cross-account-delegating-resource-based-policies) and [KMS key policies](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) are exceptions to this logic, because they must explicitly allow access for [principals](reference_policies_elements_principal.md). Resource-based policies for services other than IAM and AWS KMS may also require an explicit `Allow` statement within the same account to grant access. For more information, see the documentation for the specific service you're working with.
For single account policy evaluation requests, resource-based policy logic differs from other policy types if the specified principal is an IAM user, an IAM role, or a session principal. Session principals include [IAM role sessions](reference_policies_elements_principal.md#principal-role-session) or an [AWS STS federated user principals](reference_policies_elements_principal.md#sts-session-principals). If a resource-based policy grants permission directly to the IAM user or the session principal that is making the request, then an implicit deny in an identity-based policy, a permissions boundary, or a session policy does not impact the final decision.
+ **IAM role** – Resource-based policies that grant permissions to an IAM role ARN are limited by an implicit deny in a permissions boundary or session policy. You can specify the role ARN in the Principal element or the `aws:PrincipalArn` condition key. In both cases, the principal that makes the request is the **IAM role session**.
Permissions boundaries and session policies do not limit permissions granted using the `aws:PrincipalArn` condition key with a wildcard(\$1) in the Principal element, unless the identity-based policies contain an explicit deny. For more information, see [IAM role principals](reference_policies_elements_principal.md#principal-roles).
**Example role ARN**
```
arn:aws:iam::111122223333:role/examplerole
```
+ **IAM role session** – Within the same account, resource-based policies that grant permissions to an IAM role session ARN grant permissions directly to the assumed role session. Permissions granted directly to a session are not limited by an implicit deny in an identity-based policy, a permissions boundary, or session policy. When you assume a role and make a request, the principal making the request is the IAM role session ARN and not the ARN of the role itself. For more information, see [Role session principals](reference_policies_elements_principal.md#principal-role-session).
**Example role session ARN**
```
arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname
```
+ **IAM user** – Within the same account, resource-based policies that grant permissions to an IAM user ARN (that is not a federated user session) are not limited by an implicit deny in an identity-based policy or permissions boundary.
**Example IAM user ARN**
```
arn:aws:iam::111122223333:user/exampleuser
```
+ **AWS STS federated user principal** – A federated user session is a session created by calling [`GetFederationToken`](id_credentials_temp_request.md#api_getfederationtoken). When a federated user makes a request, the principal making the request is the federated user ARN and not the ARN of the IAM user who federated. Within the same account, resource-based policies that grant permissions to a federated user ARN grant permissions directly to the session. Permissions granted directly to a session are not limited by an implicit deny in an identity-based policy, a permissions boundary, or session policy.
However, if a resource-based policy grants permission to the ARN of the IAM user who federated, then requests made by the federated user during the session are limited by an implicit deny in a permission boundary or session policy.
**Example federated user session ARN**
```
arn:aws:sts::111122223333:federated-user/exampleuser
```
+ **Identity-based policies** – The enforcement code checks the identity-based policies for the principal. For an IAM user, these include user policies and policies from groups to which the user belongs. If there are no identity-based policies or no statements in identity-based policies that allow the requested action, then the request is implicitly denied and the enforcement code returns a final decision of **Deny**. If any statement in any applicable identity-based policies allows the requested action, the code evaluation continues.
+ **IAM permissions boundaries** – The enforcement code checks whether the IAM entity that is used by the principal has a permissions boundary. If the policy that is used to set the permissions boundary does not allow the requested action, then the request is implicitly denied. The enforcement code returns a final decision of **Deny**. If there is no permissions boundary, or if the permissions boundary allows the requested action, the code evaluation continues.
+ **Session policies** – The enforcement code checks whether the principal is a session principal. Session principals include an IAM role session or an AWS STS federated user session. If the principal is not a session principal, the enforcement code returns a final decision of **Allow**.
For session principals, the enforcement code checks whether a session policy was passed in the request. You can pass a session policy while using the AWS CLI or AWS API to get temporary credentials for a role or an AWS STS federated user principal. If you didn't pass a session policy, a default session policy is created and the enforcement code returns a final decision of **Allow**.
+ If a session policy is present and does not allow the requested action, then the request is implicitly denied. The enforcement code returns a final decision of **Deny**.
+ The enforcement code checks whether the principal is a role session. If the principal is a role session, then the request is **Allowed**. Otherwise, the request is implicitly denied and the enforcement code returns a final decision of **Deny**.
+ If a session policy is present and allows the requested action, then the enforcement code returns a final decision of **Allow**.
# Policy evaluation for requests within a single account
## Policy evaluation for an IAM role
The following flow chart provides details about how a policy evaluation decision is made for an IAM role within a single account.
![\[Evaluation flow chart for an IAM role within a single account\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/PolicyEvaluationSingleAccountRole.png)
## Policy evaluation for an IAM user
The following flow chart provides details about how a policy evaluation decision is made for an IAM user within a single account.
![\[Evaluation flow chart for an IAM user within a single account\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/PolicyevaluationSingleAccountUser.png)
## Example identity-based and resource-based policy evaluation
The most common types of policies are identity-based policies and resource-based policies. When access to a resource is requested, AWS evaluates all the permissions granted by the policies for **at least one Allow** within the same account. An explicit deny in any of the policies overrides the allow.
**Important**
If either the identity-based policy or the resource-based policy within the same account allows the request and the other doesn't, the request is still allowed.
Assume that Carlos has the user name `carlossalazar` and he tries to save a file to the `amzn-s3-demo-bucket-carlossalazar-logs` Amazon S3 bucket.
Also assume that the following policy is attached to the `carlossalazar` IAM user.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowS3ListRead",
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:GetAccountPublicAccessBlock",
"s3:ListAccessPoints",
"s3:ListAllMyBuckets"
],
"Resource": "arn:aws:s3:::*"
},
{
"Sid": "AllowS3Self",
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*",
"arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar"
]
},
{
"Sid": "DenyS3Logs",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::*log*"
}
]
}
```
------
The `AllowS3ListRead` statement in this policy allows Carlos to view a list of all of the buckets in the account. The `AllowS3Self` statement allows Carlos full access to the bucket with the same name as his user name. The `DenyS3Logs` statement denies Carlos access to any S3 bucket with `log` in its name.
Additionally, the following resource-based policy (called a bucket policy) is attached to the `amzn-s3-demo-bucket-carlossalazar` bucket.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/carlossalazar"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*",
"arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar"
]
}
]
}
```
------
This policy specifies that only the `carlossalazar` user can access the `amzn-s3-demo-bucket-carlossalazar` bucket.
When Carlos makes his request to save a file to the `amzn-s3-demo-bucket-carlossalazar-logs` bucket, AWS determines what policies apply to the request. In this case, only the identity-based policy and the resource-based policy apply. These are both permissions policies. Because no permissions boundaries apply, the evaluation logic is reduced to the following logic.
![\[Evaluation flow chart\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/EffectivePermissionsShort.png)
AWS first checks for a `Deny` statement that applies to the context of the request. It finds one, because the identity-based policy explicitly denies Carlos access to any S3 buckets used for logging. Carlos is denied access.
Assume that he then realizes his mistake and tries to save the file to the `amzn-s3-demo-bucket-carlossalazar` bucket. AWS checks for a `Deny` statement and does not find one. It then checks the permissions policies. Both the identity-based policy and the resource-based policy allow the request. Therefore, AWS allows the request. If either of them explicitly denied the statement, the request would have been denied. If one of the policy types allows the request and the other doesn't, the request is still allowed.
# Cross-account policy evaluation logic
You can allow a principal in one account to access resources in a second account. This is called cross-account access. When you allow cross-account access, the account where the principal exists is called the *trusted* account. The account where the resource exists is the *trusting* account.
To allow cross-account access, you attach a resource-based policy to the resource that you want to share. You must also attach an identity-based policy to the identity that acts as the principal in the request. The resource-based policy in the trusting account must specify the principal of the trusted account that will have access to the resource. You can specify the entire account or its IAM users, AWS STS federated user principals, IAM roles, or assumed-role sessions. You can also specify an AWS service as a principal. For more information, see [How to specify a principal](reference_policies_elements_principal.md#Principal_specifying).
The principal's identity-based policy must allow the requested access to the resource in the trusting service. You can do this by specifying the ARN of the resource.
In IAM, you can attach a resource-based policy to an IAM role to allow principals in other accounts to assume that role. The role's resource-based policy is called a role trust policy. After assuming that role, the allowed principals can use the resulting temporary credentials to access multiple resources in your account. This access is defined in the role's identity-based permissions policy. To learn how allowing cross-account access using roles is different from allowing cross-account access using other resource-based policies, see [Cross account resource access in IAM](access_policies-cross-account-resource-access.md).
**Important**
Other services can affect the policy evaluation logic. For example, AWS Organizations supports [service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) and [resource control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) that can be applied to principals and resources in one or more accounts. AWS Resource Access Manager supports [policy fragments](https://docs.aws.amazon.com/ram/latest/userguide/permissions.html) that control which actions that principals are allowed to perform on resources that are shared with them.
## Determining whether a cross-account request is allowed
For cross-account requests, the requester in the trusted `AccountA` must have an identity-based policy. That policy must allow them to make a request to the resource in the trusting `AccountB`. Additionally, the resource-based policy in `AccountB` must allow the requester in `AccountA` to access the resource.
When you make a cross-account request, AWS performs two evaluations. AWS evaluates the request in the trusting account and the trusted account. For more information about how a request is evaluated within a single account, see [How AWS enforcement code logic evaluates requests to allow or deny access](reference_policies_evaluation-logic_policy-eval-denyallow.md). The request is allowed only if both evaluations return a decision of `Allow`.
![\[Cross-account evaluation\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/policy_cross-account-eval-simple.png)
1. When a principal in one account makes a request to access a resource in another account, this is a cross-account request.
1. The requesting principal exists in the trusted account (`AccountA`). When AWS evaluates this account, it checks the identity-based policy and any policies that can limit an identity-based policy. For more information, see [Evaluating identity-based policies with permissions boundaries](reference_policies_evaluation-logic.md#policy-eval-basics-id-bound).
1. The requested resource exists in the trusting account (`AccountB`). When AWS evaluates this account, it checks the resource-based policy that is attached to the requested resource and any policies that can limit a resource-based policy. For more information, see [Evaluating identity-based policies with resource-based policies](reference_policies_evaluation-logic.md#policy-eval-basics-id-rdp).
1. AWS allows the request only if both account policy evaluations allow the request.
The following flow chart provides a more detailed illustration of how a policy evaluation decision is made for a cross-account request. Again, AWS allows the request only if both account policy evaluations allow the request.
![\[Detailed cross-account policy evaluation\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/PolicyEvaluationCrossAccount.png)
## Example cross-account policy evaluation
The following example demonstrates a scenario where a role in one account is granted permissions by a resource-based policy in a second account.
Assume that Carlos is a developer with an IAM role named `Demo` in account 111111111111. He wants to save a file to the `amzn-s3-demo-bucket-production-logs` Amazon S3 bucket in account 222222222222.
Also assume that the following policy is attached to the `Demo` IAM role.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowS3ListRead",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Sid": "AllowS3ProductionObjectActions",
"Effect": "Allow",
"Action": "s3:*Object*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*"
},
{
"Sid": "DenyS3Logs",
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::*log*",
"arn:aws:s3:::*log*/*"
]
}
]
}
```
------
The `AllowS3ListRead` statement in this policy allows Carlos to view a list of all of the buckets in Amazon S3. The `AllowS3ProductionObjectActions` statement allows Carlos full access to objects in the `amzn-s3-demo-bucket-production` bucket.
Additionally, the following resource-based policy (called a bucket policy) is attached to the `amzn-s3-demo-bucket-production` bucket in account 222222222222.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject*",
"s3:PutObject*",
"s3:ReplicateObject",
"s3:RestoreObject"
],
"Principal": { "AWS": "arn:aws:iam::111111111111:role/Demo" },
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*"
}
]
}
```
------
This policy allows the `Demo` role to access objects in the `amzn-s3-demo-bucket-production` bucket. The role can create and edit, but not delete the objects in the bucket. The role can't manage the bucket itself.
When Carlos makes his request to save a file to the `amzn-s3-demo-bucket-production-logs` bucket, AWS determines what policies apply to the request. In this case, the identity-based policy attached to the `Demo` role is the only policy that applies in account `111111111111`. In account `222222222222`, there is no resource-based policy attached to the `amzn-s3-demo-bucket-production-logs` bucket. When AWS evaluates account `111111111111`, it returns a decision of `Deny`. This is because the `DenyS3Logs` statement in the identity-based policy explicitly denies access to any log buckets. For more information about how a request is evaluated within a single account, see [How AWS enforcement code logic evaluates requests to allow or deny access](reference_policies_evaluation-logic_policy-eval-denyallow.md).
Because the request is explicitly denied within one of the accounts, the final decision is to deny the request.
![\[Request to amzn-s3-demo-bucket-production-logs bucket\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/policy_cross-account-eval-example.png)
Assume that Carlos then realizes his mistake and tries to save the file to the `Production` bucket. AWS first checks account `111111111111` to determine if the request is allowed. Only the identity-based policy applies, and it allows the request. AWS then checks account `222222222222`. Only the resource-based policy attached to the `Production` bucket applies, and it allows the request. Because both accounts allow the request, the final decision is to allow the request.
![\[Request to Production bucket\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/policy_cross-account-eval-example-correct.png)