awslabs/ssosync

The security token included in the request is expired

ahmetozergetir opened this issue · 5 comments

I have followed the documentation to create a configuration for ssosync. When I execute the ssosync on local, I get the below error.

At Google Workspace, it works to sync the users with SCIM to AWS but on my local, it has an expired token error. Even though I have created a new token, still I have a similar issue.

Tested on 3da5c146fa736f7943ab3e31c772bded25f58d1a commit

INFO[0000] Syncing AWS users and groups from Google Workspace SAML Application
WARN[0000] Problem performing test query against Identity Store  error="ExpiredTokenException: The security token included in the request is expired\n\tstatus code: 400, request id: xxx-xxx-xxx"
FATA[0000] ExpiredTokenException: The security token included in the request is expired

To Reproduce

Steps to reproduce the behavior:

  1. go build
  2. Defining the below environmental variables
    1. SSOSYNC_SCIM_ACCESS_TOKEN=${SECRET got from AWS IAM IDC}
    2. SSOSYNC_SCIM_ENDPOINT=https://scim.eu-west-1.amazonaws.com/${path}/scim/v2/
    3. AWS_REGION=eu-west-1
  3. Google Workspace service account JSON is renamed and moved to the application build folder
  4. The application started with the following arguments ./ssosync --debug -i d-XXXXX -r eu-west-1

Expected behavior
The system will sync the Google groups to AWS IAM IDC

Hello 👋
Thank you for your fast response.
I have not deployed it as lambda yet but if AWS access is required besides of SCIM token, I can be create a user too fill AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY information and continue test at local.

What kind of IAM policies are required with least privilege? It is not documented at readme.md and repository.

You'll find an IAM Role in template,yaml there is a least privilege policy however, I would recommend deploying from the AWS Serverless Application Repository (currently v2.2.1).

Ok, I found the reason, because I am also testing the AWS SSO for AWS CLI, it does not take a look at environment variables, so when deleting the files under ~/.aws/sso/* and ~/.aws/credentials helps to overcome this issue.