Automatic re-open container behavior too late and misses cookies from first response (cause of AWS ALB OIDC login failures) #2646
Labels
bug
Something is broken!
Component: Site Assignment
Issues related to assigning a site to a container
Status: Expected
This behavior is expected of the add-on
Comments
dekimsey
changed the title
dekimsey
changed the title
|
I am having a similar issue, were you ever able to determine a fix? |
|
No good ones. I've been dealing with it by manually opening the given site doing the login dance and then for the rest of my login session any future links will open correctly as I'm not being redirected. Frankly, been thinking of giving up since it's been so broken. It lifts my heart I'm not the only one noticing though... 😁! |
dannycolin
added
Component: Site Assignment
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Before submitting a bug report
Step to reproduce
(Please refer to the additional information section for more specific diagnostic steps)
a. The inital request will load and then redirect to the OIDC provider
b. Complete three-legged authentication flow.
c. OIDC provider will now redirect to initial web-app.
Actual behavior
After successful third-party authentication, the final redirect to the original site will fail with a "401 Authenticate" error response from the ALB.
Expected behavior
Navigation works normally and I'm logged in.
From what I can gather, I think this might be specific to AWS ALB SSO integrations. After digging into the request flows the stand-out is that my client no longer has an
AWSALBNonceon the redirect back to the web-app for the last leg of the three-legged authentication flow.Additional informations
The following is based on some digging I had performed and was reporting internally to support teams, so it's backdated about a month ago when the issue first-appeared.
Relevant Addons:
Temporary Containers v1.9.2I have re-tested this without Temporary Containers enabled and I still observe the problematic behavior.
What's strange to me is this has worked for years without issue (both here and $lastjob). So I'm curious if anything has recently changed on our side, I suspect the answer is no and the recentFirefox 128.0 change may be related. As the behavior has started fairly recently (wrote 2024-05-23). I'm looking to see if that's been a behavior change since last few weeks or so.
Observations:
T1337), and enterhttps://some-app.hashicorp.services/a. The first response from ALB sets a cookie
AWSALBAuthNonce=foo, and 302's to Okta for SSO.b. Navigation happens in
workcontainer1a. 💥 This request does not have an
AWSALBAuthNoncecookie set.If I manually create a
workcontainer tab, then navigate tohttps://some-app.example.com/I see theAWSALBAuthNoncecookie persists from the initial response and is present on step #3, and authentication completes successfully.Provide a copy of Troubleshooting Information page (optional)
Troubleshooting Information
Footnotes
At some point in step 1, FF re-opens the tab into the assigned container,
work. From the available multi-tab logs, I cannot tell if this action happens before the initial request or after. Based on what I'm seeing here with this nonce cookie being dropped, I'd assume after its the only action that makes sense. ↩The text was updated successfully, but these errors were encountered: