Do You need an AI ASSISTANT? Let’s build it using Amazon Q! (Part 2)
Tags: ai, genai, aws, data
Published: 2024-02-03 23:31:08

In my [previous post](https://dev.to/aws-builders/do-you-need-an-ai-assistant-lets-build-it-using-amazon-q-part-1-3bh5), I shared how to implement an **AI assistant** using the features available in the recently launched **Amazon Q for Business service**.

Overall scope was to build that **AI assistant** to take advantage of a **Knowledge Base** including information from **the internet, document repositories and uploaded relevant documents**.

Until that moment, we had our **AI Assistant** already operating for **internal use**. We need now to take the next step to **DEPLOY the AI Assistant to our organization** so we can have **multiple users** leveraging its capabilities with the **required security measures in place**.

Let’s see now the **process and lessons learned** during the **deployment** of an **AI Assistant** using **Amazon Q for Business**!

**Integrating our AI Assistant with an Identity Provider**

The first step that we need to follow to deploy the **Amazon Q web experience**, web user interface that we are using to interact with our **AI Assistant**, is to integrate it with a **system/service** that will **authenticate and authorize the access of users** in our organization.

Similarly to the **various alternatives** that are available to integrate with **data sources**, Amazon Q offers various alternatives of an **identity provider (IdP)** that’s compliant with **SAML 2.0**.

The **identity providers** currently supported by Amazon Q include AWS IAM Identity Center, Okta, Microsoft EntraID, and PingIdentity.

**Amazon Q** acts as a **service provider (SP)** that **requests user authentication and authorization** from an **identity provider (IdP)**. The **IdP authenticates** the user’s identity and **provides attributes** about the user to **Amazon Q**. **Amazon Q** then **authorizes the user’s session** based on these attributes.

**Security Assertion Markup Language (SAML)** is used to transfer **user identity data** between the IdP and Amazon Q in a standardized way. Some key points about integrating an IdP with Amazon Q:

- **Authentication** confirms a user’s identity by verifying they are who they say they are;
- **Authorization** allows users certain permissions or access to resources;
- The **IdP** stores, manages and verifies user identities for applications like **Amazon Q**;
- **Amazon Q** uses service-initiated single sign-on (SSO) to authenticate users. **IdP-initiated SSO is not supported**.

For our use case, I decided to use **AWS IAM Identity Center** as our **Identity Provider**. We need to follow preparation steps to proceed with the integration.

**Enabling an IAM Identity Center instance**

We need to enable **IAM Identity Center** using the service console:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v1xev48t3ojjoglrvjpy.jpg)

At this point there is an important decision to be taken related to the **type of instance** for IAM Identity Center: **organization instances** or **account instances**. Let’s briefly understand the characteristics of each one:

- **Organization instances of IAM Identity Center:** When we enable IAM Identity Center in conjunction with **AWS Organizations**, we are creating an **organization instance** of IAM Identity Center. An **organization instance** is the **primary method** of enabling IAM Identity Center as it provides support for **all features** of IAM Identity Center including managing permissions for multiple AWS accounts in your organization and **assigning access to customer managed applications**.

- **Account instances of IAM Identity Center:** Account instances are bound to a single AWS account and are used only to manage user and group access for supported applications in the same account and AWS Region. Supported applications are AWS managed applications and OIDC-based customer managed applications. **OpenID Connect (OIDC)** is a standard for identity federation.

Looking at a summary of the capabilities available for each instance type:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/au864qzty6tnolrm3598.jpg)

Based on the previous definitions, we need to select an **organization instance of IAM Identity Center** due to, at least, two reasons: (1) We need to be able to integrate with **Customer-managed applications** (that is the case of our **Amazon Q for business application**) and (2) We need that the authentication and authorization process uses the **SAML** standard. Both requisites are not supported by an **Account instance of IAM Identity Center**.

If you hadn’t created an **AWS organization** before, the process to enable an **organization instance** will automatically create an AWS Organization in the background assigning the account that we are using as **management account**.

After the creation of the **organization instance**, we need to confirm our **identity source**. The **identity source** is where we administer users and groups, and it is the service that authenticates our users. By default, **IAM Identity Center** creates an **Identity Center directory**. For our use case we will use this default option.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rbo238ja035vjxswxuwv.jpg)

Note in the previous image that there is an **AWS access portal URL** being shown here. It’s important to highlight that our **AI Assistant** will appear in that portal, but **we won’t be able to access it using the portal**. This is because **IdP-initiated SSO is not supported** by Amazon Q. We will see later how we will access our AI Assistant.

Moving forward, we need to create at least **one valid user** with a **valid e-mail address** and, optionally but highly recommended, create **groups** and assign users to them. **Users and/or groups** will be used later to enable **access to our AI assistant**.

For our **use case**, we created **one group with one user** to test the access, including the **activation of MFA** as a **security measure** already available as part of the process:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lsl9hbfhpyi314raih5f.jpg)

At this moment, we are ready to begin the integration of our **AI Assistant** with **IAM Identity Center**. To start the process, we need to come back to the **Amazon Q console** and “Edit” the **Web Experience settings**:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3t9g9tdc0uc3akuzaiqd.jpg)

Following the steps detailed in [Setting up Amazon Q with IAM Identity Center as identity provider — Amazon Q](https://docs.aws.amazon.com/amazonq/latest/business-use-dg/idp-sso.html), we will complete the configuration of both **Amazon Q** and its integration with **IAM Identity Center**, executing **carefully** a series of steps in both **services console**.

At the end of this process, in **IAM Identity Center**, we will have our **AI Assistant application** configured with the **assignment of authorized group/user**, as you can see in the following image:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r6pvz7gun8swyccougqs.jpg)

On the side of **Amazon Q**, in the **Web experience settings** section we will have the information about the **service role** created to authorize Amazon Q to provision the resources required for the deployment and mainly the **Deployed URL that is the URL that the users will use to access our AI assistant application!!**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xaz1vrtvh1bsvv90be8c.jpg)

Now we are ready to test the access of our **user** to our **AI assistant** application. To do that, we can click on the **Deployed URL** and start the process. As you can see in the following image, the integration with **IAM Identity Center** will be actioned and we will need to **sign-in** into the application:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z3w6qdrwcdw9dj9umdvy.jpg)

And **take advantage of MFA** to **enhance the security** to our application:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wi0ejozvfpi4tzhfsvpw.jpg)

Completing this process, we will get **authorized access** to our **AI assistant** and the user is **READY TO GO to explore use cases that we described in the previous post!!**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1tyk6ewtm5aem0mroy8m.jpg)

At this point, we have accomplished the objective to **deploy our AI assistant** using a **WEB EXPERIENCE** user interface with access enabled for our **authorized user**.

As from here, defining what will be our **actual team of users**, we can extend the configuration of **IAM Identity Center** and, through the proper **communication channels** and in **compliance with the corporate policies**, release access to our **AI assistant for a broader group**.

In case your organization has different identity providers, like **Microsoft Entra ID (formerly Azure Active Directory)** or others, you can also perform the required configuration as needed.

As in the case of **data**, I understand that **these integration capabilities of Amazon Q with different Identity providers** helps to **mitigate adoption barriers** and contributes to **fulfill the strong expectation of organizations** to have a **secure access to the AI assistant that will provide access to very valuable corporate information and documentation**.

Now that we have completed this deployment step, **what could be the next step?**

What about integrating our **corporate applications and/or platforms** with the AI assistant not through a web interface but through **APIs**?

This could be a very interesting example of the **utilization of our AI assistant’s insights** to **enhance the execution of our Business/IT processes** and our **team’s collaboration, don’t you agree?**

**Let’s meet again in our next post and please feel free to share your feedback and comments!**