how to use credentials generated by logging via saml2aws in amazon kendra?

Question

I am trying to test my search application with amazon kendra. I utilized the code provided with the documentation -> https://docs.aws.amazon.com/kendra/latest/dg/deploying.html. I am using saml2aws to login from my machine to aws, which generates following keys

aws_access_key_id = ***
aws_secret_access_key = ****
aws_session_token = ***
aws_security_token= ***
x_principal_arn=**
x_security_token_expires= **
region= ***

where as in the search application code provided by aws , it uses aws-sdk and for authentication uses following code, which uses only three values. when i plug the values in generated from the saml2aws in the config file, it complains "the security token included in the request is invalid". when i try to add the session token generated , above, it doesn't work either.how to pass the credentials generated via saml2aws login in such condition.

export const Kendra = !hasErrors
? new Kendra({
   accessKeyId: config.accessKeyId, 
   secretAccessKey : ...
   region : ..
})
: undefined

Answer 1

Please include session token while initializing Kendra client as well. Code sample you are referring to demonstrates only one of different ways to initialize Kendra client. AWS JS SDK allows you to pass many more parameters (read this) as options (sessionToken being one of them) while initializing the Kendra client. If your credentials are not working even after passing sessionToken then in most likelihood you are hitting the case where you are using an expired session token (session tokens are valid for a max time of 12 hours). I can recommend three potential ways to solve this problem:

1. Use long lived credential to initialize Kendra client
2. You put your own web server between UX and Kendra. This web server in the backend can use long lived credentials to call Kendra API. This will allow you to not leak your credentials in UX code.
3. Use Cognito to make calls to Kendra service. Please refer on how Amplify can help you on that

All three above mentioned options should be able to get rid of sessionToken expiration limitations.