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 Risposte
1
Risposta accettata
debadm
con risposta un mese fa
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
ESPERTO
Matt-B
con risposta un mese fa
profile picture
ESPERTO
A_J
verificato un mese fa
  • 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
con risposta 11 giorni fa
  • 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
con risposta un mese fa
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 ;)

con risposta un mese fa
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
con risposta 14 giorni fa

Accesso non effettuato. Accedi per postare una risposta.

Una buona risposta soddisfa chiaramente la domanda, fornisce un feedback costruttivo e incoraggia la crescita professionale del richiedente.

Linee guida per rispondere alle domande