Amazon Q Business chat-sync CLI command always failing

5

I've tried using both the aws qbusiness chat-sync CLI command and the underlying API but can't get either to work even though I'm using a user with full "qbusiness:*" access to all "*" resources.

Both
aws qbusiness chat-sync --application-id <my-app-guid>
and
aws qbusiness chat-sync --application-id <my-app-guid> --user-id <my-user-id-tried-both-email-address-username-and-user-guid>

always return "An error occurred (AccessDeniedException) when calling the ChatSync operation: User is not authorized for this service call."

Using THE VERY SAME USER I can log in via the Amazon Q Web Experience and all is fine, just can't chat via CLI / API. I can also call other CLIs / APIs fine using the same creds, for example I can successfully call both BatchPutDocument and BatchDeleteDocument but ChatSync always fails with "An error occurred (AccessDeniedException) when calling the ChatSync operation: User is not authorized for this service call."

  • It is possible the window in which you are running the code might not be getting AWS credentials

    1. Please post the output with --debug flag.
    2. Try to perform other AWS CLI API like aws s3 ls
  • I can perform ALL other AWS CLI operations in the very same CLI session/window. This is the only one that fails so perhaps just an Amazon Q Business bug?

  • I just tested the aws-cli chat-sync api. Please share output of the command adding --debug flag at the end of the cli command.

    `aws qbusiness chat-sync --application-id 818ab2cd-xxxx-xxxx-xxxx-123456ebf8a3 --user-id abcd --user-message "test" --debug

  • Here is the output of running the CLI command with the --debug flag. I have only replaced security tokens & signatures in the output. These comment windows only allow 1500 characters so I'll have to split into multiple comments. Part 1:

    2024-05-02 08:09:12,140 - MainThread - botocore.credentials - DEBUG - Credentials need to be refreshed.
    2024-05-02 08:09:12,142 - MainThread - urllib3.connectionpool - DEBUG - http://localhost:1338 "GET /latest/meta-data/container/security-credentials HTTP/1.1" 200 1400
    2024-05-02 08:09:12,143 - MainThread - botocore.credentials - DEBUG - Retrieved credentials will expire at: 2024-05-02 08:23:26+00:00
    2024-05-02 08:09:12,144 - MainThread - botocore.auth - DEBUG - Calculating signature using v4 auth.
    2024-05-02 08:09:12,144 - MainThread - botocore.auth - DEBUG - CanonicalRequest:
    POST
    /applications/056ac616-ce88-4e16-bdfc-fcfa0f2e102e/conversations
    sync=&userId=c4c89438-50a1-7041-c450-513b6a69825d
    content-type:application/json
    host:qbusiness.us-east-1.api.aws
    x-amz-date:20240502T080912Z
    x-amz-security-token: replaced
    content-type;host;x-amz-date;x-amz-security-token
    replaced
    2024-05-02 08:09:12,144 - MainThread - botocore.auth - DEBUG - StringToSign:
    AWS4-HMAC-SHA256
    20240502T080912Z
    20240502/us-east-1/qbusiness/aws4_request
    243aacdaf916367c838ec0518f4fc1dac7933d29425dab0fd337c01428d3f4ff
    2024-05-02 08:09:12,144 - MainThread - botocore.auth - DEBUG - Signature:
    replaced
    
  • Part 2:

    2024-05-02 08:09:12,144 - MainThread - botocore.endpoint - DEBUG - Sending http request: <AWSPreparedRequest stream_output=False, method=POST, url=https://qbusiness.us-east-1.api.aws/applications/056ac616-ce88-4e16-bdfc-fcfa0f2e102e/conversations?sync&userId=c4c89438-50a1-7041-c450-513b6a69825d, headers={'Content-Type': b'application/json', 'User-Agent': b'aws-cli/2.15.42 Python/3.11.8 Linux/6.1.84-99.169.amzn2023.x86_64 exec-env/CloudShell exe/x86_64.amzn.2023 prompt/off command/qbusiness.chat-sync', 'X-Amz-Date': b'20240502T080912Z', 'X-Amz-Security-Token': b'replaced', 'Authorization': b'AWS4-HMAC-SHA256 Credential=replaced/20240502/us-east-1/qbusiness/aws4_request, SignedHeaders=content-type;host;x-amz-date;x-amz-security-token, Signature=replaced', 'Content-Length': '78'}>
    2024-05-02 08:09:12,145 - MainThread - botocore.httpsession - DEBUG - Certificate path: /usr/local/aws-cli/v2/2.15.42/dist/awscli/botocore/cacert.pem
    2024-05-02 08:09:12,146 - MainThread - urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): qbusiness.us-east-1.api.aws:443
    2024-05-02 08:09:12,342 - MainThread - urllib3.connectionpool - DEBUG - https://qbusiness.us-east-1.api.aws:443 "POST /applications/056ac616-ce88-4e16-bdfc-fcfa0f2e102e/conversations?sync&userId=c4c89438-50a1-7041-c450-513b6a69825d HTTP/1.1" 403 59
    
6 Answers
2
Accepted Answer
debadm
answered 2 months ago
profile picture
EXPERT
reviewed 11 days ago
0

Hi There

The --user-id that you pass in the chat-sync CLI command is not the same as the user ID that is making the CLI call.

Please run aws sts get-caller-identity which will show you the current IAM identity/role, and verify the user has the expected permissions. [1]

If you are logged into the AWS Console using SSO, youll probably see something like "Arn": "arn:aws:sts::1234567890:assumed-role/roleName" in the output

This is the IAM role that you are assuming when you run the CLI command. Verify that Role has the appropriate permissions

[1] https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/get-caller-identity.html

profile pictureAWS
EXPERT
Matt-B
answered 2 months ago
profile picture
EXPERT
A_J
reviewed 2 months ago
  • I ran aws sts get-caller-identity to confirm and yes as expected it is an assumed role. That role has the AdministratorAccess AWS managed - job function policy assigned which allows full access to absolutely everything and still it doesn't work (like I say ALL other CLI commands do work from same CLI session). The AWS managed AdministratorAccess policy looks like this:

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

    so I don't see what more permissions I can give it.

  • Have also tried via direct accessKeyId/secretAccessKey user creds (rather than an assumed role) with exactly the same outcome. Perhaps it's more to do with the --user-id parameter than who I'm calling as. The docs aren't clear what this user-id is although I've tried everything I can think of and the user is always one with access to the Q Business App and can log in and chat fine via the web experience (I've tried a user with both a Q Buisness Lite and a Q Business Pro subscription). I wonder if anyone has actually got this ChatSync API to work. Would be great to hear some specifics from someone on the --user-id parameter and their user setup.

0

The resolution to the AccessDeniedException issue people faced while calling the chat-sync API was provided 18 days ago by debadm. Granted, it is neither a simple nor easy workaround to what we have been able to do with the chat-sync API before 30 April (the day Q Business went GA). But try to appreciate the reasons behind this "tightening" of identity.

In the past (before 30 April), one could masquerade as ANY user by using the --user-id parameter. Now, you don't and can't explicitly specify the UserId. Instead, you make use of a identity-aware session while calling the chat-sync API. The identity of the user is implicit in the session.

To obtain the identity-aware session:

  1. You would need an idToken provided by your SSO Identity Provider (IdP).
  2. Using that token, you exchange for an identity-aware token from IAM Identity Center (IdC) whom you need to configure to treat your IdP as a trusted token issuer (TTI).
  3. And using this IdC token, you assume an IAM role, hence obtaining temporary identity-aware session credentials.
  4. Finally, with these temporary credentials, you call the chat-sync API (without specifying UserId because it is implicit in the session credentials).

It's a longwinded answer to the question why it works this way now, but hopefully you recognise this new method, albeit not a straightforward one compared to the old, is ultimately a much better and secured solution.

AWS
answered a month ago
  • Thank you, this was the explanation and confirmation I was after. I understand and appreicate why you have had to change it to work this way. It would be great for the AWS docs to all be updated to reflect this - it took a lot of second guessing and wasted time before debadm pointed everyone to the answer (hidden away in a GitHub repo)

0

I am running into the same problem, with the same setup (Ec2, role, etc). I strongly suspect this is a bug on AWS's end.

Kamil
answered 2 months ago
0

I am experiencing the same problem. I created a lambda which has all AmazonQ business permissions then I ran chat-sync against a datasource free Confluence instance setting the userId as the account Confluence ID or the Confluence email. Also, I set the confluence email visible for anyone as the doc says. I checked the indexing process of the docs was executed sucessfully too. Also, I tested it with my user AWS account ID ,who is admin, without any success.

Could you shed any light here? Thank you ;)

answered 2 months ago
0

Same issue,

"An error occurred (AccessDeniedException) when calling the ChatSync operation: User is not authorized for this service call."

Tried with the user name, the email, the ID, everything.

QUser
answered a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions