You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I updated to the latest version of Multi-Account Container and tested if I can reproduce the issue
I searched for existing reports to see if it hasn't already been reported
Step to reproduce
(Please refer to the additional information section for more specific diagnostic steps)
Assign an AWS ALB OIDC enabled site to always open in a container.
From another window or application, open a link to the site.
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.
Final authentication step fails
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 AWSALBNonce on 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.2
Firefox Multi-Account Containers v8.1.3
I 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:
I open a new tab (assigned to temporary container T1337), and enter https://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 work container1
If I manually create a work container tab, then navigate to https://some-app.example.com/ I see the AWSALBAuthNonce cookie persists from the initial response and is present on step #3, and authentication completes successfully.
Provide a copy of Troubleshooting Information page (optional)
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:
dekimsey
changed the title
Automatic re-open container behavior too late and missies cookies from first response (causing AWS ALB SSO login failure)
Automatic re-open container behavior too late and missies cookies from first response (cause of AWS ALB OIDC login failures)
Jun 24, 2024
dekimsey
changed the title
Automatic re-open container behavior too late and missies cookies from first response (cause of AWS ALB OIDC login failures)
Automatic re-open container behavior too late and misses cookies from first response (cause of AWS ALB OIDC login failures)
Jun 24, 2024
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
AWSALBNonce
on 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
work
container1a. 💥 This request does not have an
AWSALBAuthNonce
cookie set.If I manually create a
work
container tab, then navigate tohttps://some-app.example.com/
I see theAWSALBAuthNonce
cookie 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: