I have been working on https://github.com/versent/saml2aws for a couple of years, this tool enables developers to use SSO from the command line to get short lived credentials from AWS. As most SSO services don't have an API for authentication, this is done using screen scraping. This has resulted in:
- A brittle solution which requires reverse engineering and lots of patience seeing what you can get away with.
- This is now how SSO is suppose to work, it is designed for browsers only.
- Runs into tons of problems if you have multiple layers of SSO, as services send users off to social or third party authentication of users.
So we need a better way to integrate CLI tools with SSO to enable these tools to acquire and use short term credentials.
So using AWS as example, I could just create an IAM user and store that on my local machine, but this has some issues:
- When you off-board staff, or use contract staff how do you clean these up?
- How often do these end up in source control or published internally in wiki or documented as a part of procedures
- These are a user name and password that never expires..
So given that GitHub personal access tokens, and a range of other developer focused API tokens have the same issues something needs to be done about it.
So I really want to enable developers to have a relatively easy process to use and refresh tokens without afflicting companies with the nightmare of managing long term secrets. This would:
- Enable companies to off board staff without worrying about API keys laying around for internal admin services / accounts.
- Make it easy for developers to get access and keep access things without manual rotation policies.
- If a developers phone / laptop is stolen or lost these credentials can be revoked, and any refresh tokens will be rejected.
So in summary I need a way to enable CLI tools to trigger an SSO login in a browser, wait for a user to go through this multi layered redirect filled experience and return to the IdP and have the CLI tool get notified of authentication completion and receive some credentials which it can write locally. These credentials could come with a refresh token, or not, but should enable to CLI tool to operate for a work day just like most other services they use.
Luckily there is an OAuth 2.0 flow for this.
The OAuth 2.0 “Device Flow” extension enables OAuth on devices that have an Internet connection but don’t have a browser or an easy way to enter text.
And AWS is currently using this with their SSO service https://aws.amazon.com/blogs/developer/aws-cli-v2-now-supports-aws-single-sign-on/ but not everyone uses this service.
$ aws2 sso login --profile my-sso-profile
Attempting to automatically open the SSO authorization page in your default
browser. If the browser does not open or you wish to use a different device to
authorize this request, open the following URL:
https://device.sso.us-west-2.amazonaws.com/
Then enter the code:
ABCD-EFGH
Successully logged into Start URL: https://d-1234567890.awsapps.com/start
My experience with integration between services such as AWS, and the vast array of identity services out there is that at some point the standards break down and someone needs to add some code which is used to fudge/transform the data. This typically happens in plugins/adapters inside these services.
- I don't need users as such, just the ability to mint tokens with some scopes.
- Additional meta data is provided to the client via an API once they logged in.
- I need to look like an IdP so AWS can validate the tokens using the JKS / discovery endpoints.
- There will be some custom integration where required to support running on private subnets or behind security devices.
- Really just a couple of flows with lots of auditing / tracing.
I am planning to build a client/server using dexidp/dex with golang.org/x/oauth2 and coreos/go-oidc along with a dive into the world of SAML, as most of the services I work with use this.
Given I work on AWS, and would be mainly using this in that environment I would be using services like DynamoDB for persistence and lambda with api gateway to host it and provide some basic rate limiting / WAF.
Note I am not planning on turning dex into 100 lambda functions, just use awslabs/aws-lambda-go-api-proxy to host a normal web service in lambda and proxy all events to it. This will enable me to also deploy in a container with a load balancer out front if needed.
If your planning to provide some of the parts of dex it would be great if the following was considered.
- Keep the simple storage abstraction in Dex as this is pretty easy to use with a key value store like DynamoDB.
- Integrated device flow so that CLI applications can use SSO!
- Keep the core libraries simple so I can just use the core to build my service.
- Provide implementations of all the hard security stuff like CSRF ect.
Note that I am happy to implement, support and contribute to efforts around these libraries as I use these in my day to day work.
Given that a saml2aws like service will need lots of work integrating with an array of different services it will need to be flexible, hence me looking at dex and being interested in work on a some assembly required idp with good core ideas.