- Più recenti
- Maggior numero di voti
- Maggior numero di commenti
Here is a solution to this issue : https://github.com/aws-samples/custom-web-experience-with-amazon-q-business
This is also explained here: https://aws.amazon.com/blogs/machine-learning/deploy-a-microsoft-teams-gateway-for-amazon-q-your-business-expert/
Thanks. I've not tried it as the solution is REALLY long and complicated but I'll trust it works. Weird how none of the AWS docs mention any of this and we have to rely on blogs and github samples to have any clue that a special access token is required.
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
I ran
aws sts get-caller-identityto 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-idparameter 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-idparameter and their user setup.
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:
- You would need an idToken provided by your SSO Identity Provider (IdP).
- 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).
- And using this IdC token, you assume an IAM role, hence obtaining temporary identity-aware session credentials.
- 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.
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)
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.
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 ;)
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.
Contenuto pertinente
AWS UFFICIALEAggiornata 2 anni fa- AWS UFFICIALEAggiornata un anno fa
- AWS UFFICIALEAggiornata 2 anni fa
It is possible the window in which you are running the code might not be getting AWS credentials
--debugflag.aws s3 lsI 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
--debugflag 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:
Part 2: