Jira DC instance behind Okta that logs users out with a 401 error

[Ben Radlinski]

Ever since we moved our Jira DC to a proxy with access through CloudFront, users that keep Jira pages open for long periods of time are reporting that they return to their browser with a 401 error. They are forced to reauth with Okta and are not returned to the same page. 

My assumption is that CloudFront is probably killing idle connections and as a result, Jira thinks the user has logged out. Is there any way to avoid this? Is there a way to direct them back to the page they were on?

[Jim Knepley - ReleaseTEAM]

I'm not sure why it matters how long a page is open, and my experience isn't directly with Jira (we used an ALB when I implemented it), but this might help.

CloudFront removes the Authorization header on several types of requests (see https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-headers-behavior)

You can change this behavior by allowing the Authorization header in your CloudFront configuration.

In the AWS console for your CloudFront distro, view "Cache Behaviour Setting" and "Edit"
Select "Whitelist" under "Cache Based on Selected Request" and "Add >>" the "Authorization" header to the "Whitelist Headers" list.

[Ben Radlinski]

Thanks, I will check it out!

[Ben Radlinski]

I had a discussion with our security/Okta guy and this has been an issue for other apps for a while, and it's related to Okta, not CloudFront.

Users authenticate via Okta to access Jira Data Center. Once authentication has been established it's handed off to Jira. Users open a bunch of issues during the week and leave them open during the weekend. The Jira authentication times out during the weekend and redirects to the Okta auth page. All pages that were left open, start to refresh and are redirected to Okta. Because Okta has no knowledge of where that page was going before, it throws the 401 error if the user attempts to open it.

I am testing out saving open issues in a Chrome tab group and letting them expire overnight, then log back into Jira via Okta before reopening the tab group. 

I don't think there's a workaround for this as Okta is doing what it's supposed to do. We could make our Jira auth sessions unlimited, but I'm guessing I wouldn't get approval for that. :-)

[Marty Henderson]

Ben - I don't know for sure, but there must be a way for Okta to preserve some of the url parameters to setup the redirect after login when the session expires. This seems like it should be possible? When the auth expires in Jira, it will send that os_destination param as the last page it was on, there's got to be a way for Okta to preserve that somehow.

[Marty Henderson]

I have some ideas, but no guarantees..... :-)

It sounds like it could be either Okta or the proxy is stripping off the url params (os_destination) that Jira uses to manage the redirect after login.

Without knowing your specific setup, I'd say take a look at both configurations and see if you can configure it to preserve the os_destination parameter. Or if there's an Okta specific parameter for that type of thing?

It looks something like this:

<your_jira_url>/login.jsp?os_destination=<users_page>

[Ben Radlinski]

I will take a look at that, appreciate it.

[Ben Radlinski]

So it did turn out to be Okta related (see above). I'm not sure we can keep Okta from doing what it's doing in this situation.