Big Data

Configure ADFS Id Federation with Amazon QuickSight

Configure ADFS Id Federation with Amazon QuickSight
Written by admin


Amazon QuickSight Enterprise version can combine along with your current Microsoft Lively Listing (AD), offering federated entry utilizing Safety Assertion Markup Language (SAML) to dashboards. Utilizing current identities from Lively Listing eliminates the necessity to create and handle separate person identities in AWS Id Entry Administration (IAM). Federated customers assume an IAM function when entry is requested via an identification supplier (IdP) equivalent to Lively Listing Federation Service (AD FS) primarily based on AD group membership. Though, you may join AD to QuickSight utilizing AWS Listing Service, this weblog focuses on federated logon to QuickSight Dashboards.

With identification federation, your customers get one-click entry to Amazon QuickSight purposes utilizing their current identification credentials. You even have the safety advantage of identification authentication by your IdP. You possibly can management which customers have entry to QuickSight utilizing your current IdP. Consult with Utilizing identification federation and single sign-on (SSO) with Amazon QuickSight for extra info.

On this put up, we reveal how you need to use a company e mail handle as an authentication possibility for signing in to QuickSight. This put up assumes you’ve an current Microsoft Lively Listing Federation Companies (ADFS) configured in your setting.

Answer overview

Whereas connecting to QuickSight from an IdP, your customers provoke the sign-in course of from the IdP portal. After the customers are authenticated, they’re routinely signed in to QuickSight. After QuickSight checks that they’re approved, your customers can entry QuickSight.

The next diagram exhibits an authentication circulate between QuickSight and a third-party IdP. On this instance, the administrator has arrange a sign-in web page to entry QuickSight. When a person indicators in, the sign-in web page posts a request to a federation service that complies with SAML 2.0. The tip-user initiates authentication from the sign-in web page of the IdP. For extra details about the authentication circulate, see Initiating sign-on from the identification supplier (IdP).

QuickSight IdP flow

The answer consists of the next high-level steps:

  1. Create an identification supplier.
  2. Create IAM insurance policies.
  3. Create IAM roles.
  4. Configure AD teams and customers.
  5. Create a relying social gathering belief.
  6. Configure declare guidelines.
  7. Configure QuickSight single sign-on (SSO).
  8. Configure the relay state URL for QuickStart.

Conditions

The next are the stipulations to construct the answer defined on this put up:

  • An current or newly deployed AD FS setting.
  • An AD person with permissions to handle AD FS and AD group membership.
  • An IAM person with permissions to create IAM insurance policies and roles, and administer QuickSight.
  • The metadata doc out of your IdP. To obtain it, check with Federation Metadata Explorer.

Create an identification supplier

So as to add your IdP, full the next steps:

  1. On the IAM console, select Id suppliers within the navigation pane.
  2. Select Add supplier.
  3. For Supplier kind¸ choose SAML.
  4. For Supplier title, enter a reputation (for instance, QuickSight_Federation).
  5. For Metadata doc, add the metadata doc you downloaded as a prerequisite.
  6. Select Add supplier.
  7. Copy the ARN of this supplier to make use of in a later step.

Add IdP in IAM

Create IAM insurance policies

On this step, you create IAM insurance policies that enable customers to entry QuickSight solely after federating their identities. To offer entry to QuickSight and in addition the flexibility to create QuickSight admins, authors (normal customers), and readers, use the next coverage examples.

The next code is the creator coverage:

{
    "Assertion": [
        {
            "Action": [
                "quicksight:CreateUser"
            ],
            "Impact": "Permit",
            "Useful resource": [
                "*"
            ]
        }
    ],
    "Model": "2012-10-17"
}

The next code is the reader coverage:

{ 
"Model": "2012-10-17", 
"Assertion": [ 
{ 
"Effect": "Allow",
"Action": "quicksight:CreateReader", 
"Resource": "*" 
} 
] 
}

The next code is the admin coverage:

{
    "Assertion": [
        {
            "Action": [
                "quicksight:CreateAdmin"
            ],
            "Impact": "Permit",
            "Useful resource": [
                "*"
            ]
        }
    ],
    "Model": "2012-10-17"
}

Create IAM roles

You possibly can configure e mail addresses on your customers to make use of when provisioning via your IdP to QuickSight. To do that, add the sts:TagSession motion to the belief relationship for the IAM function that you simply use with AssumeRoleWithSAML. Be sure the IAM function names begin with ADFS-.

  1. On the IAM console, select Roles within the navigation pane.
  2. Select Create new function.
  3. For Trusted entity kind, choose SAML 2.0 federation.
  4. Select the SAML IdP you created earlier.
  5. Choose Permit programmatic and AWS Administration Console entry.
  6. Select Subsequent.
    Create IAM Roles
  7. Select the admin coverage you created, then select Subsequent.
  8. For Identify, enter ADFS-ACCOUNTID-QSAdmin.
  9. Select Create.
  10. On the Belief relationships tab, edit the belief relationships as follows so you may cross principal tags when customers assume the function (present your account ID and IdP):
{
    "Model": "2012-10-17",
    "Assertion": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::ACCOUNTID:saml-provider/Identity_Provider"
            },
            "Action":[ "sts:AssumeRoleWithSAML",
	 "sts:TagSession"],
            "Situation": {
                "StringEquals": {
                    "SAML:aud": "https://signin.aws.amazon.com/saml"
                },
                "StringLike": {
                    "aws:RequestTag/Electronic mail": "*"
                }
            }
            }
    ]
}

  1. Repeat this course of for the function ADFS-ACCOUNTID-QSAuthor and fix the creator IAM coverage.
  2. Repeat this course of for the function ADFS-ACCOUNTID-QSReader and fix the reader IAM coverage.

Configure AD teams and customers

Now it’s essential to create AD teams that decide the permissions to register to AWS. Create an AD safety group for every of the three roles you created earlier. Observe that the group title ought to comply with identical format as your IAM function names.

One strategy for creating the AD teams that uniquely establish the IAM function mapping is by choosing a typical group naming conference. For instance, your AD teams would begin with an identifier, for instance AWS-, which is able to distinguish your AWS teams from others throughout the group. Subsequent, embody the 12-digit AWS account quantity. Lastly, add the matching function title throughout the AWS account. It is best to do that for every function and corresponding AWS account you want to help with federated entry. The next screenshot exhibits an instance of the naming conference we use on this put up.

AD Groups

Later on this put up, we create a rule to choose up AD teams beginning with AWS-, the rule will take away AWS-ACCOUNTID- from AD teams title to match the respective IAM function, which is why we use this naming conference right here.

Customers in Lively Listing can subsequently be added to the teams, offering the flexibility to imagine entry to the corresponding roles in AWS. You possibly can add AD customers to the respective teams primarily based on your corporation permissions mannequin. Observe that every person should have an e mail handle configured in Lively Listing.

Create a relying social gathering belief

So as to add a relying social gathering belief, full the next steps:

  1. Open the AD FS Administration Console.
  2. Select (right-click) Relying Get together Trusts, then select Add Relying Get together Belief.
    Add Relying Party Trust
  3. Select Claims conscious, then select Begin.
  4. Choose Import information concerning the relying social gathering printed on-line or on a neighborhood community.
  5. For Federation metadata handle, enter https://signin.aws.amazon.com/static/saml-metadata.xml.
  6. Select Subsequent.
    ADFS Wizard Data Source
  7. Enter a descriptive show title, for instance Amazon QuickSight Federation, then select Subsequent.
  8. Select your entry management coverage (for this put up, Allow everybody), then select Subsequent.
    ADFS Access Control
  9. Within the Able to Add Belief part, select Subsequent.
    ADFS Ready to Add
  10. Depart the defaults, then select Shut.

Configure declare guidelines

On this part, you create declare guidelines that establish accounts, set LDAP attributes, get the AD teams, and match them to the roles created earlier. Full the next steps to create the declare guidelines for NameId, RoleSessionName, Get AD Teams, Roles, and (optionally) Session Length:

  1. Choose the relying social gathering belief you simply created, then select Edit Declare Issuance Coverage.
  2. Add a rule referred to as NameId with the next parameters:
    1. For Declare rule template, select Remodel an Incoming Declare.
    2. For Declare rule title, enter NameId
    3. For Incoming declare kind, select Home windows account title.
    4. For Outgoing declare kind, select Identify ID.
    5. For Outgoing title ID format, select Persistent Identifier.
    6. Choose Go via all declare values.
    7. Select End.
      NameId
  3. Add a rule referred to as RoleSessionName with the next parameters:
    1. For Declare rule template, select Ship LDAP Attributes as Claims.
    2. For Declare rule title, enter RoleSessionName.
    3. For Attribute retailer, select Lively Listing.
    4. For LDAP Attribute, select E-Mail-Addresses.
    5. For Outgoing declare kind, enter https://aws.amazon.com/SAML/Attributes/RoleSessionName.
    6. Add one other E-Mail-Addresses LDAP attribute and for Outgoing declare kind, enter https://aws.amazon.com/SAML/Attributes/PrincipalTag:Electronic mail.
    7. Select OK.
      RoleSessionName
  4. Add a rule referred to as Get AD Teams with the next parameters:
    1. For Declare rule template, select Ship Claims Utilizing a Customized Rule.
    2. For Declare rule title, enter Get AD Teams
    3. For Customized Rule, enter the next code:
      c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add(retailer = "Lively Listing", varieties = ("http://temp/variable"), question = ";tokenGroups;{0}", param = c.Worth);

    4. Select OK.
      Get AD Groups
  1. Add a rule referred to as Roles with the next parameters:
    1. For Declare rule template, select Ship Claims Utilizing a Customized Rule.
    2. For Declare rule title, enter Roles
    3. For Customized Rule, enter the next code (present your account ID and IdP):
      c:[Type == "http://temp/variable", Value =~ "(?i)^AWS-ACCOUNTID"]=> concern(Sort = "https://aws.amazon.com/SAML/Attributes/Position", Worth = RegExReplace(c.Worth, "AWS-ACCOUNTID-", "arn:aws:iam:: ACCOUNTID:saml-provider/your-identity-provider-name,arn:aws:iam:: ACCOUNTID:function/ADFS-ACCOUNTID-"));

    4. Select End.Roles

Optionally, you may create a rule referred to as Session Length. This configuration determines how lengthy a session is open and lively earlier than customers are required to reauthenticate. The worth is in seconds. For this put up, we configure the rule for 8 hours.

  1. Add a rule referred to as Session Length with the next parameters:
    1. For Declare rule template, select Ship Claims Utilizing a Customized Rule.
    2. For Declare rule title, enter Session Length.
    3. For Customized Rule, enter the next code:
      => concern(Sort = "https://aws.amazon.com/SAML/Attributes/SessionDuration", Worth = "28800");

    4. Select End.Session Duration

It is best to be capable to see these 5 declare guidelines, as proven within the following screenshot.
All Claims Rules

  1. Select OK.
  2. Run the next instructions in PowerShell in your AD FS server:
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

Set-AdfsProperties -EnableRelayStateForIdpInitiatedSignOn $true

  1. Cease and begin the AD FS service from PowerShell:
internet cease adfssrv

internet begin adfssrv

Configure E-mail Syncing

With QuickSight Enterprise version built-in with an IdP, you may limit new customers from utilizing private e mail addresses. This implies customers can solely log in to QuickSight with their on-premises configured e mail addresses. This strategy permits customers to bypass manually coming into an e mail handle. It additionally ensures that customers can’t use an e mail handle which may differ from the e-mail handle configured in Lively Listing.

QuickSight makes use of the preconfigured e mail addresses handed via the IdP when provisioning new customers to your account. For instance, you may make it in order that solely corporate-assigned e mail addresses are used when customers are provisioned to your QuickSight account via your IdP. While you configure e mail syncing for federated customers in QuickSight, customers who log in to your QuickSight account for the primary time have preassigned e mail addresses. These are used to register their accounts.

To configure E-mail syncing for federated customers in QuickSight, full the next steps:

  1. Log in to your QuickSight dashboard with a QuickSight administrator account.
  2. Select the profile icon.
    QuickSight SSO
  3. On the drop-down menu, select on Handle QuickSight.
  4. Within the navigation pane, select Single sign-on (SSO).
  5. For Electronic mail Syncing for Federated Customers, choose ON, then select Allow within the pop-up window.
  6. Select Save.SSO Configuration

Configure the relay state URL for QuickStart

To configure the relay state URL, full the next steps (revise the enter info as wanted to match your setting’s configuration):

  1. Use the ADFS RelayState Generator to generate your URL.
  2. For IDP URL String, enter https://ADFSServerEndpoint/adfs/ls/idpinitiatedsignon.aspx.
  3. For Relying Get together Identifier, enter urn:amazon:webservices or https://signin.aws.amazon.com/saml.
  4. For Relay State/Goal App, enter your authenticated customers to entry. On this case, it’s https://quicksight.aws.amazon.com.
  5. Select Generate URL.RelayState Generator
  6. Copy the URL and cargo it in your browser.

You need to be introduced with a login to your IdP touchdown web page.

ADFS Logon Page

Be sure the person logging in has an e mail handle attribute configured in Lively Listing. A profitable login ought to redirect you to the QuickSight dashboard after authentication. In the event you’re not redirected to the QuickSight dashboard web page, be sure you ran the instructions listed earlier after you configured your declare guidelines.

Abstract

On this put up, we demonstrated tips on how to configure federated identities to a QuickSight dashboard and make sure that customers can solely register with preconfigured e mail handle in your current Lively Listing.

We’d love to listen to from you. Tell us what you suppose within the feedback part.


Concerning the Writer

Adeleke Coker is a World Options Architect with AWS. He helps clients globally speed up workload deployments and migrations at scale to AWS. In his spare time, he enjoys studying, studying, gaming and watching sport occasions.

About the author

admin

Leave a Comment