

# IAM federation
<a name="iam-federation"></a>


|  | 
| --- |
|    Applies to: Enterprise Edition and Standard Edition  | 


|  | 
| --- |
|    Intended audience:  System administrators  | 

**Important**  
Amazon Quick recommends that you integrate new Amazon Quick subscriptions with IAM Identity Center for identity management. This IAM identity federation user guide is provided as a reference for existing account configurations. For more information on integrating your Amazon Quick account with IAM Identity Center, see [Configure your Amazon Quick account with IAM Identity Center](https://docs.aws.amazon.com/quicksight/latest/user/sec-identity-management-identity-center.html).

**Note**  
IAM identity federation doesn't support syncing identity provider groups with Amazon Quick.

Amazon Quick supports identity federation in both Standard and Enterprise editions. When you use federated users, you can manage users with your enterprise identity provider (IdP) and use AWS Identity and Access Management (IAM) to authenticate users when they sign in to Quick. You can use a third-party identity provider that supports Security Assertion Markup Language 2.0 (SAML 2.0) to provide an onboarding flow for your Amazon Quick users. Such identity providers include Microsoft Active Directory Federation Services, Okta, and Ping One Federation Server. With identity federation, your users get one-click access to their Amazon Quick applications using their existing identity credentials. You also have the security benefit of identity authentication by your identity provider. You can control which users have access to Amazon Quick using your existing identity provider. 

**Topics**
+ [Initiating sign-on from the identity provider (IdP)](federated-identities-idp-to-sp.md)
+ [Setting up IdP federation using IAM and Amazon Quick](external-identity-providers-setting-up-saml.md)
+ [Initiating sign-on from Quick](federated-identities-sp-to-idp.md)
+ [Setting up service provider–initiated federation with Quick Enterprise edition](setup-quicksight-to-idp.md)
+ [Configuring email syncing for federated users in Quick](jit-email-syncing.md)
+ [Tutorial: Amazon Quick and IAM identity federation](tutorial-okta-quicksight.md)

# Initiating sign-on from the identity provider (IdP)
<a name="federated-identities-idp-to-sp"></a>


|  | 
| --- |
|    Applies to: Enterprise Edition and Standard Edition  | 


|  | 
| --- |
|    Intended audience:  System administrators  | 

**Note**  
IAM identity federation doesn't support syncing identity provider groups with Amazon Quick.

In this scenario, your users initiate the sign-on process from the identity provider's portal. After the users are authenticated, they sign in to Amazon Quick. After Quick checks that they are authorized, your users can access Quick. 

Beginning with a user signing into the IdP, authentication flows through these steps:

1. The user browses to `https://applications.example.com` and signs on to the IdP. At this point, the user isn't signed in to the service provider. 

1. The federation service and the IdP authenticate the user:

   1. The federation service requests authentication from the organization's identity store.

   1. The identity store authenticates the user and returns the authentication response to the federation service.

   1. When authentication is successful, the federation service posts the SAML assertion to the user’s browser.

1. The user opens Amazon Quick:

   1. The user's browser posts the SAML assertion to the AWS Sign-In SAML endpoint (`https://signin.aws.amazon.com/saml`). 

   1. AWS Sign-In receives the SAML request, processes the request, authenticates the user, and forwards the authentication token to the Amazon Quick service.

1. Amazon Quick accepts the authentication token from AWS and presents Amazon Quick to the user.

From the user's perspective, the process happens transparently. The user starts at your organization's internal portal and lands at an Amazon Quick application portal, without ever having to supply any AWS credentials.

In the following diagram, you can find an authentication flow between Amazon Quick and a third-party identity provider (IdP). In this example, the administrator has set up a sign-in page to access Amazon Quick, called `applications.example.com`. When a user signs in, the sign-in page posts a request to a federation service that complies with SAML 2.0. The end user initiates authentication from the sign-on page of the IdP.

![\[Quick SAML Diagram. The diagram contains two boxes. The first one describes an authentication process inside the enterprise. The second one describes authentication inside AWS. The process is described in the text following the table.\]](http://docs.aws.amazon.com/quick/latest/userguide/images/SAML-Flow-Diagram.png)


For information from some common providers, see the following third-party documentation:
+ CA – [Enabling SAML 2.0 HTTP Post Binding](https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/siteminder/12-7/configuring/partnership-federation/saml-2-0-only-configurable-features/enable-saml-2-0-http-post-binding.html)
+ Okta – [Planning a SAML deployment](https://developer.okta.com/docs/concepts/saml/)
+ Ping – [Amazon integrations](https://docs.pingidentity.com/bundle/integrations/page/kun1563994988131.html)

Use the following topics to understand using an existing federation with AWS:
+ [Identity federation in AWS](https://aws.amazon.com/identity/federation/) on the AWS website
+ [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*
+ [Enabling SAML 2.0 federated users to access the AWS Management Console](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html) in the *IAM User Guide*

# Setting up IdP federation using IAM and Amazon Quick
<a name="external-identity-providers-setting-up-saml"></a>


|  | 
| --- |
|    Applies to: Enterprise Edition and Standard Edition  | 


|  | 
| --- |
|    Intended audience:  System administrators  | 

**Note**  
IAM identity federation doesn't support syncing identity provider groups with Amazon Quick.

You can use an AWS Identity and Access Management (IAM) role and a relay state URL to configure an identity provider (IdP) that is compliant with SAML 2.0. The role grants users permissions to access Amazon Quick. The relay state is the portal that the user is forwarded to, after successful authentication by AWS.

**Topics**
+ [Prerequisites](#external-identity-providers-setting-up-prerequisites)
+ [Step 1: Create a SAML provider in AWS](#external-identity-providers-create-saml-provider)
+ [Step 2: Configure permissions in AWS for your federated users](#external-identity-providers-grantperms)
+ [Step 3: Configure the SAML IdP](#external-identity-providers-config-idp)
+ [Step 4: Create assertions for the SAML authentication response](#external-identity-providers-create-assertions)
+ [Step 5: Configure the relay state of your federation](#external-identity-providers-relay-state)

## Prerequisites
<a name="external-identity-providers-setting-up-prerequisites"></a>

Before configuring your SAML 2.0 connection, do the following:
+ Configure your IdP to establish a trust relationship with AWS: 
  + Inside your organization's network, configure your identity store, such as Windows Active Directory, to work with a SAML-based IdP. SAML-based IdPs include Active Directory Federation Services, Shibboleth, and so on.
  + Using your IdP, generate a metadata document that describes your organization as an identity provider.
  + Set up SAML 2.0 authentication, using the same steps as for the AWS Management Console. When this process is complete, you can configure your relay state to match the relay state of Quick. For more information, see [Configure the relay state of your federation](https://docs.aws.amazon.com/quicksight/latest/user/external-identity-providers-setting-up-saml.html#external-identity-providers-relay-state).
+ Create an Amazon Quick account and note the name to use when you configure your IAM policy and IdP. For more information on creating an Amazon Quick account, see [Signing up for an Amazon Quick subscription](https://docs.aws.amazon.com/quicksight/latest/user/signing-up.html).

After you create the setup to federate to the AWS Management Console as outlined in the tutorial, you can edit the relay state provided in the tutorial. You do so with the relay state of Amazon Quick, described in step 5 following. 

For more information, see the following resources:
+ [Integrating Third-Party SAML Solution Providers with AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/) in the *IAM User Guide*.
+  [Troubleshooting SAML 2.0 federation with AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_saml.html), also in the *IAM User Guide*.
+ [Setting up trust between ADFS and AWS and using Active Directory credentials to connect to Amazon Athena with ODBC driver](https://aws.amazon.com/blogs/big-data/setting-up-trust-between-adfs-and-aws-and-using-active-directory-credentials-to-connect-to-amazon-athena-with-odbc-driver/) – This walkthrough article is helpful, although you don't need to set up Athena in order to use Amazon Quick.

## Step 1: Create a SAML provider in AWS
<a name="external-identity-providers-create-saml-provider"></a>

Your SAML identity provider defines your organization's IdP to AWS. It does so by using the metadata document that you previously generated using your IdP. 

**To create a SAML provider in AWS**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. Create a new SAML provider, which is an entity in IAM that holds information about your organization's identity provider. For more information, see [Creating SAML Identity Providers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html) in the *IAM User Guide*. 

1. As part of this process, upload the metadata document produced by the IdP software in your organization noted in the previous section. 

## Step 2: Configure permissions in AWS for your federated users
<a name="external-identity-providers-grantperms"></a>

Next, create an IAM role that establishes a trust relationship between IAM and your organization's IdP. This role identifies your IdP as a principal (trusted entity) for the purposes of federation. The role also defines which users authenticated by your organization's IdP are allowed to access Amazon Quick. For more information about creating a role for a SAML IdP, see [Creating a Role for SAML 2.0 Federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_saml.html) in the *IAM User Guide*.

After you have created the role, you can limit the role to have permissions only to Amazon Quick by attaching an inline policy to the role. The following sample policy document provides access to Amazon Quick. This policy allows the user access to Amazon Quick and allows them to create both author accounts and reader accounts.

**Note**  
In the following example, replace *<YOUR\$1AWS\$1ACCOUNT\$1ID>* with your 12-digit AWS account ID (with no hyphens ‘‐’).

```
    {
    "Statement": [
        {
            "Action": [
                "quicksight:CreateUser"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:quicksight::<YOUR_AWS_ACCOUNT_ID>:user/${aws:userid}"
            ]
        }
    ],
    "Version": "2012-10-17"		 	 	 
    }
```

If you want to provide access to Amazon Quick and also the ability to create Amazon Quick admins, authors (standard users), and readers, you can use the following policy example. 

```
    {
    "Statement": [
        {
            "Action": [
                "quicksight:CreateAdmin"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:quicksight::<YOUR_AWS_ACCOUNT_ID>:user/${aws:userid}"
            ]
        }
    ],
    "Version": "2012-10-17"		 	 	 
    }
```

You can view account details in the AWS Management Console.

After you have set up SAML and the IAM policy or policies, you don't need to invite users manually. The first time that users open Amazon Quick, they are provisioned automatically, using the highest level permissions in the policy. For example, if they have permissions to both `quicksight:CreateUser` and `quicksight:CreateReader`, they are provisioned as authors. If they also have permissions to `quicksight:CreateAdmin`, they are provisioned as admins. Each permission level includes the ability to create the same level user and below. For example, an author can add other authors or readers. 

Users who are invited manually are created in the role assigned by the person who invited them. They don't need to have policies that grant them permissions.

## Step 3: Configure the SAML IdP
<a name="external-identity-providers-config-idp"></a>

After you create the IAM role, update your SAML IdP about AWS as a service provider. To do so, install the `saml-metadata.xml` file found at [https://signin.aws.amazon.com/static/saml-metadata.xml](https://signin.aws.amazon.com/static/saml-metadata.xml). 

To update the IdP metadata, see the instructions provided by your IdP. Some providers give you the option to type the URL, after which the IdP gets and installs the file for you. Others require you to download the file from the URL and then provide it as a local file. 

For more information, see your IdP documentation. 

## Step 4: Create assertions for the SAML authentication response
<a name="external-identity-providers-create-assertions"></a>

Next, configure the information that the IdP passes as SAML attributes to AWS as part of the authentication response. For more information, see [Configuring SAML Assertions for the Authentication Response](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_assertions.html) in the *IAM User Guide*.

## Step 5: Configure the relay state of your federation
<a name="external-identity-providers-relay-state"></a>

Finally, configure the relay state of your federation to point to the Amazon Quick relay state URL. After successful authentication by AWS, the user is directed to Amazon Quick, defined as the relay state in the SAML authentication response.

The relay state URL for Amazon Quick is as follows.

```
https://quicksight.aws.amazon.com
```

# Initiating sign-on from Quick
<a name="federated-identities-sp-to-idp"></a>


|  | 
| --- |
|  Applies to:  Enterprise Edition  | 


|  | 
| --- |
|    Intended audience:  System administrators  | 

**Note**  
IAM identity federation doesn't support syncing identity provider groups with Amazon Quick.

In this scenario, your user initiates the sign-on process from an Amazon Quick application portal without being signed on to the identity provider. In this case, the user has a federated account managed by a third-party IdP. The user might have a user account on Quick. Quick sends an authentication request to the IdP. After the user is authenticated, Quick opens. 

Beginning with the user signing into Quick, authentication flows through these steps:

1. The user opens Quick. At this point, the user isn't signed in to the IdP. 

1. The user attempts to sign in to Amazon Quick.

1. Amazon Quick redirects the user's input to the federation service and requests authentication.

1. The federation service and the IdP authenticate the user:

   1. The federation service requests authentication from the organization's identity store.

   1. The identity store authenticates the user and returns the authentication response to the federation service.

   1. When authentication is successful, the federation service posts the SAML assertion to the user's browser.

   1. The user's browser posts the SAML assertion to the AWS Sign-In SAML endpoint (`https://signin.aws.amazon.com/saml`). 

   1. AWS Sign-In receives the SAML request, processes the request, authenticates the user, and forwards the authentication token to the Amazon Quick service.

1. Amazon Quick accepts the authentication token from AWS and presents Amazon Quick to the user.

From the user's perspective, the process happens transparently. The user starts at an Amazon Quick application portal. Amazon Quick negotiates authentication with your organization's federation service and AWS. Amazon Quick opens, without the user needing to supply any additional credentials.

# Setting up service provider–initiated federation with Quick Enterprise edition
<a name="setup-quicksight-to-idp"></a>


|  | 
| --- |
|  Applies to:  Enterprise Edition  | 


|  | 
| --- |
|    Intended audience:  System administrators  | 

**Note**  
IAM identity federation doesn't support syncing identity provider groups with Amazon Quick.

After you have finished configuring your identity provider with AWS Identity and Access Management (IAM), you can set up service provider–initiated sign in through Amazon Quick Enterprise Edition. For Quick-initiated IAM federation to work, you need to authorize Quick to send the authentication request to your IdP. A Quick administrator can configure this by adding the following information provided by the IdP:
+ The IdP URL – Quick redirects users to this URL for authentication.
+ The relay state parameter – This parameter relays the state that the browser session was in when it was redirected for authentication. The IdP redirects the user back to the original state after authentication. The state is provided as a URL.

The following table shows the standard authentication URL and relay state parameter for redirecting the user to the Quick URL that you provide.


| Identity provider | Parameter | Authentication URL | 
| --- | --- | --- | 
|  Auth0  |   `RelayState`   |   `https://<sub_domain>.auth0.com/samlp/<app_id>`   | 
|  Google accounts  |   `RelayState`   |   `https://accounts.google.com/o/saml2/initsso?idpid=<idp_id>&spid=<sp_id>&forceauthn=false`  | 
|  Microsoft Azure  |   `RelayState`   |   `https://myapps.microsoft.com/signin/<app_name>/<app_id>?tenantId=<tenant_id>`   | 
|  Okta  |   `RelayState`   |   `https://<sub_domain>.okta.com/app/<app_name>/<app_id>/sso/saml`   | 
|  PingFederate  |   `TargetResource`   |   `https://<host>/idp/<idp_id>/startSSO.ping?PartnerSpId=<sp_id>`   | 
|  PingOne  |   `TargetResource`   |   `https://sso.connect.pingidentity.com/sso/sp/initsso?saasid=<app_id>&idpid=<idp_id>`   | 

Amazon Quick supports connecting to one IdP per AWS account. The configuration page in Amazon Quick provides you with test URLs based on your entries, so you can test the settings before you turn on the feature. To make the process even more seamless, Amazon Quick provides a parameter (`enable-sso=0`) to temporarily turn off Amazon Quick initiated IAM federation, in case you need to disable it temporarily.

## To set up Amazon Quick as a service provider that can initiate IAM federation for an existing IdP
<a name="qs-setup-sp"></a>

1. Make sure that you already have IAM federation set up in your IdP, in IAM, and Amazon Quick. To test this setup, check if you can share a dashboard with another person in your company's domain.

1. Open Amazon Quick, and choose **Manage Amazon Quick** from your profile menu at upper right.

   To perform this procedure, you need to be a Amazon Quick administrator. If you aren't, you can't see **Manage Amazon Quick** under your profile menu.

1. Choose **Single sign-on (IAM federation)** from the navigation pane.

1. For **Configuration**, **IdP URL**, enter the URL that your IdP provides to authenticate users.

1. For **IdP URL**, enter the parameter that your IdP provides to relay state, for example `RelayState`. The actual name of the parameter is provided by your IdP. 

1. <a name="sp-idp-test"></a>Test signing in:
   + To test signing in with your identity provider, use the custom URL provided in **Test starting with your IdP**. You should arrive at the start page for Amazon Quick, for example https://quicksight.aws.amazon.com/sn/start.
   + To test signing in with Amazon Quick first, use the custom URL provided in **Test the end-to-end experience**. The `enable-sso` parameter is appended to the URL. If `enable-sso=1`, IAM federation attempts to authenticate. 

1. Choose **Save** to keep your settings.

## To enable service provider–initiated IAM federation IdP
<a name="qs-sp-enable"></a>

1. Make sure your IAM federation settings are configured and tested. If you're not sure about the configuration, test the connection by using the URLs from the previous procedure.

1. Open Amazon Quick, and choose **Manage Amazon Quick** from your profile menu.

1. Choose **Single sign-on (IAM federation)** from the navigation pane.

1. For **Status**, choose **ON**. 

1. Verify that it's working by disconnecting from your IdP and opening Amazon Quick. 

## To disable service provider initiated IAM federation
<a name="qs-sp-disable"></a>

1. Open Amazon Quick, and choose **Manage Amazon Quick** from your profile menu.

1. Choose **Single sign-on (IAM federation)** from the navigation pane.

1. For **Status**, choose **OFF**. 

# Configuring email syncing for federated users in Quick
<a name="jit-email-syncing"></a>


|  | 
| --- |
|  Applies to:  Enterprise Edition  | 


|  | 
| --- |
|    Intended audience:  System administrators and Amazon Quick administrators  | 

**Note**  
IAM identity federation doesn't support syncing identity provider groups with Amazon Quick.

In Amazon Quick Enterprise edition, as an administrator you can restrict new users from using personal email addresses when provisioning through their identity provider (IdP) directly to Quick. Quick then uses the preconfigured email addresses passed through the IdP when provisioning new users to your account. For example, you can make it so that only corporate-assigned email addresses are used when users are provisioned to your Amazon Quick account through your IdP.

**Note**  
Make sure that your users are federating directly to Amazon Quick through their IdP. Federating to the AWS Management Console through their IdP and then clicking into Amazon Quick results in an error and they won't be able to access Amazon Quick.

When you configure email syncing for federated users in Amazon Quick, users who log in to your Amazon Quick account for the first time have preassigned email addresses. These are used to register their accounts. With this approach, users can manually bypass by entering an email address. Also, users can't use an email address that might differ from the email address prescribed by you, the administrator.

Amazon Quick supports provisioning through an IdP that supports SAML or OpenID Connect (OIDC) authentication. To configure email addresses for new users when provisioning through an IdP, you update the trust relationship for the IAM role that they use with `AssumeRoleWithSAML` or `AssumeRoleWithWebIdentity`. Then you add a SAML attribute or OIDC token in their IdP. Last, you turn on email syncing for federated users in Amazon Quick.

The following procedures describe these steps in detail.

## Step 1: Update the trust relationship for the IAM role with AssumeRoleWithSAML or AssumeRoleWithWebIdentity
<a name="jit-email-syncing-step-1"></a>

You can configure email addresses for your users to use when provisioning through your IdP to Amazon Quick. To do this, add the `sts:TagSession` action to the trust relationship for the IAM role that you use with `AssumeRoleWithSAML` or `AssumeRoleWithWebIdentity`. By doing this, you can pass in `principal` tags when users assume the role.

The following example illustrates an updated IAM role where the IdP is Okta. To use this example, update the `Federated` Amazon Resource Name (ARN) with the ARN for your service provider. You can replace items in red with your AWS and IdP service-specific information.

```
{
    "Version": "2012-10-17"		 	 	 ,
    "Statement": [
    {
        "Effect": "Allow",
        "Principal": {
        "Federated": "arn:aws:iam::account-id:saml-provider/Okta"
        },
        "Action": "sts:AssumeRoleWithSAML",
        "Condition": {
        "StringEquals": {
            "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
        }
    },
    {
        "Effect": "Allow",
        "Principal": {
        "Federated": "arn:aws:iam::account-id:saml-provider/Okta"
        },
        "Action": "sts:TagSession",
        "Condition": {
        "StringLike": {
            "aws:RequestTag/Email": "*"
        }
        }
    }
    ]
    }
```

## Step 2: Add a SAML attribute or OIDC token for the IAM principal tag in your IdP
<a name="jit-email-syncing-step-2"></a>

After you update the trust relationship for the IAM role as described in the preceding section, add a SAML attribute or OIDC token for the IAM `Principal` tag in your IdP.

The following examples illustrate a SAML attribute and an OIDC token. To use these examples, replace the email address with a variable in your IdP that points to a user's email address. You can replace items highlighted in red with your information.
+ **SAML attribute**: The following example illustrates a SAML attribute. 

  ```
  <Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email"><AttributeValue>john.doe@example.com</AttributeValue></Attribute>
  ```
**Note**  
If you're using Okta as your IdP, make sure to turn on a feature flag in your Okta user account to use SAML. For more information, see [Okta and AWS Partner to Simplify Access Via Session Tags](https://www.okta.com/blog/2019/11/okta-and-aws-partner-to-simplify-access-via-session-tags/) on the Okta blog. 
+ **OIDC token**: The following example illustrates an OIDC token example. 

  ```
  "https://aws.amazon.com/tags": {"principal_tags": {"Email": ["john.doe@example.com"]
  ```

## Step 3: Turn on email syncing for federated users in Amazon Quick
<a name="jit-email-syncing-step-3"></a>

As described preceding, update the trust relationship for the IAM role and add a SAML attribute or OIDC token for the IAM `Principal` tag in your IdP. Then turn on email syncing for federated users in Amazon Quick as described in the following procedure.

**To turn on email syncing for federated users**

1. From any page in Amazon Quick, choose your username at top right, and then choose **Manage Amazon Quick**.

1. Choose **Single sign-on (IAM federation)** in the menu at left.

1. On the **Service Provider Initiated IAM federation** page, for **Email Syncing for Federated Users**, choose **ON**.

   When email syncing for federated users is on, Amazon Quick uses the email addresses that you configured in steps 1 and 2 when provisioning new users to your account. Users can't enter their own email addresses.

   When email syncing for federated users is off, Amazon Quick asks users to input their email address manually when provisioning new users to your account. They can use any email addresses that they want.

# Tutorial: Amazon Quick and IAM identity federation
<a name="tutorial-okta-quicksight"></a>


|  | 
| --- |
|    Applies to: Enterprise Edition and Standard Edition  | 


|  | 
| --- |
|    Intended audience:  Amazon Quick Administrators and Amazon Quick developers  | 

**Note**  
IAM identity federation doesn't support syncing identity provider groups with Amazon Quick.

In the following tutorial, you can find a walkthrough for setting up the IdP Okta as a federation service for Amazon Quick. Although this tutorial shows the integration of AWS Identity and Access Management (IAM) and Okta, you can also replicate this solution using your choice of SAML 2.0 IdPs.

In the following procedure, you create an app in the Okta IdP using their "AWS Account Federation" shortcut. Okta describes this integration app as follows:

"By federating Okta to Amazon Web Services (AWS) Identity and Access Management (IAM) accounts, end users get single sign-on access to all their assigned AWS roles with their Okta credentials. In each AWS account, administrators set up federation and configure AWS roles to trust Okta. When users sign in to AWS, they get Okta single sign-in experience to see their assigned AWS roles. They can then select a desired role, which defined their permissions for the duration of their authenticated session. Customers with large numbers of AWS Accounts, check out the AWS Single Sign-On app as an alternative." (https://www.okta.com/aws/)

**To create an Okta app using Okta's "AWS Account Federation" application shortcut**

1. Sign in to your Okta dashboard. If you don't have one, create a free Okta Developer Edition account by using [this Amazon Quick-branded URL](https://developer.okta.com/quickstart/). When you have activated your email, sign in to Okta.

1. On the Okta website, choose **<> Developer Console** at upper left, and then choose **Classic UI**.

1. Choose **Add Applications**, and choose **Add app**.

1. Enter **aws** for **Search**, and choose **AWS Account Federation** from the search results.

1. Choose **Add** to create an instance of this application.

1. For **Application label**, enter **AWS Account Federation - Amazon Quick**.

1. Choose **Next**.

1. For **SAML 2.0**, **Default Relay State**, enter **https://quicksight.aws.amazon.com**.

1. Open the context (right-click) menu for **Identity Provider metadata**, and choose to save the file. Name the file `metadata.xml`. You need this file in the next procedure.

   The contents of the file look similar to the following.

   ```
   <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="http://www.okta.com/exkffz2hATwiVft645d5">
       <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
       <md:KeyDescriptor use="signing">
           <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
           <ds:X509Data>
               <ds:X509Certificate>
               MIIDpjCCAo6gAwIBAgIGAXVjA82hMA0GCSqGSIb3DQEBCwUAMIGTMQswCQYDVQQGEwJVUzETMBEG 
               . 
               .        (certificate content omitted)
               . 
               QE/6cRdPQ6v/eaFpUL6Asd6q3sBeq+giRG4=
               </ds:X509Certificate>
           </ds:X509Data>
           </ds:KeyInfo>
       </md:KeyDescriptor>
       <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
       <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified</md:NameIDFormat>
       <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://dev-1054988.okta.com/app/amazon_aws/exkffz2hATwiVft645d5/sso/saml"/>
       <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://dev-1054988.okta.com/app/amazon_aws/exkffz2hATwiVft645d5/sso/saml"/>
       </md:IDPSSODescriptor>
       </md:EntityDescriptor>
   ```

1. After you have the XML file saved, scroll to the bottom of the Okta page, and choose **Done**.

1. Keep this browser window open, if possible. You need it later in the tutorial.

Next, you create an identity provider in your AWS account.

**To create a SAML provider in AWS Identity and Access Management (IAM)**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Identity providers**, **Create Provider**.

1. Enter the following settings:
   + **Provider Type** – Choose **SAML** from the list. 
   + **Provider Name** – Enter **Okta**.
   + **Metadata Document** – Upload the XML file `manifest.xml` from the previous procedure.

1. Choose **Next Step**, **Create**.

1. Locate the IdP that you created and choose it to view the settings. Note the **Provider ARN**. You need this to finish the tutorial.

1. Verify that the identity provider is created with your settings. In IAM, choose **Identity providers**, **Okta** (the IdP you added), **Download metadata**. The file should be the one that you recently uploaded.

Next, you create an IAM role to enable the SAML 2.0 federation to act as a trusted entity in your AWS account. For this step, you need to choose how you want to provision users in Amazon Quick. You can do one of the following:
+ Grant permission to the IAM role so that first-time visitors become Amazon Quick users automatically.

**To create an IAM role for a SAML 2.0 federation as a trusted entity**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. In the navigation pane, choose **Roles**, **Create Role**.

1. For **Select type of trusted entity**, choose the card labeled **SAML 2.0 federation**.

1. For **SAML provider**, select the IdP that you created in the previous procedure, for example `Okta`.

1. Enable the option **Allow programmatic and AWS Management Console access**.

1. Choose **Next: Permissions**.

1. Paste the following policy into the editor. 

   In the policy editor, update the JSON with your provider's Amazon Resource Name (ARN). 

   ```
   {
       "Version": "2012-10-17"		 	 	 ,
       "Statement": [
       {
           "Effect": "Allow",
           "Action": "sts:AssumeRoleWithSAML",
           "Resource": "arn:aws:iam::111111111111:saml-provider/Okta",
           "Condition": {
           "StringEquals": {
               "saml:aud": "https://signin.aws.amazon.com/saml"
           }
           }
       }
       ]
       }
   ```

1. Choose **Review policy**. 

1. For **Name**, enter **QuicksightOktaFederatedPolicy**, and then choose **Create policy**.

1. Choose **Create policy**, **JSON** a second time. 

1. Paste the following policy into the editor. 

   In the policy editor, update the JSON with your AWS account ID. It should be the same account ID that you used in the previous policy in the provider ARN.

   ```
   {
       "Version": "2012-10-17"		 	 	 ,
       "Statement": [
           {
               "Action": [
                   "quicksight:CreateReader"
               ],
               "Effect": "Allow",
               "Resource": [
                   "arn:aws:quicksight::111111111111:user/${aws:userid}"
               ]
           }
       ]
       }
   ```

   You can omit the AWS Region name in the ARN, as shown following.

   ```
   arn:aws:quicksight::111111111111:user/$${aws:userid}
   ```

1. Choose **Review policy**. 

1. For **Name**, enter **QuicksightCreateReader**, and then choose **Create policy**.

1. Refresh the list of policies by choosing the refresh icon at right. 

1. For **Search**, enter **QuicksightOktaFederatedPolicy**. Choose the policy to enable it (![\[alt text not found\]](http://docs.aws.amazon.com/quick/latest/userguide/images/checkbox-on.png)).

   If you don't want to use automatic provisioning, you can skip the following step. 

   To add a Amazon Quick user, use [register-user](https://docs.aws.amazon.com/quicksight/latest/APIReference/API_RegisterUser.html). To add a Amazon Quick group, use [create-group](https://docs.aws.amazon.com/quicksight/latest/APIReference/API_CreateGroup.html). To add users to the Amazon Quick group, use [create-group-membership](https://docs.aws.amazon.com/quicksight/latest/APIReference/API_CreateGroupMembership.html). 

1. (Optional) For **Search**, enter **QuicksightCreateReader**. Choose the policy to enable it (![\[alt text not found\]](http://docs.aws.amazon.com/quick/latest/userguide/images/checkbox-on.png)).

   Do this step if you want to provision Amazon Quick users automatically, rather than using the Amazon Quick API.

   The `QuicksightCreateReader` policy activates automatic provisioning by allowing use of the `quicksight:CreateReader` action. Doing this grants dashboard subscriber (reader-level) access to first-time users. A Amazon Quick administrator can later upgrade them from the Amazon Quick profile menu, **Manage Amazon Quick**, **Manage users**. 

1. To continue attaching the IAM policy or policies, choose **Next: Tags**. 

1. Choose **Next: Review**.

1. For **Role name**, enter **QuicksightOktaFederatedRole**, and choose **Create role**.

1. Verify that you completed this successfully by taking these steps:

   1. Return to the main page of the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). You can use your browser's **Back** button.

   1. Choose **Roles**. 

   1. For **Search**, enter Okta. Choose **QuicksightOktaFederatedRole** from the search results.

   1. On the **Summary** page for the policy, examine the **Permissions** tab. Verify that the role has the policy or policies that you attached to it. It should have `QuicksightOktaFederatedPolicy`. If you chose to add the ability to create users, it should also have `QuicksightCreateReader`.

   1. Use the ![\[alt text not found\]](http://docs.aws.amazon.com/quick/latest/userguide/images/caret-right-filled.png) icon to open each policy. Verify that the text matches what is shown in this procedure. Double-check that you added your own AWS account number in place of the example account number 111111111111. 

   1. On the **Trust relationships** tab, verify that the **Trusted entities** field contains the ARN for the identity provider. You can double-check the ARN in the IAM console by opening **Identity providers**, **Okta**. 

**To create an access key for Okta**

1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).

1. Add a policy that allows Okta to display a list of IAM roles to the user. To do this, choose **Policy**, **Create policy**. 

1. Choose **JSON**, then enter the following policy.

   ```
   {
       "Version": "2012-10-17"		 	 	 ,
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "iam:ListRoles",
                   "iam:ListAccountAliases"
               ],
               "Resource": "*"
           }
       ]
       }
   ```

1. Choose **Review Policy**.

1. For **Name**, enter **OktaListRolesPolicy**. Then choose **Create policy**.

1. Add a user so you can provide Okta with an access key. 

   In the navigation pane, choose **Users**, **Add User**.

1. Use the following settings:
   + For **User name**, enter `OktaSSOUser`.
   + For **Access type**, enable **Programmatic access**.

1. Choose **Next: Permissions**.

1. Choose **Attach existing policies directly**.

1. For **Search**, enter **OktaListRolesPolicy**, and choose **OktaListRolesPolicy** from the search results. 

1. Choose **Next: Tags**, and then choose **Next: Review**. 

1. Choose **Create user**. Now you can get the access key.

1. Download the key file by choosing **Download .csv**. The file contains the same access key ID and secret access key that displays on this screen. However, because AWS doesn't display this information a second time, make sure to download the file.

1. Verify that you completed this step correctly by doing the following:

   1. Open the IAM console, and choose **Users**. Search for **OktaSSOUser**, and open it by choosing the username from the search results.

   1. On the **Permissions** tab, verify that the **OktaListRolesPolicy** is attached. 

   1. Use the ![\[alt text not found\]](http://docs.aws.amazon.com/quick/latest/userguide/images/caret-right-filled.png) icon to open the policy. Verify that the text matches what is shown in this procedure. 

   1. On the **Security credentials** tab, you can check the access key, although you already downloaded it. You can return to this tab to create an access key when you need a new one.

In the following procedure, you return to Okta to provide the access key. The access key works with your new security settings to allow AWS and the Okta IdP to work together.

**To finish configuring the Okta application with AWS settings**

1. Return to your Okta dashboard. If requested to do so, sign in. If the developer console is no longer open, choose **Admin** to reopen it.

1. If you have to reopen Okta, you can return to this section by following these steps:

   1. Sign in to Okta. Choose **Applications**.

   1. Choose **AWS Account Federation - Amazon Quick**—the application that you created at the beginning of this tutorial.

   1. Choose the **Sign On** tab, between **General** and **Mobile**.

1. Scroll to **Advanced Sign-On Settings**.

1. For **Identity Provider ARN (Required only for SAML IAM federation)**, enter the provider ARN from the previous procedure, for example: 

   ```
   arn:aws:iam::111122223333:saml-provider/Okta
   ```

1. Choose **Done** or **Save**. The name of the button varies depending if you are creating or editing the application.

1. Choose the **Provisioning** tab, and at the lower part of the tab, choose **Configure API Integration**.

1. Turn on **Enable API integration** to display the settings.

1. For **Access Key** and **Secret Key**, provide the access key and secret key that you downloaded previously to a file named **OktaSSOUser**`_credentials.csv`.

1. Choose **Test API Credentials**. Look above the **Enable API integration** setting for a message confirming that **AWS Account Federation was verified successfully**.

1. Choose **Save**.

1. Make sure that **To App** is highlighted at left, and choose **Edit** at right.

1. For **Create Users**, turn on the option **Enable**.

1. Choose **Save**.

1. On the **Assignments** tab, near **Provisioning** and **Import**, choose **Assign**.

1. Do one or more of the following to enable federated access:
   + To work with individual users, choose **Assign to People**.
   + To work with IAM groups, choose **Assign to Groups**. You can choose specific IAM groups or **Everyone (All users in your organization)**.

1. For each IAM user or group, do the following:

   1. Choose **Assign**, **Role**.

   1. Select **QuicksightOktaFederatedRole** from the list of IAM roles.

   1. For **SAML User Roles**, enable **QuicksightOktaFederatedRole**.

1. Choose **Save and Go Back**, and then choose **Done**.

1. Verify that you completed this step correctly by choosing the **People** or **Groups** filter at left, and checking the users or groups that you entered. If you can't complete this process because the role that you created doesn't appear in the list, return to the previous procedures to verify the settings.

**To sign in to Amazon Quick using Okta (IdP to service provider sign-in)**

1. If you are using an Okta administrator account, switch to user mode. 

1. Sign in to your Okta Applications dashboard with a user that has been granted federated access. You should see a new application with your label, for example **AWS Account Federation - Amazon Quick**. 

1. Choose the application icon to launch **AWS Account Federation - Amazon Quick**.

You can now manage identities using Okta and use federated access with Quick.

The following procedure is an optional part of this tutorial. If you follow its steps, you authorize Amazon Quick to forward authorizations requests to the IdP on behalf of your users. Using this method, users can sign in to Amazon Quick with no need to sign in using the IdP page first.

**(Optional) To set up Amazon Quick to send authentication requests to Okta**

1. Open Amazon Quick, and choose **Manage Amazon Quick** from your profile menu.

1. Choose **Single sign-on (IAM federation)** from the navigation pane.

1. For **Configuration**, **IdP URL**, enter the URL that your IdP provides to authenticate users, for example https://dev-*1-----0*.okta.com/home/amazon\$1aws/*0oabababababaGQei5d5/282*. You can find this in your Okta app page, on the **General** tab, in **Embed Link**.

1. For **IdP URL**, enter `RelayState`. 

1. Do one of the following: 
   + To test signing in with your identity provider first, use the custom URL provided in **Test starting with your IdP**. You should arrive at the start page for Amazon Quick, for example https://quicksight.aws.amazon.com/sn/start.
   + To test signing in with Amazon Quick first, use the custom URL provided in **Test the end-to-end experience**. The `enable-sso` parameter is appended to the URL. If `enable-sso=1`, IAM federation attempts to authenticate. If `enable-sso=0`, Amazon Quick doesn't send the authentication request, and you sign in to Amazon Quick as before.

1. For **Status**, choose **ON**.

1. Choose **Save** to keep your settings.

You can create a deep link to a Amazon Quick dashboard to allow users to use IAM federation to connect directly to specific dashboards. To do this, you append the relay state flag and dashboard URL to the Okta single sign-on URL, as described following.

**To create a deep link to a Amazon Quick dashboard for single sign-on**

1. Locate the Okta application’s single sign-on (IAM federation) URL in the `metadata.xml` file that you downloaded beginning of the tutorial. You can find the URL near the bottom of the file, in the element named `md:SingleSignOnService`. The attribute is named `Location` and the value ends with `/sso/saml`, as shown in the following example.

   ```
   <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://dev-0000001.okta.com/app/amazon_aws/abcdef2hATwiVft645d5/sso/saml"/>
   ```

1. Take the value of the IAM federation URL and append `?RelayState=` followed by the URL of your Amazon Quick dashboard. The `RelayState` parameter relays the state (the URL) that the user was in when they were redirected to the authentication URL.

1. To the new IAM federation with the relay state added, append the URL of your Amazon Quick dashboard. The resulting URL should resemble the following.

   ```
   https://dev-1-----0.okta.com/app/amazon_aws/abcdef2hATwiVft645d5/sso/saml?RelayState=https://us-west-2.quicksight.aws.amazon.com/sn/analyses/12a12a2a-121a-212a-121a-abcd12abc1ab
   ```

1. If the link you create doesn't open, check that you are using the most recent IAM federation URL from the `metadata.xml`. Also check that the username you use to sign in isn't assigned in more than one IAM federation Okta app.