Hello!
I have couple of questions about quicksight configuration.
Our goal is to use quicksight as an embedded application and configure user provisioning as automated as possible.
We have Keycloak as our Identity Provider and we want to avoid the creation of IAM user for each Keycloak user we have.
Does quicksight user should be considered as IAM user?
RegisterUser endpoint with an IdentityType = IAM will register existed IAM user in quicksight and no further account activation will be needed, am I right?
RegisterUser endpoint with an IdentityType = IAM_Identity_Center can be used to configure OIDC user authentication via Keycloak. Right? Is this configured per user?
What is the difference between configuring SSO on Quicksight Manage page vs configuring IAM Identity Center?
We ventured into this sometime back and I can share my experience which is based on how we ended up configuring the setup.
a. Enabling SSO in Quick Sight Manage SSO means you are enabling SSO for all users. So you can’t then have a email id based user and another as a SSO authenticated user. Additionally, the SSO enabled is for just one Identity provider. This is fine if you are doing it for a single organization. In our case we have Quick Sight supporting different customers and wanted to enable Federated login for multiple customers who may have different Identity providers. So we ruled this out
b. Federated user can be created using the register-user command with Identity type as IAM and a role that has the requisite policies assigned (Admin, Author, Reader role with required policy for each role). The link below for SAML based Identity Provider initiated SSO authentication is what we used Enabling Amazon QuickSight federation with Microsoft Entra ID (formerly Azure AD) | AWS Big Data Blog
c. I guess both SAML and OIDC should work similarly in the Federated login. The specific details of the setup may differ a bit, but you should be able to sort it out by reaching out to AWS through a support request.
Hi @Giridhar.Prabhu
Thank you for your answer. I wanted to ask a couple of clarifying questions because I’m interested in the difference between configuring an IAM Identity Provider (as mentioned in the article) versus using the RegisterUser API.
If I configure the IAM Identity Provider and set the quicksight:CreateAdmin permission, does that mean the user should self-provision and register their email on Quick Sight?
And if we register a user via the RegisterUser API with the IAM type and a specified OIDC provider, will the user be able to use Quick Sight without additional self-provisioning?
Using the RegisterUser API you are kind of pre-provisioning the user.
Howerver, if you setup the IAM Identity Provider as documented in the Article the user is provisioned in AWS the first time he accesses the Quick Sight App via his IdP website/homepage. He is not going to require registration on the Quick Sight login page.
There is a one-to-one relationship between the Group assignment on the IdP side to the role in the AWS side. So, if you assigned a user to the Reader Group on the IdP then a AWS IAM account with the CreateUser (Reader) privilege is created the first time this user accesses Quick Sight. No login screen appears as the authentication has already been done by the IdP and you have setup trust relationship with this App in AWS.
Hi @bshevtsov,
Since we haven’t heard back, I’ll close out this topic. However, if you have any additional questions, feel free to create a new post in the community and link this discussion for relevant information if needed.