List AWS Account in IdP menu

[monde]

Currently the Choose an IdP only list AWS Fed App name and AWS ARN. Is it possible to also list the AWS Account name?

Currently:

? Choose an IdP:  [Use arrows to move, type to filter]
> App A (arn:aws:iam::123:saml-provider/A)
  App B  (arn:aws:iam::123:saml-provider/B)
  App C (arn:aws:iam::123:saml-provider/B)

Proposed something like so with the given AWS Account number 123-123-123 and user foo/my-name

? Choose an IdP:  [Use arrows to move, type to filter]
> 123-123-123 foo/my-name / App A (arn:aws:iam::123:saml-provider/A)
  123-123-123 foo/my-name / App B  (arn:aws:iam::123:saml-provider/B)
  123-123-123 foo/my-name / App C (arn:aws:iam::123:saml-provider/B)

[monde]

cc: @jefftaylor-okta

[palotasb-booking]

+1

At my company it looks like this, hard to know which account you want to log into by only looking at the AWS account ID.

System web browser will open the following URL to begin Okta device authorization for the AWS CLI

https://okta.example.com/activate?user_code=EXAMPLE

? Choose an IdP:  [Use arrows to move, type to filter]
> arn:aws:iam::123456789012:saml-provider/company-okta-idp
  arn:aws:iam::012345678901:saml-provider/company-okta-idp
  arn:aws:iam::901234567890:saml-provider/company-okta-idp
  arn:aws:iam::890123456789:saml-provider/company-okta-idp
  arn:aws:iam::789012345678:saml-provider/company-okta-idp

[monde]

Okta internal reference https://oktainc.atlassian.net/browse/OKTA-573099

[stmyers]

In saml2aws, the account alias is displayed when presented with account/role to assume...for me it's less about the foo/my-name and more about the friendly name of the account. It's not clear if that's what your targeting with App A, App B, App C so I figured I'd call that out as well.

This alias is also displayed when logging into AWS web console from Okta IdP initiated auth, when given a choice of what roles to assume.

? Please choose the role  [Use arrows to move, type to filter]
> Account: app1-dev (123456789012) / role1
  Account: app1-test (012345678901) / role1
  Account: app1-prod (901234567890) / role1
  Account: user-sandbox (890123456789) / OrgAdministrator

[monde]

Just following up we'd like to get this into the next release which will be a v1.0.0 release

[monde]

@palotasb-booking @stmyers ok, looking for some more feedback from the community. I need to explain what is taking place to illustrate there won't necessarily be equivalent behavior to other tools.

cc/ @jefftaylor-okta

Background

I'm speaking here in terms of the multiple fed apps feature where there are multiple Okta OIN AWS Fed apps being utilized. Realize there are two steps that take place. One to render the drop down of IdPs (effectively the OIN AWS Fed apps). Two, the roles available when the Assume Role SAML assertion has been presented by Okta based on the Fed App selected.

One Okta OIN AWS Fed Apps "IdP selection"

In the first step you see a drop down of Okta OIN AWS Fed App Name then "Identity Provider ARN" as (arn:aws:iam::[NNN]:saml-provider/[Role Name]). So line two of the drop down below is app "AWS Account Federation (EC2)" and IAM IdP ARN "arn:aws:iam::294719231913:saml-provider/MMondragon_Okta_AWS_CLI_ec2".

? Choose an IdP:  [Use arrows to move, type to filter]
> AWS Account Federation (arn:aws:iam::913:saml-provider/Mondragon_AWS_CLI)
  AWS Account Federation (EC2) (arn:aws:iam::913:saml-provider/MMondragon_Okta_AWS_CLI_ec2)
  AWS Account Federation (eks) (arn:aws:iam::913:saml-provider/MMondragon_Okta_AWS_CLI_eks)
  AWS Account Federation (cloudfront) (arn:aws:iam::913:saml-provider/Mondragon_cloudfront)

You can see where this values live in the Admin UI. First the list of my OIN AWS Fed Apps in my demo org.

Then for my "AWS Account Federation (eks)" Sign On tab the ARN is in the "Identity Provider ARN (Required only for SAML SSO)" value

Suggestions?

Looking for suggestion on the format of the IdP drop down lines. Perhaps showing the real ARN value in the second half of each line is too noisy?

Two "Role Selection"

Once the AWS Fed App has been selected, we've effectively selected the IAM IdP and now we just need to select an IAM role from this IAM IdP. At this point the Okta monolith has done the dance with AWS for assume roll with SAML to generate a SAML assertion. Packed in that assertion is information about Roles on that IdP.

I have these values available as saml2:AttributeStatement in the SAML document:

saml2:Attribute - Role
  arn:aws:iam::913:saml-provider/Mondragon_AWS_CLI,arn:aws:iam::913:role/MMondragon_S3_Read
  arn:aws:iam::913:saml-provider/Mondragon_AWS_CLI,arn:aws:iam::913:role/Mondragon_S3_AWS_CLI
  arn:aws:iam::913:saml-provider/Mondragon_AWS_CLI,arn:aws:iam::913:role/NotAdmin

saml2:Attribute - RoleSessionName
  me@okta.com

saml2:Attribute - SessionDuration
  3600

At this point the Role drop down is rendered as:

? Choose a Role:  [Use arrows to move, type to filter]
> arn:aws:iam::913:role/MMondragon_S3_Read
  arn:aws:iam::913:role/Mondragon_S3_AWS_CLI
  arn:aws:iam::913:role/NotAdmin

Suggestions?

Perhaps include the "saml2:Attribute - RoleSessionName" value from the SAML document?

? Choose a Role:  [Use arrows to move, type to filter]
> me@okta.com arn:aws:iam::913:role/MMondragon_S3_Read
  me@okta.com arn:aws:iam::913:role/Mondragon_S3_AWS_CLI
  me@okta.com arn:aws:iam::913:role/NotAdmin

Conclusion

Thanks in advance for everyone's suggestions.

[palotasb-booking]

Hi @monde!

In our use case we have a bunch of SAML Providers which are all the same but they reside in different AWS accounts.

? Choose an IdP:  [Use arrows to move, type to filter]
> arn:aws:iam::123456789012:saml-provider/company-okta-idp
  arn:aws:iam::012345678901:saml-provider/company-okta-idp
  arn:aws:iam::901234567890:saml-provider/company-okta-idp
  arn:aws:iam::890123456789:saml-provider/company-okta-idp
  arn:aws:iam::789012345678:saml-provider/company-okta-idp

For us the only variable parts are the highlighted AWS account IDs. So it's different than the example you mention where a single AWS account (913 in your example) has different OIN AWS Fed Apps. The last part of the ARN is always literally :saml-provider/company-okta-idp.

For IdP selection, the AWS sign-in page (https://signin.aws.amazon.com/saml after you sign in with Okta) disambiguates the AWS account IDs based on the AWS account alias. The AWS account alias in our case is always a human-readable recognizable string, usually in the form of company-<project>-<component>.

So for the IdP selection phase we'd really appreciate an API call to iam:ListAccountAliases and the IdP selection options to include the AWS account alias of the account where each presented Fed App lives. Example:

? Choose an IdP:  [Use arrows to move, type to filter]
> corp-finance-prod            arn:aws:iam::123456789012:saml-provider/company-okta-idp
  corp-finance-dev             arn:aws:iam::012345678901:saml-provider/company-okta-idp
  corp-datascience-team-alpha  arn:aws:iam::901234567890:saml-provider/company-okta-idp
  corp-datascience-team-beta   arn:aws:iam::890123456789:saml-provider/company-okta-idp
  corp-sandbox-palotasb        arn:aws:iam::789012345678:saml-provider/company-okta-idp

For the role selection part, the variable part is always the IAM role name. (The role session name is always the email address of the person signing in, the role session duration is constant too.) So again I would highlight the role ARN or the role name or list that part first in the role selection phase.

[palotasb-booking]

Another way to say this more succinctly: In our setup, the IdP selection phase is really an AWS account selection phase.

[stmyers]

If a user is only assigned to a single AWS Okta app, can you IdP selection phase be skipped (ie. automatically selected)?

For our case, some users may have 2-3 IdPs, but most will just have 1 IdP (used for multiple accounts)

[JRman]

? Choose an IdP: [Use arrows to move, type to filter]

corp-finance-prod arn:aws:iam::123456789012:saml-provider/company-okta-idp
corp-finance-dev arn:aws:iam::012345678901:saml-provider/company-okta-idp
corp-datascience-team-alpha arn:aws:iam::901234567890:saml-provider/company-okta-idp
corp-datascience-team-beta arn:aws:iam::890123456789:saml-provider/company-okta-idp
corp-sandbox-palotasb arn:aws:iam::789012345678:saml-provider/company-okta-idp
For the role selection part, the variable part is always the IAM role name. (The role session name is always the email address of the person signing in, the role session duration is constant too.) So again I would highlight the role ARN or the role name or list that part first in the role selection phase.

This is EXACTLY our use case as well... Really need the AWS account alias to help decipher the account id.

[perj]

I guess this is the same as what @palotasb-booking is saying, but I wanted to clarify that the Okta App name would not be useful to us. We only have a single Okta AWS Federation app that connects to multiple IdPs.

A list of account names would be the best, we've been trying hard to not require our developers to remember the numeric account ids so far.

[monde]

Just keeping a heart beat on this, our PM and I are actively seeking how to address and solve this issue.

[monde]

Note to self: https://aws.amazon.com/blogs/security/easier-role-selection-for-saml-based-single-sign-on/
"Easier Role Selection for SAML-Based Single Sign-On"
Appears list of accounts / roles on AWS SSO /saml is comprised of
https://docs.aws.amazon.com/singlesignon/latest/PortalAPIReference/API_ListAccounts.html
https://docs.aws.amazon.com/singlesignon/latest/PortalAPIReference/API_ListAccountRoles.html

[daniel-sampliner]

FYI #94 kinda addresses this. The purpose of that PR is to address #36, however as a side-effect it also grabs the account aliases to use as the profile names. You can see how it's using the the ListAccountAliases to fetch the human-friendly alias.

However, I found that I wasn't able to make that call until after I had already retrieved the STS credentials, so it couldn't be done before the user had to choose a cryptic account/role to use. Perhaps someone more familiar with okta or AWS APIs can figure out how to get the aliases at an earlier point.