SAML-based authentication using AssumeRoleWithSAML

[johnkeates]

Would it be a complex task to add support for authenticating against a SAML IdP to get tokens from STS?

I imagine it would be something like calling the IdP page to get the nonce/csrf token, and then posting the creds to the IdP, redirecting to AWS, which then hands out the tokens, which probably need to be refreshed periodically to stay active.

[errygg]

+1

[lox]

I suspect it might end up being pretty complicated. Segment ended up creating a fork of aws-vault specifically for this + Okta which might be worth checking out:

https://segment.com/blog/secure-access-to-100-aws-accounts/

[rverma-nikiai]

+1 for this. There is a project https://github.com/cevoaustralia/aws-google-auth which is quiet relevant. Although it would be great if these capabilities are also part of vault since vault doesn't support reading from existing credential file.
A more relevant which can be merged in vault with ease is https://github.com/aidan-/aws-cli-federator

[cullenmcdermott]

Would it be possible to utilize parts of saml2aws to accomplish this?

[lox]

Thoughts @wolfeidau? The other route would be to integrate 99designs/keyring as a common backend for the two tools.

[wolfeidau]

I would LOVE to use 99designs/keyring for https://github.com/Versent/saml2aws, I am using some pretty messy stuff now via CGO and it is a nightmare.

Will take a look at a bit of a refactor of this, thanks for the note @lox

[wolfeidau]

Turns out 99designs/keyring currently doesn't support the type of keychain items I use in saml2aws which is a bit of a bummer.

Looking at enhancing the upstream library to support user / pass / server as per the current api.

The github.com/keybase/go-keychain uses kSecClassGenericPassword where as I currently use kSecClassInternetPassword which includes a server name and is designed to store credentials for remote access accounts.

It seems this is going to quickly evolve into a yack shaving excursion. ✂️ 🔥

[majormoses]

We are looking at switching over our aws auth to using okta as a provider and are gonna be looking at the segment project as well as this one: https://github.com/oktadeveloper/okta-aws-cli-assume-role

[brendanheywood]

+1

[Vad1mo]

Why don't we add a Go Plugin System over RPC to AWS-VAULT and then in the second step one could add different SAML Provider such https://github.com/Versent/saml2aws to AWS-VAULT.

No forking of AWS-VAULT needed and the codebase would still be lean.

[hydrajump]

Is support for SAML via ADFS authentication something that the aws-vault maintainers are open to or is it best to fork aws-vault and maybe do what aws-okta has done?

[mtibben]

Hey folks, SSO support has just been merged in #549. Try out the pre-release at https://github.com/99designs/aws-vault/releases/tag/v5.5.0-alpha3 and let us know how it goes

[hlascelles]

I have been using it just fine for a couple of weeks (built from this branch) and it has been working great!

However today, it suddenly stopped working, with, as far as I can tell, no changes by me. I tried the alpha official build and it gave the same error:

❯ aws-vault-linux-amd64 exec sso-login --debug -- aws sts get-caller-identity
2020/04/21 18:31:32 aws-vault v5.5.0-alpha3
2020/04/21 18:31:32 [keyring] Considering backends: [secret-service kwallet pass file]
2020/04/21 18:31:32 Loading config file /home/myuser/.aws/config
2020/04/21 18:31:32 Parsing config file /home/myuser/.aws/config
2020/04/21 18:31:32 Looking for sessions for sso-login
2020/04/21 18:31:32 Looking up all keys in keyring
aws-vault: error: Failed to get credentials for sso-login : Session token not found or invalid
	status code: 401, request id: 

I've tried clearing all sessions in aws-vault, and no dice.

I've export'ed the ENV from the AWS console, and they work fine. I've been reading that aws cli caches details in ~/.aws/cli/cache but I don't have that.

Nothing apt updated at the time... I am at a loss. What should I try next?

[hlascelles]

Hmm! It just "started working again", also with no changes by me, really.

It all started breaking about 9 hours after I first executed an aws-vault command today, then started working another hour after that. Does that help narrow down the problem?

[mtibben]

However today, it suddenly stopped working, with, as far as I can tell, no changes by me.

Maybe @itsdalmo has some thoughts on how to debug this?

[hydrajump]

Hey folks, SSO support has just been merged in #549. Try out the pre-release at https://github.com/99designs/aws-vault/releases/tag/v5.5.0-alpha3 and let us know how it goes

This is a silly question but since the above comment was posted in this issue I have to ask. Does this mean that aws-vault supports other SAML providers than AWS SSO, e.g. ADFS?

[FernandoMiguel]

I would love to see Azure AD support

[johnkeates]

I would love to see Azure AD support

If Azure AD can do normal SAML it should be easy enough to add that. If Azure AD's SAML is like AD Federation (classical) then it might be problematic depending on how you assign your roles to from the IdP to the AWS User.

[statik]

I believe there is a useful path here by configuring AWS-SSO to connect with Azure AD, and then aws-vault could authenticate against AWS-SSO (which would have Azure AD as the identity source). Some descriptions of the integration here: https://aws.amazon.com/blogs/aws/the-next-evolution-in-aws-single-sign-on/

[hlascelles]

So that error has again happened today:

ws-vault: error: exec: Failed to get credentials for sso-network-services-administrator: : Session token not found or invalid
	status code: 401, request id: 

It's around the same time of day too (ie, probably around the same length of time since I did the browser sign in. I think 6 hours?). I will take exact timings next time.

[mtibben]

Perhaps a bug in the cached credentials?

[mtibben]

@hlascelles I believe this issue is fixed in v6.0.0-beta3. If it's not, can you please create a new issue?

[mtibben]

Closing this, as it's now possible to use SAML via AWS SSO in #549. There are probably better ways to utilize AssumeRoleWithSAML however, so if anyone needs that support, please open a new issue or PR

[brendanheywood]

Am I missing something? AWS SSO !== a generic saml solution. From the looks of the other issue and the docs only AWS is supported. If so I think this issue should be reopened

https://github.com/99designs/aws-vault#aws-sso-integration

[mtibben]

Hey @brendanheywood AWS SSO supports 3rd party IdP.

This issue was a very general "Support SAML-based authentication" which aws-vault can now do via AWS SSO. If you have a more specific implementation in mind, lets create a a new issue to track that

[mtibben]

Meh, I guess we can leave this issue open as the sts.AssumeRoleWithSAML case

[mtibben]

Anyone up for having a stab at the implementation?

It should be significantly easier than it has been in the past as the code for config, caching and credential providers are all orthogonal

[brendanheywood]

I've know saml pretty well, but not go at all. There should hopefully be some saml libs that do all the heavy lifting and this look promising:

https://github.com/crewjam/saml

[greyfairer]

My ex-colleague has implemented this in Go for SAML authentication with OneLogin: https://github.com/glnds/masl. He did a blog post on it last week: https://medium.com/@engineering/masl-managing-multiple-aws-accounts-using-the-cli-687bfefef5a1.
I'm not sure if it would work with e.g. Google Apps too?

[dantrauner]

+1 for this – I love aws-vault for non-SAML and came from using the now unmaintained aws-okta for SAML, but it turns out you cannot use the AWS SSO service if your AWS account(s) are tied to a reseller. This is a known issue for the way AWS resellers are set up :(

[mtibben]

After a little more research, I'm not convinced adding direct SAML support to aws-vault is desirable given the considerable complexity involved in an implementation and that tools like https://github.com/Versent/saml2aws already exist

Seems like adding support for AssumeRoleWithSAML would only re-create what saml2aws does.

Maybe there's something that I'm missing. To those who have voted on this issue, what can't be accomplished with saml2aws that you're hoping aws-vault would be able to accomplish?

[dantrauner]

@mtibben I think saml2aws might not actually support encrypted backends for caching credentials, so you end up with plaintext secrets on disk. I haven't tried it in a while though, so maybe that's supported now? I know aws-vault has always done this.

[baztian]

@dantrauner is right. Saml2aws stores the access credentials on plain text. Personally I'm using aws accounts tied to saml idps and some not being tied to saml. Therefore it would be nice to have just one tool for the job. But honestly saml2aws is OK.

[johnkeates]

While I'd still like to have it all in aws-vault (some setups use SAML, some OID, some AWS SSO, some plain credentials), I do see the point of not making it extra complicated...

If it really is unreasonably hard to get this integrated I should probably see if the reverse can be done -- hooking a frontend up to a SAML client as well as having aws-vault as a client. It would still give the best of both worlds (somewhat).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[olfway]

It's not stale, still valid

[hannahkamundson]

+1

[Freyert]

Putting this here so I remember next time I see it.

It's pretty evident how impossible this feature is, how outside of aws-vault's scope it is, and how better alternatives exist.

It's impossible:

1. Everyone does SAML differently
2. Most examples I've seen is that the SAML document is presented to you as a hidden field in an HTML form.
3. There's no requirement on how the document is presented and only general guidelines of what exists in the document.
4. I'm guessing some systems might return the SAML document via an API? I'm no SAML expert.

Outside of scope:
aws-vault is mostly to keep credentials in your system's keychain instead of clear text on disk. Since there are no credentials to store it doesn't fit too well into the system.

Better Alternatives
Since everyone's SAML is different you're better off writing an executable to execute the flow for you and using credential_process to execute the SAML authentication for you when using the CLI.

Here's a "general" walkthrough from AWS for working with SAML via the CLI: https://aws.amazon.com/premiumsupport/knowledge-center/aws-cli-call-store-saml-credentials/

Notice: you have to search around the logs for the SAML document. It is not presented directly.

---

Maintaining the aws exec $PROFILE -- terraform plan workflow might be important. I suppose if AWS_PROFILE is set it should honor the config and use the credential_process.

---

From what I can tell saml2aws implements different procedures for each saml provider.

[johnkeates]

I suppose in a way using aws with credential_process can be used to front both aws-vault and SAML. The thing is that not everyone has uniform accounts, and some people work with different organisations so you end up with multiple different authentication requirements. Some SAML, some OIDC some plain AWS; if you have to run 4 different CLI tools to get auth going that's a bit of a PITA, and the aws-vault experience is better than aws (the CLI). From that perspective it makes it desirable to have that same positive interaction but for 'every' account and authentication combination (we also have accounts that have three types of auth at the same time due to different parties having different requirements... it gets messy sometimes but the real world tends to do that).

Perhaps aws-vault isn't the best place, on the other hand, if other CLI tools can do it you'd think that therefore it must be technically possible to do the same here. On the other other hand, it might not be feasible for the aws-vault maintainers since that could end up being a huge time sink.

If we just consider the interaction with this issue over time, it does seem to be an issue people keep coming back to. If that means that just some documentation stating it's infeasibility for this project is the end-result that would be a closing option as well 🙂

[Freyert]

@johnkeates you're right, that single CLI experience is so key. aws-vault makes auth so much more transportable across tools.

I'm looking at credential_process in more depth. Would aws-vault function correctly with that?

I think most of the SAML work is fine if individuals can learn how to build it themselves (if saml2aws does not support) which saml2aws provides a lot of good examples.

If aws-vault can use the response from the credential_process, manage it better than the CLI manages (caching, system keychain, etc), and keep a consistent aws-vault experience I think that provides a much better framework for working with SAML than what I have currently.

The AWS CLI does not cache external process credentials the way it does assume-role credentials. If caching is required, you must implement it in the external process. (Source)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.