Giters

awslabs / ssosync

Populate AWS SSO directly with your G Suite users and groups using either a CLI or AWS Lambda

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

SAM CLI validation is incorrect

behobu opened this issue · comments

commented

Describe the bug
When attempting to use the SAM CLI to upload a locally-modified copy of SSOSync (no changes were made to the CloudFormation configuration files), it fails to accept both the GoogleCredentials and the SCIMAccessToken strings because of invalid validation regexes. This led to me having to use { "foo":"bar" } and "a"*500, respectively, to get the process to complete. After it completed, I was able to go into AWS Secrets Manager and manually edit those two secrets to have the correct values. They were simple copy-past from the text file I had with those values in them, and the credentials.json had no carriage returns in it to mess up any whitespace parsing or command-line issues.

To Reproduce
Steps to reproduce the behavior:

  1. Follow all the instructions in the SAM section of the README (at the bottom)
  2. During the "sam deploy --guided" step, copy-paste the values for GoogleCredentials from any text editor (as long as CR/LF have been removed) and get a state in the process where the command line just "ticks" (makes a tick noise) at you, and refuses any further input.
  3. Alternately, perform step 2 above but provide your true value for the SCIMAccessToken, and have the terminal do the same thing - tick at you (make a tick noise) due to invalid input.
  4. These values cannot be supplied by the .toml file unfortunately so you either have to type them in (blindly and 100% correctly) or you need to copy-paste from a text editor. Or, you provide a fake value to get through that step and fix it afterward.
  5. Can't show error, since no actual error is displayed. The terminal interface just stops accepting input.

Expected behavior
Ideally, a JSON string that conforms to the JSON standard would be accepted and parsed properly for the GoogleCredentials secret, and a properly-formed SCIM Access Token would be accepted and parsed properly for the SCIMAccessToken secret.

Additional context
This project was cloned to a Macbook with an M1 chip, and the AWS CLI and SAM CLI were both installed from AWS-provided sources. VSCode was used as the text editor that held the secret values before being copy-pasted. JSON validation was performed on the credentials.json object, and a manual examination of SCIM Access Tokens from various IdP sources revealed that my token value was most likely not malformed. This was backed up by the fact that when I copy-pasted into AWS Secrets Manager, the stack worked properly.

commented

I don't use the SAM method for testing or deployment instead using the CICD pipelines but I will take a look the validation of those two strings is only very light at this point but I'll run some manual tests. and look to build a codebuild based test for SAM deployment.

Under cicd/cloudformation/ You'll find two templates secrets.yaml and developer.yaml If you are working on forks of the code base I would use these to build and test the code. Once built you'll have a SAR product you can share with any production accounts you might want to deploy to. If you are looking to use the official release then I would strongly recommend deploying from the official SAR product in the README.md.