# Policy evaluation logic
When a principal tries to use the AWS Management Console, the AWS API, or the AWS CLI, that principal sends a *request* to AWS. When an AWS service receives the request, AWS completes several steps to determine whether to allow or deny the request.
1. **Authentication** – AWS first authenticates the principal that makes the request, if necessary. This step is not necessary for a few services, such as Amazon S3, that allow some requests from anonymous users.
1. **[Processing the request context](reference_policies_evaluation-logic_policy-eval-reqcontext.md)** – AWS processes the information gathered in the request to determine which policies apply to the request.
1. **[How AWS enforcement code logic evaluates requests to allow or deny access](reference_policies_evaluation-logic_policy-eval-denyallow.md)** – AWS evaluates all of the policy types and the order of the policies affects how they are evaluated. AWS then processes the policies against the request context to determine whether the request is allowed or denied.
## Evaluating identity-based policies with resource-based policies
Identity-based policies and resource-based policies grant permissions to the identities or resources to which they are attached. When an IAM entity (user or role) requests access to a resource within the same account, AWS evaluates all the permissions granted by the identity-based and resource-based policies. The resulting permissions are the union of the permissions of the two types. If an action is allowed by an identity-based policy, a resource-based policy, or both, then AWS allows the action. An explicit deny in either of these policies overrides the allow.
![\[Evaluation of identity-based policies and resource-based policies\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/permissions_policies_effective.png)
## Evaluating identity-based policies with permissions boundaries
When AWS evaluates the identity-based policies and permissions boundary for a user, the resulting permissions are the intersection of the two categories. That means that when you add a permissions boundary to a user with existing identity-based policies, you might reduce the actions that the user can perform. Alternatively, when you remove a permissions boundary from a user, you might increase the actions they can perform. An explicit deny in either of these policies overrides the allow. To view information about how other policy types are evaluated with permissions boundaries, see [Evaluating effective permissions with boundaries](access_policies_boundaries.md#access_policies_boundaries-eval-logic).
![\[Evaluation of identity-based policies and permissions boundaries\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/permissions_boundary.png)
## Evaluating identity-based policies with AWS Organizations SCPs or RCPs
When a user belongs to an account that is a member of an organization and accesses a resource that doesn't have a resource-based policy configured, the resulting permissions are the intersection of the user's policies, service control policies (SCPs), and resource control policy (RCP). This means that an action must be allowed by all three policy types. An explicit deny in the identity-based policy, an SCP, or an RCP overrides the allow.
![\[Evaluation of identity-based policies and SCPs or RCPs\]](http://docs.aws.amazon.com/IAM/latest/UserGuide/images/permissions_scp-idp.png)
You can learn [whether your account is a member of an organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_details.html#orgs_view_account) in AWS Organizations. Organization members might be affected by an SCP or RCP. To view this data using the AWS CLI command or AWS API operation, you must have permissions for the `organizations:DescribeOrganization` action for your AWS Organizations entity. You must have additional permissions to perform the operation in the AWS Organizations console. To learn whether an SCP or RCP is denying access to a specific request, or to change your effective permissions, contact your AWS Organizations administrator.
# Processing the request context
Request context
When AWS evaluates and authorizes a request, it assembles the request information into a *request context*. The request context contains any information that can be used in policy evaluation.
+ **Principal** – The user, role, or federated user principal that sent the request. Information about the principal includes the policies that are associated with that principal.
+ **Actions** – One or more actions that the principal wants to perform.
+ **Resources** – One or more AWS resource objects upon which the actions or operations are performed.
+ **Resource data** – Data related to the resource that is being requested. This can include information such as a DynamoDB table name or a tag on an Amazon EC2 instance.
+ **Environment data** – Information about the IP address, user agent, SSL enabled status, or the time of day.
This information is compared against applicable policies to determine whether to allow or deny the request. You can organize this property information using the **Principal**, **Action**, **Resource**, and **Condition** (PARC) model to better understand how AWS policies are evaluated.
## Understanding the PARC model
The PARC model represents the request context based on the four JSON elements in the policy language:
+ [Principal](reference_policies_elements_principal.md) – The entity making the request. A principal represents a human user or programmatic workload that can be authenticated and then authorized to perform actions in AWS accounts.
+ [Action](reference_policies_elements_action.md) – The operation being performed. Often the action will map to an API action.
+ [Resource](reference_policies_elements_resource.md) – The AWS resource on which the action is being performed.
+ [Condition](reference_policies_elements_condition.md) – Additional constraints that must be met for the request to be allowed.
The following shows an example of how the PARC model might represent a request context:
```
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:UserId=AIDA123456789EXAMPLE:BobsSession
- aws:PrincipalAccount=123456789012
- aws:PrincipalOrgId=o-example
- aws:PrincipalARN=arn:aws:iam::AIDA123456789EXAMPLE:role/HR
- aws:MultiFactorAuthPresent=true
- aws:CurrentTime=...
- aws:EpochTime=...
- aws:SourceIp=...
- aws:PrincipalTag/dept=123
- aws:PrincipalTag/project=blue
- aws:RequestTag/dept=123
```
## Importance of the request context
Understanding the request context and how it interacts with policy evaluation is crucial for:
+ Troubleshooting access issues
+ Designing effective and secure policies
+ Understanding the full scope of permissions granted by a policy
+ Predicting the outcome of policy evaluations in different scenarios
By visualizing the request context using the PARC model, you can more easily understand how AWS makes authorization decisions and design your policies more effectively.
## How AWS uses the request context
When evaluating policies, AWS compares the information in the request context with the information specified in all applicable policies. This includes identity-based policies, resource-based policies, IAM permissions boundaries, Organizations SCPs, Organizations RCPs, and session policies.
For each policy type, AWS uses the request context to check:
+ Whether the policy applies to the request based on the principal.
+ Whether the requested action is allowed on the specified resource.
+ Whether any conditions specified in the policy are met by the request context.
How AWS evaluates policies depends on the types of policies that apply to the request context. These policy types are available for use within a single AWS account. For more information about these policy types, see [Policies and permissions in AWS Identity and Access Management](access_policies.md). To learn how AWS evaluates policies for cross-account access, see [Cross-account policy evaluation logic](reference_policies_evaluation-logic-cross-account.md).
+ **AWS Organizations resource control policies (RCPs)** – AWS Organizations RCPs specify the maximum available permissions for resources within accounts in an organization or organizational unit (OU). RCPs apply to resources in member accounts and impact the effective permissions for principals, including the AWS account root user, regardless of whether the principals belong to your organization. RCPs don't apply to resources in the organization management account and to calls made by service-linked roles. If an RCP is present, permissions granted by identity-based and resource-based policies to resources in your member accounts are only effective if the RCP allows the action.
+ **AWS Organizations service control policies (SCPs)** – AWS Organizations SCPs specify the maximum available permissions for principals within accounts in an organization or organizational unit (OU). SCPs apply to principals in member accounts, including each AWS account root user. If an SCP is present, permissions granted by identity-based and resource-based policies to principals in your member accounts are only effective if the SCP allows the action. The only exceptions are principals in the organization management account and service-linked roles.
+ **Resource-based policies** – Resource-based policies grant permissions for principals specified in the policy. The permissions define what the principal can do with the resource to which the policy is attached.
+ **Permissions boundaries** – Permissions boundaries are a feature that sets the maximum permissions that an identity-based policy can grant to an IAM entity (user or role). When you set a permissions boundary for an entity, the entity can perform only the actions that are allowed by both its identity-based policies and its permissions boundary. In some cases, an implicit deny in a permissions boundary can limit the permissions granted by a resource-based policy. For more information, see [How AWS enforcement code logic evaluates requests to allow or deny access](reference_policies_evaluation-logic_policy-eval-denyallow.md).
+ **Identity-based policies** – Identity-based policies are attached to an IAM identity (user, group of users, or role) and grant permissions to IAM entities (users and roles). If only identity-based policies apply to a request, then AWS checks all of those policies for at least one `Allow`.
+ **Session policies** – Session policies are policies that you pass as parameters when you programmatically create a temporary session for a role or federated user session. To create a role session programmatically, use one of the `AssumeRole*` API operations. When you do this and pass session policies, the resulting session's permissions are the intersection of the IAM entity's identity-based policy and the session policies. To create a federated user session, you use the IAM user access keys to programmatically call the `GetFederationToken` API operation. For more information, see [Session policies](access_policies.md#policies_session).
Remember, an explicit deny in any of these policies overrides the allow.
**Note**
**AWS Organizations declarative policies** allow you to centrally declare and enforce your desired configuration for a given AWS service at scale across an organization. Since declarative policies are applied directly at the service level, they don't directly impact policy evaluation requests and aren't included with the request context. For more information, see [Declarative policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) in the AWS Organizations User Guide.
## Example policy evaluation using the PARC model
To illustrate how the request context interacts with policy evaluation, let's consider an example policy:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:CreateBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/dept": "123"
}
}
}
]
}
```
------
In this example, the policy would allow the `CreateBucket` action only when the request context includes an `aws:PrincipalTag/dept` value of "123" and the resource matches the `amzn-s3-demo-bucket1` bucket name. The following table shows how AWS uses the request context to evaluate this policy and make authorization decisions.
| Policy | Request context | Evaluation result |
| --- | --- | --- |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:PrincipalTag/dept=123
| **Match** |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:DeleteBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:PrincipalTag/dept=123
| **No match** |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:PrincipalTag/dept=321
| **No match** |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
No `aws:PrincipalTag` in the request. | **No match** |
# How AWS enforcement code logic evaluates requests to allow or deny access
AWS enforcement code logic
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
Single account policy evaluation
## 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
Example 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
Cross-account policy evaluation
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)
# The difference between explicit and implicit denies
Explicit and implicit denies
A request results in an explicit deny if an applicable policy includes a `Deny` statement. If policies that apply to a request include an `Allow` statement and a `Deny` statement, the `Deny` statement trumps the `Allow` statement. The request is explicitly denied.
An implicit denial occurs when there is no applicable `Deny` statement but also no applicable `Allow` statement. Because an IAM principal is denied access by default, they must be explicitly allowed to perform an action. Otherwise, they are implicitly denied access.
When you design your authorization strategy, you must create policies with `Allow` statements to allow your principals to successfully make requests. However, you can choose any combination of explicit and implicit denies.
For example, you can create the following policy that includes allowed actions, implicitly denied actions, and explicitly denied actions. The `AllowGetList` statement **allows** read-only access to IAM actions that begin with the prefixes `Get` and `List`. All other actions in IAM, such as `iam:CreatePolicy` are **implicitly denied**. The `DenyReports` statement **explicitly denies** access to IAM reports by denying access to actions that include the `Report` suffix, such as `iam:GetOrganizationsAccessReport`. If someone adds another policy to this principal to grant them access to IAM reports, such as `iam:GenerateCredentialReport`, report-related requests are still denied because of this explicit deny.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowGetList",
"Effect": "Allow",
"Action": [
"iam:Get*",
"iam:List*"
],
"Resource": "*"
},
{
"Sid": "DenyReports",
"Effect": "Deny",
"Action": "iam:*Report",
"Resource": "*"
}
]
}
```
------