[Q] .saml2aws & .aws/config relationship | general usage

[charger89]

Hia, I'm one of the aws-okta refugees and need a little hand-holding with onboarding to saml2aws; main problem is understanding how saml2as config (~/.saml2aws) relates/refers to aws-cli config (~/.aws/config). aws-okta setup was simple enough - we could add different account/role profile definitions in aws cli configuration and refer to them by aws-okta argument, eg aws-okta exec <profile> <command>

Eg our ~/.aws/config could look something like

[default]
region = eu-west-1
cli_follow_urlparam = false

[okta]
aws_saml_url = home/amazon_aws/0obcg34stZzRtVx5F753/281

[ profile dev ]
role_arn = arn:aws:iam::672333961278:role/role-delegated-write
[ profile nonprod ]
role_arn = arn:aws:iam::722242912841:role/role-delegated-write
[ profile prod ]
role_arn = arn:aws:iam::515183197132:role/role-delegated-read

and aws-okta's own setup would be via aws-okta add where it asks for authentication info.

2FA would be prompted once, and aws-okta would store the credentials under ~/.aws-okta/

Now, saml2aws config looks different:

[default]
app_id               =
url                  = https://yourcompany.okta.com/home/amazon_aws/0obcg34stZzRtVx5F753/281
username             = user@domain
provider             = Okta
mfa                  = Auto
skip_verify          = false
timeout              = 0
aws_urn              = urn:amazon:webservices
aws_session_duration = 3600
aws_profile          = default
resource_id          =
subdomain            =
role_arn             =
region               =
http_attempts_count  =
http_retry_delay     =

[dev]
app_id               =
url  = <same as above>
<most values same as above>
...
role_arn = arn:aws:iam::672333961278:role/role-delegated-write

[nonprod]
<again, most values same as above>
...
role_arn = arn:aws:iam::722242912841:role/role-delegated-write

Then we'd have to log in into each profile via 2FA:

saml2aws login --profile dev|nonprod|prod

which then gives us authentication for whatever the command we need:

saml2aws exec --profile dev|nonprod|prod -- <command>

This all leaves me a bit puzzled: 1) why do we need to go through 2FA for each profile login if we have the one "master" user we authenticate over say OKTA with? (possibly related: https://github.com/Versent/saml2aws/issues/438 & https://github.com/Versent/saml2aws/issues/492) 2) it appears as if ~/.aws/config is not referred to at all - note we have to duplicate the role_arn definitions in ~/.saml2aws; is this assumption correct? Feel like it can't be correct, as readme refers to aws cli config, but can't exactly see how it's used. 3) could someone further explain what --exec-profile does? --profile selects our profile definition from .saml2aws (and not from ~/.aws/config!), but exec-profile escapes me a bit. 4) when we get error aws credentials have expired error, is it possible to automatically re-initiate login to renew credentials? 5) when we have role_arn defined in config as above, then how come saml2aws login still prompts for role selection: Please choose the role:? Seems redundant, and it'd fail if we choose any other role than the one that's configured.

Thanks!

[indrekj]

I pretty much have exactly the same questions. Have you figured any of these out?

[charger89]

Nope, no progress whatsoever. Been continuing with aws-okta so far.

[wolfeidau]

There is a lot to unpack here.

1. saml2aws doesn't persist cookies or tokens related to authentication, this is partially because each identity provider implements different systems for retaining sessions.

2. saml2aws interacts primarily with the aws credentials file, this is based on my original goal of keeping things very simple, in hindsight this probably wasn't the best long term plan.

Summary of how these files work is here.

https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html

3. saml2aws primarily uses alias to manage configuration for each identity provider, some users like to override the profile configured for each identity provider "alias" at runtime. The --exec-profile is used for more advanced role assumption, most poeple just use the default profile or override it with --profile.

I think there is a key difference between saml2aws and some of the tools which use keychain to store credentials is it is designed to just get the creds most of the time, once on disk in plain text existing tools can just use them as required.

Is this perfect, probably not, but alas it does make things simple for myriad of tools out there.

4. saml2aws supports a raft of different identity providers, not all of them have an authentication API like okta so re-authentication may not be trivial, or reliable sadly. I have tended towards keeping things consistent over trying to specialise in one identity provider.

5. saml2aws uses the role in it's configuration file to feed the default behavior of the command, this can be overridden via flags when authenticating. The role in the aws configuration file is a record of which role was used to retrieve the credentials stored in the same file, it acts as a simple record and can be used for automation in scripts on top of saml2aws.

Given you have come from aws-okta some of this may seem a little simplistic, but overall I am optimizing for broad integration and community contributions.

I am always open to contributions, I do my very best to keep on top of PRs :pray:.

[lamp0chka]

I've been in same boat until recent release of saml2aws. Now profiles work like magic. Here is what I did:

[profile <dev_account>]
credential_process = saml2aws login --skip-prompt --quiet --credential-process --role arn:aws:iam::<dev_account>:role/<dev_role> --profile <dev_account>

[profile <stage_account>]
credential_process = saml2aws login --skip-prompt --quiet --credential-process --role arn:aws:iam::<stage_account>:role/<stage_role> --profile <stage_account>

Test it:

aws s3 ls --profile <dev_account>
dev account data, works

aws s3 ls --profile <stage_account>
stage account data, works

Key thing here is usage of --profile flag in saml2aws, this will create associated profile in ~/.aws/credentials.

If that key is missing, then [saml] profile will be used, this no-go as login data is cached. Example:

aws s3 ls --profile <dev_account>
dev account data, works

aws s3 ls --profile <stage_account>
dev account data, broken

Edit: Ok, I've got happy too early. If the credentials expire, aws cli continues to use them and is not trying to run saml2aws credential_process again. Deleting ~/.aws/credentials helps, but would be nice to automate this somehow.

[Jomik]

I would like to add to this. It seems like an oversight that we are still writing to the credentials file, if the credentials-process flag is parsed. It should not be necessary, or at least the credentials should be cached elsewhere. Wondering if it works just fine with --profile dummy, because then aws wont see credentials for the profile, and then proceed to ask the process, which can read from the dummy, if they are not expired. But you do need a dummy for each profile.. Silly workaround 😄

[sledigabel]

This is an excellent point regarding the file name @Jomik.