Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authentication with Cognito #33

Open
6 of 7 tasks
eschwartz opened this issue Nov 19, 2019 · 2 comments
Open
6 of 7 tasks

Authentication with Cognito #33

eschwartz opened this issue Nov 19, 2019 · 2 comments
Assignees

Comments

@eschwartz
Copy link
Contributor

eschwartz commented Nov 19, 2019

I want to be able to authenticate as a DCE user (not admin), via an external IDP.

User Flow:

  • CLI command initiates auth flow
$ dce auth
> Opening a browser to authenticate....
> Enter Login Code: 
  • CLI grabs location of DCE API from dce.yml
    • This config is either populated on running dce system deploy, or manually configured by end user
  • CLI opens browser window at https://<dce_api_url>/auth
  • /auth uses Cognito JS SDK (client-side) to redirect user to IDP login page*
  • IDP prompts user for username/password
  • IDP redirects back to /auth endpoint, with ?code= query param
  • /auth endpoint converts the ?code= param to a JWT, using Cognito JS SDK**
  • /auth endpoint converts the JWT to an STS token, using the Cognito JS SDK**
  • /auth endpoint encodes the STS token as base64
  • /auth endpoint displays base64 token to user, and copies to clipboard
  • User pastes the token back into their CLI prompt
  • CLI saves the token to dce.yaml for future use

For future CLI commands...

  • CLI decodes STS token, and uses in sigv4 auth to DCE API endpoints
  • API Gateways is able to inspect the STS token and associate it with a Cognito identity. API GW includes cognito metadata in API Gateway Event object passed to lambdas***

Other Considerations

  • If a CLI user is using AWS CLI creds (eg. from ~/.aws/credentials), they shouldn't need to login via Cognito. They should be able to continue using basic IAM Auth, and be treated as an admin user.

* note that /auth endpoint is not yet implemented. Will be completed in main DCE repo
** Alternatively, /auth endpoint could just grab the ?code= param and pass it back to the CLI, and the CLI could do the code->JWT->STS conversion
*** ...or so we think. See /leases/auth code for inspecting cognito data in API GW events


BONUS POINTS: Auto-Auth

CLI should have a pre-command hook, which authenticates users if they aren't already authenticated.

So, I should be able to run dce leases login, go through my IDP login, and get access to my AWS account. (I don't want to run dce auth and then also dce leases login.

Tasks

For github.com/Optum/dce:

  • Add /auth endpoint, with client side Cognito JS SDK code
  • Verify that STS tokens from Cognito get passed through into the API GW event, the way we think they do
  • Test IRL, with a real IDP
    • Identity any areas where additional configuration is necessary
  • Document how to integrate IDP/Cognito with DCE

For github.com/Optum/dce-cli

  • Update dce auth to open /auth endpoint
  • dce auth command prompts for code, and saves to dce.yml
  • Use API code from dce auth for other CLI commands
@eschwartz
Copy link
Contributor Author

@joshmarsh is going to drive the github.com/Optum/dce work
@eschwartz is going to drive the github.com/Optum/dce-cli work

@joshmarsh
Copy link
Contributor

/auth endpoint encodes the STS token as base64
/auth endpoint displays base64 token to user, and copies to clipboard

@eschwartz , here's an example of the sts creds JSON:

{
   "accessKeyId":"xxx",
   "secretAccessKey":"xxx",
   "sessionToken":"xxx",
   "expireTime":"Wed Nov 20 2019 13:30:13 GMT-0600 (Central Standard Time)"
}

eschwartz pushed a commit that referenced this issue Nov 22, 2019
Stuff going on here

- Add `dce auth` command
  - pops you out to a browser at the `/auth` endpoint that @joshmarsh is working on
  - see #33
- Remove dce.yml configs we aren't using
- Configure a AWS creds provider that will load creds from the auth token, but fallback to env vars or the `~/.aws/credentials` file
- Run `dce auth` before any command, if we don't have any valid creds in our chain
- Refactor how to load and save our config YAML, so it's easier to work with from inside multiple commands
- Remove viper dependency (wasn't really being used)
- Some other cleanup/refactor around init logic, to get this all wired up properly
  - I'll try to point these out in the code
- New setup for integration tests
  - These test call our cobra CLI programmatically. For some reasons:
    - Lets us use debugger to run through tests
    - Don't need to rebuild for every test run
    - Can still use mocks at boundaries (eg. mock out web browser call)
  - I'm hoping this new testing pattern makes it easier to write tests for CLI commands going forward.
eschwartz pushed a commit that referenced this issue Nov 22, 2019
Stuff going on here

- Add `dce auth` command
  - pops you out to a browser at the `/auth` endpoint that @joshmarsh is working on
  - see #33
- Remove dce.yml configs we aren't using
- Configure a AWS creds provider that will load creds from the auth token, but fallback to env vars or the `~/.aws/credentials` file
- Run `dce auth` before any command, if we don't have any valid creds in our chain
- Refactor how to load and save our config YAML, so it's easier to work with from inside multiple commands
- Remove viper dependency (wasn't really being used)
- Some other cleanup/refactor around init logic, to get this all wired up properly
  - I'll try to point these out in the code
- New setup for integration tests
  - These test call our cobra CLI programmatically. For some reasons:
    - Lets us use debugger to run through tests
    - Don't need to rebuild for every test run
    - Can still use mocks at boundaries (eg. mock out web browser call)
  - I'm hoping this new testing pattern makes it easier to write tests for CLI commands going forward.
@joshmarsh joshmarsh assigned eschwartz and joshmarsh and unassigned eschwartz and joshmarsh Dec 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants