aws-okta 1.0.0 breaks with multiple profiles about aws-okta

[sdann]

@nickatsegment I've had one user hit the same error in 1.0.0. I'm looking into it now.

@josacar Do you have 2FA enabled in your Okta environment, either at the user (all logins) or app (AWS) level?

Also, when you delete the okta device token and the okta session cookie, you say that fixes the issue. Roughly, how long does it keep working after deleting those, before you have to delete them again?

[sdann]

So far in our environment this seems to only happen once, after upgrade from v0.27.0 and v1.0.0, and not again after the old Okta session has been manually deleted from Keychain.

@josacar Is this the case for you as well? Can you also tell me more about your Okta 2FA requirements?

[nickatsegment]

Merged and released https://github.com/segmentio/aws-okta/releases/tag/v1.0.1. @josacar please confirm and close

[josacar]

Merged and released https://github.com/segmentio/aws-okta/releases/tag/v1.0.1. @josacar please confirm and close

We are testing it and so far is working good, we can close the issue and reopen if needed.

Thanks you @sdann and @nickatsegment !

[nickatsegment]

Do you mean that this broke between v0.27.0 and v1.0.0?

Off the top of my head, I wonder if it's this: 18e92f7

If you're code-saavy, you could try a custom build with that PR reverted.

[josacar]

I'm trying, however I cannot build it on my local machine.

[nickatsegment]

Ok, try v0.27.0 for the time being and see if that alleviates it.

[josacar]

I was able to build it in my personal laptop and I can confirm reverting 18e92f7 solves the problem.

[nickatsegment]

DEBU[0000] Using okta_session_cookie_key from profile: env_aws_production_super

Looks like you're using a custom cookie name. Is it possible to run without that?

Trying to decide whether we should just revert the whole patch. I think it actually fixed the case of cookies colliding when switching between accounts though. I'd argue this patch makes it more broken since it ends up failing entirely, as opposed to causing a spurious reauth

[josacar]

This is without a custom cookie:

$ dist/aws-okta-v1.0.0-darwin-amd64 --debug exec aws_production_ro -- aws sts get-caller-identity
DEBU[0000] Parsing config file /Users/selu/.aws/config
DEBU[0000] Using KrItemPerSessionStore
DEBU[0000] cache get `aws_production_ro session (61383132653561633237)`: miss (read error): The specified item could not be found in the keyring
DEBU[0000] Using aws_saml_url from profile aws_production_ro: home/amazon_aws/0oafwlfffff9jvXDA30x7/272
DEBU[0000] Using okta provider (okta-creds)
DEBU[0010] domain: domain.okta.com
DEBU[0011] Failed to reuse session token, starting flow from start
DEBU[0011] Step: 1
DEBU[0013] Step: 2
DEBU[0013] Step: 3
getting creds via SAML: Okta user josacar does not have the AWS app added to their account.  Please contact your Okta admin to make sure things are configured properly.

[nickatsegment]

@sdann you wrote the original PR; any ideas? I'm tempted to just revert the whole thing if it's breaking stuff

[sdann]

Unfortunately, that error message is just a catch all when Okta returns any response that doesn't include a SAMLResponse assertion. The problem could be multiple things, unrelated to whether you have permission to the Okta AWS app.

I'm able to repro that error, by changing my stored okta session cookie to garbage. My environment requires 2FA. When a garbage session cookie is sent, along with DT my environment goes down a path of requesting 2FA via the WebUI, redirecting to:

/policy/second-factor?...
/login/login.htm?...

Then login.htm gets parsed for a SAMLResponse section, which doesn't exist, and getting creds via SAML: Okta user does not have the AWS app... is returned.

It's not obvious to me, how or why this flow is failing, but it seems related to 2FA. If your environment doesn't have 2FA required, then the first fix we should try is detecting that based off your config from aws-okta add and NOT send the DT cookie for any requests.

[josacar]

I cleared every enter in keychain several times just in case and it happens. I'm using okta push as MFA.

…

-------- Original Message --------

On Feb 4, 2020, 20:44, Steven Danneman wrote: So far in our environment this seems to only happen once, after upgrade from v0.27.0 and v1.0.0, and not again after the old Okta session has been manually deleted from Keychain. ***@***.***(https://github.com/josacar) Is this the case for you as well? Can you also tell me more about your Okta 2FA requirements? — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](#279?email_source=notifications&email_token=AAMODXVGECBLNVBJ7T3LB33RBHASLA5CNFSM4KL6YWE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKY547Y#issuecomment-582082175), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAMODXSF2LVWWL7CWQTOTUTRBHASLANCNFSM4KL6YWEQ).

[joseluis-fw]

@josacar Do you have 2FA enabled in your Okta environment, either at the user (all logins) or app (AWS) level?

We have 2FA in our Okta environment and we have always 2FA in some Okta apps, we have nothing extra in AWS.

[sdann]

With the current version, we're initially reusing the stored session and device token. These seem to both expire at the same time. aws-okta detects that the session is expired and restarts the authn flow, but keeps sending the same device token.

The creds to session flow succeeds, but during the session to SAMLAssertion request, the Okta server then realizes the device token that we've been sending is expired, and prompts for 2FA again through an HTML flow.

aws-okta doesn't have any detection for this. We could parse this 2FA prompt and restart the 2FA flow, but it's easier to clear out device token cookie at the same time we detect the session is expired.

I've got a preliminary patch that fixes my repro. I'll clean it up and do some more testing before PR.

[sdann]

@nickatsegment Proposed fix in PR #280

[josacar]

This fix is working for us pretty well, even we get the proper caching of 2FA step between profiles.