# Identity and access management for AWS Interconnect
AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use AWS Interconnect resources. IAM is an AWS service that you can use with no additional charge.
**Topics**
+ [Audience](#security-iam-audience)
+ [Authenticating with identities](#security-iam-authentication)
+ [Managing access using policies](#security-iam-access-manage)
+ [How AWS Interconnect works with IAM](security-iam-service-with-iam.md)
+ [AWS Interconnect identity-based policy examples](security-iam-id-based-policy-examples.md)
+ [Troubleshooting AWS Interconnect identity and access](security-iam-troubleshoot.md)
## Audience
How you use AWS Identity and Access Management (IAM) differs, depending on the work you do in AWS Interconnect.
**Service user** – If you use the AWS Interconnect service to do your job, then your administrator provides you with the credentials and permissions that you need. As you use more AWS Interconnect features to do your work, you might need additional permissions. Understanding how access is managed can help you request the right permissions from your administrator. If you cannot access a feature in AWS Interconnect, see [Troubleshooting AWS Interconnect identity and access](security-iam-troubleshoot.md).
**Service administrator** – If you’re in charge of AWS Interconnect resources at your company, you probably have full access to AWS Interconnect. It’s your job to determine which AWS Interconnect features and resources your service users should access. You must then submit requests to your IAM administrator to change the permissions of your service users. Review the information on this page to understand the basic concepts of IAM. To learn more about how your company can use IAM with AWS Interconnect, see [How AWS Interconnect works with IAM](security-iam-service-with-iam.md).
** IAM administrator** – If you’re an IAM administrator, you might want to learn details about how you can write policies to manage access to AWS Interconnect. To view example AWS Interconnect identity-based policies that you can use in IAM, see [AWS Interconnect identity-based policy examples](security-iam-id-based-policy-examples.md).
## Authenticating with identities
Authentication is how you sign in to AWS using your identity credentials. You must be *authenticated* (signed in to AWS) as the AWS account root user, an IAM user, or by assuming an IAM role.
You can sign in to AWS as a federated identity by using credentials provided through an identity source. AWS IAM Identity Center (IAM Identity Center) users, your company’s single sign-on authentication, and your Google or Facebook credentials are examples of federated identities. When you sign in as a federated identity, your administrator previously set up identity federation using IAM roles. When you access AWS by using federation, you are indirectly assuming a role.
Depending on the type of user you are, you can sign in to the AWS Management Console or the AWS access portal. For more information about signing in to AWS, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.
If you access AWS programmatically, AWS provides a software development kit (SDK) and a command line interface (CLI) to cryptographically sign your requests using your credentials. If you don’t use AWS tools, you must sign requests yourself. For more information about using the recommended method to sign requests yourself, see [Signature Version 4 signing process](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) in the *AWS General Reference*.
Regardless of the authentication method that you use, you might also be required to provide additional security information. For example, AWS recommends that you use multi-factor authentication (MFA) to increase the security of your account. To learn more, see [Multi-factor authentication](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html) in the *AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide* and [Using multi-factor authentication (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) in the *IAM User Guide*.
### AWS account root user
When you first create an AWS account, you begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user and is accessed by signing in with the email address and password that you used to create the account. We strongly recommend that you don’t use the root user for your everyday tasks. Safeguard your root user credentials and use them to perform tasks that only the root user can perform. For the complete list of tasks that require you to sign in as the root user, see [Tasks that require root user credentials](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html) in the *Account Management Reference Guide*.
### Federated identity
As a best practice, require human users, including users that require administrator access, to use federation with an identity provider to access AWS services by using temporary credentials.
A federated identity is a user from your enterprise user directory, a web identity provider, the AWS Directory Service, the Identity Center directory, or any user that accesses AWS services by using credentials provided through an identity source. When federated identities access AWS accounts, they assume roles, and the roles provide temporary credentials.
For centralized access management, we recommend that you use AWS IAM Identity Center. You can create users and groups in IAM Identity Center, or you can connect and synchronize to a set of users and groups in your own identity source for use across all your AWS accounts and applications. For information about IAM Identity Center, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide*.
### IAM users and groups
An * [IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) * is an identity within your AWS account that has specific permissions for a single person or application. Where possible, we recommend relying on temporary credentials instead of creating IAM users who have long-term credentials such as passwords and access keys. However, if you have specific use cases that require long-term credentials with IAM users, we recommend that you rotate access keys. For more information, see [Rotate access keys regularly for use cases that require long-term credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials) in the *IAM User Guide*.
An [IAM group](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) is an identity that specifies a collection of IAM users. You can’t sign in as a group. You can use groups to specify permissions for multiple users at a time. Groups make permissions easier to manage for large sets of users. For example, you could have a group named *IAMAdmins* and give that group permissions to administer IAM resources.
Users are different from roles. A user is uniquely associated with one person or application, but a role is intended to be assumable by anyone who needs it. Users have permanent long-term credentials, but roles provide temporary credentials. To learn more, see [When to create an IAM user (instead of a role)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose) in the *IAM User Guide*.
### IAM roles
An * [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) * is an identity within your AWS account that has specific permissions. It is similar to an IAM user, but is not associated with a specific person. You can temporarily assume an IAM role in the AWS Management Console by [switching roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). You can assume a role by calling an AWS CLI or AWS API operation or by using a custom URL. For more information about methods for using roles, see [Using IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) in the *IAM User Guide*.
IAM roles with temporary credentials are useful in the following situations:
+ **Federated user access** – To assign permissions to a federated identity, you create a role and define permissions for the role. When a federated identity authenticates, the identity is associated with the role and is granted the permissions that are defined by the role. For information about roles for federation, see [Creating a role for a third-party Identity Provider](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*. If you use IAM Identity Center, you configure a permission set. To control what your identities can access after they authenticate, IAM Identity Center correlates the permission set to a role in IAM. For information about permissions sets, see [Permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) in the *AWS IAM Identity Center (successor to AWS Single Sign-On) User Guide*.
+ **Temporary IAM user permissions** – An IAM user can assume an IAM role to temporarily take on different permissions for a specific task.
To learn whether to use IAM roles, see [When to create an IAM role (instead of a user)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) in the *IAM User Guide*.
## Managing access using policies
You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when a principal (user, root user, or role session) makes a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents. For more information about the structure and contents of JSON policy documents, see [Overview of JSON policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*.
Administrators can use AWS JSON policies to specify who has access to what. That is, which **principal** can perform **actions** on what **resources**, and under what **conditions**.
Every IAM entity (user or role) starts with no permissions. By default, users can do nothing, not even change their own password. To give a user permission to do something, an administrator must attach a permissions policy to a user. Or the administrator can add the user to a group that has the intended permissions. When an administrator gives permissions to a group, all users in that group are granted those permissions.
IAM policies define permissions for an action regardless of the method that you use to perform the operation. For example, suppose that you have a policy that allows the `iam:GetRole` action. A user with that policy can get role information from the AWS Management Console, the AWS CLI, or the AWS API.
### Identity-based policies
Identity-based policies are JSON permissions policy documents that you can attach to an identity, such as an IAM user, role, or group. These policies control what actions users and roles can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Creating IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
Identity-based policies can be further categorized as *inline policies* or *managed policies*. Inline policies are embedded directly into a single user, group, or role. Managed policies are standalone policies that you can attach to multiple users, groups, and roles in your AWS account. Managed policies include AWS managed policies and customer managed policies. To learn how to choose between a managed policy or an inline policy, see [Choosing between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) in the *IAM User Guide*.
### Multiple policy types
When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*.
# How AWS Interconnect works with IAM
Before you use IAM to manage access to AWS Interconnect, learn what IAM features are available to use with AWS Interconnect. To get a high-level view of how AWS Interconnect and other AWS services work with IAM, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
**Topics**
+ [AWS Interconnect Identity-based policies](#security-iam-service-with-iam-id-based-policies)
+ [Authorization based on AWS Interconnect tags](#security-iam-service-with-iam-tags)
+ [AWS Interconnect IAM roles](#security-iam-service-with-iam-roles)
## AWS Interconnect Identity-based policies
With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. You can’t specify the principal in an identity-based policy because it applies to the user or role to which it is attached. To learn about all of the elements that you use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*.
### Actions
The `Action` element of an IAM identity-based policy describes the specific action or actions that will be allowed or denied by the policy. Policy actions usually have the same name as the associated AWS API operation. The action is used in a policy to grant permissions to perform the associated operation.
Policy actions in AWS Interconnect use the following prefix before the action: `interconnect:`. For example, to grant someone permission to run an Amazon EC2 instance with the Amazon EC2 `RunInstances` API operation, you include the `ec2:RunInstances` action in their policy. Policy statements must include either an `Action` or `NotAction` element. AWS Interconnect defines its own set of actions that describe tasks that you can perform with this service.
To specify multiple actions in a single statement, separate them with commas as follows:
```
"Action": [
"interconnect:CreateConnection",
"interconnect:ListEnvironments"
]
```
You can specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `Describe`, include the following action:
```
"Action": "interconnect:Create*"
```
To see a list of AWS Interconnect actions, see [Actions Defined by AWS Interconnect](https://alpha.www.docs.aws.a2z.com/service-authorization/latest/reference/list_awsinterconnect.html#awsinterconnect-actions-as-permissions) in the *IAM User Guide*.
### Resources
The `Resource` element specifies the object or objects to which the action applies. Statements must include either a `Resource` or a `NotResource` element. You specify a resource using an ARN or using the wildcard (\$1) to indicate that the statement applies to all resources.
The AWS Interconnect Connection resource has the following ARN:
```
arn:${Partition}:interconnect:${Region}:${Account}:connection/${ConnectionId}
```
For more information about the format of ARNs, see [Amazon Resource Names (ARNs) and AWS service Namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
For example, to specify the `mcc-12345678` connection in your statement, use the following ARN:
```
"Resource": "arn:aws:interconnect:us-east-1:123456789012:connection/mcc-12345678"
```
To specify all instances that belong to a specific account, use the wildcard (\$1):
```
"Resource": "arn:aws:interconnect:us-east-1:123456789012:connection/*"
```
Some AWS Interconnect actions, such as those for creating resources, cannot be performed on a specific resource. In those cases, you must use the wildcard (\$1).
```
"Resource": "*"
```
To see a list of AWS Interconnect resource types and their ARNs, see [Resources Defined by AWS Interconnect](https://alpha.www.docs.aws.a2z.com/service-authorization/latest/reference/list_awsinterconnect.html#awsinterconnect-resources-for-iam-policies) in the *IAM User Guide*. To learn with which actions you can specify the ARN of each resource, see [Actions Defined by AWS Interconnect](https://alpha.www.docs.aws.a2z.com/service-authorization/latest/reference/list_awsinterconnect.html#awsinterconnect-actions-as-permissions).
### Condition keys
The `Condition` element (or `Condition` *block*) lets you specify conditions in which a statement is in effect. The `Condition` element is optional. You can create conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request.
If you specify multiple `Condition` elements in a statement, or multiple keys in a single `Condition` element, AWS evaluates them using a logical `AND` operation. If you specify multiple values for a single condition key, AWS evaluates the condition using a logical `OR` operation. All of the conditions must be met before the statement’s permissions are granted.
You can also use placeholder variables when you specify conditions. For example, you can grant an IAM user permission to access a resource only if it is tagged with their IAM user name. For more information, see [IAM policy elements: variables and tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html) in the *IAM User Guide*.
AWS Interconnect defines its own set of condition keys and also supports using some global condition keys. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*.
All Amazon EC2 actions support the `aws:RequestedRegion` and `ec2:Region` condition keys. For more information, see [Example: Restricting access to a specific region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region).
To see a list of AWS Interconnect condition keys, see [Condition Keys for AWS Interconnect](https://alpha.www.docs.aws.a2z.com/service-authorization/latest/reference/list_awsinterconnect.html#awsinterconnect-policy-keys) in the *IAM User Guide*. To learn with which actions and resources you can use a condition key, see [Actions defined by AWS Interconnect](https://alpha.www.docs.aws.a2z.com/service-authorization/latest/reference/list_awsinterconnect.html#awsinterconnect-actions-as-permissions).
### Examples
To view examples of AWS Interconnect identity-based policies, see [AWS Interconnect identity-based policy examples](security-iam-id-based-policy-examples.md).
## Authorization based on AWS Interconnect tags
You can attach tags to AWS Interconnect resources or pass tags in a request to AWS Interconnect. To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `interconnect:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys. For more information about tagging AWS Interconnect resources, see [AWS Interconnect TagResource API](https://docs.aws.amazon.com/interconnect/latest/api/API_TagResource.html).
To view an example identity-based policy for limiting access to a resource based on the tags on that resource, see [Viewing AWS Interconnect connections based on tags](security-iam-id-based-policy-examples.md#security-iam-id-based-policy-examples-view-connection-tags).
## AWS Interconnect IAM roles
An [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) is an entity within your AWS account that has specific permissions.
### Using temporary credentials with AWS Interconnect
You can use temporary credentials to sign in with federation, assume an IAM role, or to assume a cross-account role. You obtain temporary security credentials by calling AWS STS API operations such as [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) or [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html).
AWS Interconnect supports using temporary credentials.
# AWS Interconnect identity-based policy examples
By default, IAM users and roles don’t have permission to create or modify AWS Interconnect resources. They also can’t perform tasks using the AWS Management Console, AWS CLI, or AWS API. An IAM administrator must create IAM policies that grant users and roles permission to perform specific API operations on the specified resources they need. The administrator must then attach those policies to the IAM users or groups that require those permissions.
To learn how to create an IAM identity-based policy using these example JSON policy documents, see [Creating policies on the JSON tab](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) in the *IAM User Guide*.
**Topics**
+ [Policy best practices](#security-iam-service-with-iam-policy-best-practices)
+ [Using the AWS Interconnect console](#security-iam-id-based-policy-examples-console)
+ [Allow users to view their own permissions](#security-iam-id-based-policy-examples-view-own-permissions)
+ [Viewing AWS Interconnect Connections based on tags](#security-iam-id-based-policy-examples-view-connection-tags)
## Policy best practices
Identity-based policies determine whether someone can create, access, or delete AWS Interconnect resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:
+ **Get started with AWS managed policies and move toward least-privilege permissions** – To get started granting permissions to your users and workloads, use the AWS managed policies that grant permissions for many common use cases. They are available in your AWS account. We recommend that you reduce permissions further by defining AWS customer managed policies that are specific to your use cases. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*.
+ **Apply least-privilege permissions** – When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as *least-privilege permissions*. For more information about using IAM to apply permissions, see [Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*.
+ **Use conditions in IAM policies to further restrict access** – You can add a condition to your policies to limit access to actions and resources. For example, you can write a policy condition to specify that all requests must be sent using SSL. You can also use conditions to grant access to service actions if they are used through a specific AWS service, such as CloudFormation. For more information, see [IAM JSON policy elements: condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
+ **Use IAM Access Analyzer to validate your IAM policies to ensure secure and functional permissions** – IAM Access Analyzer validates new and existing policies so that the policies adhere to the IAM policy language (JSON) and IAM best practices. IAM Access Analyzer provides more than 100 policy checks and actionable recommendations to help you author secure and functional policies. For more information, see [IAM Access Analyzer policy validation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) in the *IAM User Guide*.
+ **Require multi-factor authentication (MFA)** – If you have a scenario that requires IAM users or root users in your account, turn on MFA for additional security. To require MFA when API operations are called, add MFA conditions to your policies. For more information, see [Configuring MFA-protected API access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) in the *IAM User Guide*.
## Using the AWS Interconnect console
To access the AWS Interconnect console, you must have a minimum set of permissions. These permissions must allow you to list and view details about the AWS Interconnect resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won’t function as intended for entities (users or roles) with that policy.
To ensure that those entities can still use the AWS Interconnect console, also attach the following AWS managed policy to the entities. For more information, see [Adding permissions to a user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*:
```
AWSInterconnectConsoleAccess
```
You don’t need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that you’re trying to perform.
## Allow users to view their own permissions
This example shows how you might create a policy that allows IAM users to view the inline and managed policies that are attached to their user identity. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Viewing AWS Interconnect Connections based on tags
You can use conditions in your identity-based policy to control access to AWS Interconnect resources based on tags. This example shows how you might create a policy that allows viewing a Connection. However, permission is granted only if the Connection tag `Owner` has the value of that user’s user name. This policy also grants the permissions necessary to complete this action on the console.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListConnectionsInConsole",
"Effect": "Allow",
"Action": "interconnect:ListConnections",
"Resource": "*"
},
{
"Sid": "ViewConnectionIfOwner",
"Effect": "Allow",
"Action": "interconnect:GetConnection",
"Resource": "arn:aws:interconnect:*:*:connection/*",
"Condition": {
"StringEquals": {"interconnect:ResourceTag/Owner": "${aws:username}"}
}
}
]
}
```
You can attach this policy to the IAM users in your account. If a user named `richard-roe` attempts to view an AWS Interconnect Connection, the Connection must be tagged `Owner=richard-roe` or `owner=richard-roe`. Otherwise he is denied access. The condition tag key `Owner` matches both `Owner` and `owner` because condition key names are not case-sensitive. For more information, see [IAM JSON policy elements: condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
# Troubleshooting AWS Interconnect identity and access
Use the following information to help you diagnose and fix common issues that you might encounter when working with AWS Interconnect and IAM.
**Topics**
+ [I am not authorized to perform an action in AWS Interconnect](#security-iam-troubleshoot-no-permissions)
+ [I am not authorized to perform iam:PassRole](#security-iam-troubleshoot-passrole)
+ [I want to allow people outside of my AWS account to access my AWS Interconnect resources](#security-iam-troubleshoot-cross-account-access)
## I am not authorized to perform an action in AWS Interconnect
If the AWS Management Console tells you that you’re not authorized to perform an action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your user name and password.
The following example error occurs when the `mateojackson` IAM user tries to use the console to view details about a Connection but does not have `interconnect:GetConnection ` permissions.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: interconnect:GetConnection on resource: mcc-12345678
```
In this case, Mateo asks his administrator to update his policies to allow him to access the `mcc-12345678` resource using the `interconnect:GetConnection` action.
## I am not authorized to perform iam:PassRole
If you receive an error that you’re not authorized to perform the `iam:PassRole` action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your user name and password. Ask that person to update your policies to allow you to pass a role to AWS Interconnect.
Some AWS services allow you to pass an existing role to that service, instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service.
The following example error occurs when an IAM user named `marymajor` tries to use the console to perform an action in AWS Interconnect. However, the action requires the service to have permissions granted by a service role. Mary does not have permissions to pass the role to the service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In this case, Mary asks her administrator to update her policies to allow her to perform the `iam:PassRole` action.
## I want to allow people outside of my AWS account to access my AWS Interconnect resources
You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.
To learn more, consult the following:
+ To learn whether AWS Interconnect supports these features, see [How AWS Interconnect works with IAM](security-iam-service-with-iam.md).
+ To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*.
+ To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*.
+ To learn how to provide access through identity federation, see [Providing Access to Externally Authenticated Users (Identity Federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*.
+ To learn the difference between using roles and resource-based policies for cross-account access, see [How IAM roles differ from resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) in the *IAM User Guide*.