Parsing broken on new AWS SAML login page if resolve_aws_alias true

Nike-Inc / gimme-aws-creds

A CLI that utilizes Okta IdP via SAML to acquire temporary AWS credentials

Apache License 2.0

919 stars 262 forks source link

Parsing broken on new AWS SAML login page if resolve_aws_alias true #425

Closed markjreed closed 1 year ago

markjreed commented 1 year ago

Expected Behavior

gimme-aws-creds should see all of my assigned roles and prompt

Current Behavior

gimme-aws-creds sees only a single role (first one on page)

Possible Solution

Need to adjust parsing of SAML login page HTML

Steps to Reproduce (for bugs)

Get more than one role assigned in AWS via SAML provider
Run gimme-aws-creds without any arguments to select a role

Context

Lots of IaC with hard-coded AWS_PROFILE values that include account aliases, now must be changed to account-id (or workflow changed to specify profile names)

Your Environment

App Version used:
2.7.1
Operating System and version: macOS 13.4.1

SteveyPugs commented 1 year ago

Seeing the same. Now sees it as a single login.

chrissnell-okta commented 1 year ago

It appears that AWS changed the design of the role selection page in the login workflow. Guessing that gimme-aws-creds will have to be updated to scrape the role names from this new design.

jbhasemeier commented 1 year ago

setting resolve_aws_alias = false is working for us as a local authentication workaround, returning the role arn in the console. this wont help if you rely on that alias resolution.

drwelby commented 1 year ago

I was hoping a quick regex update in the scraping would fix it but the new page returned is some NextJS mess...

jpenagg commented 1 year ago

looks like AWS might have just reverted the change?

patrickleet commented 1 year ago

looks like AWS might have just reverted the change?

I saw that, and was gonna say something, but then I refreshed and new design was back again - maybe it's some sort of canary percentage based roll-out?

drwelby commented 1 year ago

Seems to be consistently back to vanilla html.

I stashed a response and have what I think could be the basis of a fix:

aws.py.diff.txt

drwelby commented 1 year ago

Summing it all up:

AWS "upgraded" the account page to a NextJS page that does search and pagination and other pretty stuff before rolling it back
Since the page is rendered client side, there no longer were account IDs in the HTML to scrape
Solution (above) is to find the base64'ed JSON data payload in the NextJS page, decode it, then parse out the account IDs

drwelby commented 1 year ago

joepurdy commented 1 year ago

We were impacted by this change since we have a wrapper utility (https://github.com/ArcadiaPower/axolotl) that depends on gimme-aws-creds for performing the SAML login to obtain credentials. I also managed to snag the response of the new NextJS page this morning prior to AWS reverting and worked out a fix that parses the same values from the new JSON metadata.

Unless I hear differently I'll get a PR drafted for when/if AWS moves forward with the switch to the new login page.

joepurdy commented 1 year ago

Opened a draft PR (linked automatically by Github above) that accounts for the new NextJS page. My approach conditionally falls back to the existing parsing strategy if the NextJS metadata isn't present which should allow this to merge/release ahead of AWS trying Round 2 of the new login page.

I do still want to update test cases prior to getting it merged, but I pushed my changes in case anyone cares to comment and/or needs a patch faster than it takes to get a main release cut.

infa-ddeore commented 12 months ago

when is the next release with this fix?