IssueTracker

Hello,

We have shared this to our engineering team and unfortunately I am not able to provide an E.T.A on the fix. Future update(s) will be posted here.

We recently implemented an experimental workaround for this. We're looking for feedback on it if you'd like to give it a try. What you'd need to do is one of the following:

1. Add an iframe in your application pointing to /_gcp_iap/session_refresher, e.g. <iframe src="/_gcp_iap/session_refresher" style="width:0;height:0;border:0; border:none;"></iframe>

2. Instruct your users to load https://yourapp/_gcp_iap/session_refresher in an extra tab.

I realize this is hoaky and no substitute for a proper fix, but let me know if it's at all a viable workaround for you!
  --Matthew, Cloud IAP engineering lead

Appears to work. Thanks

@ms...@google.com We're using the second option you listed now and it seems to work well. Thanks!

Awesome, thanks Geoffrey and Zach! I'll leave this issue open to track the proper fix, but we'll go ahead and document session_refresher.

I tried both solutions and the second one work for the desktop browser. But my main application is using via android tablet with "<meta name="mobile-web-app-capable" content="yes">". So it open on a separate full screen window. I tried to load the page[my_app/_gcp_iap/session_refresher] on main chrome browser but it is not working.

Any idea how can i achieve this workaround on mobile web page?

any updates on an ETA for a fix without the workaround?
we use this to supply access to applications we do not have direct control over and adding an iframe in them is not an option

#7: I'd expect the iframe solution to work in that environment, though I haven't tested it. I don't suppose you're able to use https://cloud.google.com/iap/docs/authentication-howto#authenticating_from_a_mobile_app ?

#8: Understood.  No ETA at this time, but it's a high priority.  I'll post any updates here.

The workaround is now documented: https://cloud.google.com/iap/docs/sessions-howto

I tried "Modify your application code to handle the HTTP 401 response." step that include in the document. But I keep getting the following error.

"(index):1 Failed to load https://accounts.google.com/o/oauth2/v2/auth?client_id=643514917173-c9ai54k0e8ng6hkgpbqnhogf20k2tt7p.apps.googleusercontent.com&response_type=code&scope=openid+email&redirect_uri=https://[mydomain_here]/_gcp_gatekeeper/authenticate&state=CkBodHRwczovL3NnY29udHJhY3RnY3AuY29yZGxpZmUuY29tL3NlcnZpY2VzL2NoZWNrLWNvbm5lY3Rpb24uc3ZjEjBBR1k1bEFLb0s1RGRxTEdKX2dYQ2V6R2pRZm4tN0REVGFnOjE1MTczNjg1NzU2MDY: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://[mydomain_here]' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled."

Any ETA for a fix? We also have internal applications we access via IAP that we are unable to edit or add iframes to.
We are starting to evaluate other solutions now, which is not the route we wanted to go.

Appreciate your help.

Hi Paul, I'm sorry this is taking so long.  There's a fix we're considering which I'd anticipate being able to roll out in April that would:

1. Change the IAP session lifetime from 1 hour to 20 hours.
2. Add a check so that, for every request with a valid session, IAP calls out to the Google identity system to verify the following:

2a. Account is not suspended or disabled
2b. Account does not have the 'force password reset' flag set
2c. Account's password was not changed after the IAP session started
2d. Does *not* check that the user didn't "sign out" of the Google session that was active when they started their IAP session (we may add this in the future but we're considering skipping it for now to get this rolled out sooner). This means that an IAP session would be valid for up to 20 hours after the user signed out of Google. IAP sessions can be separately logged out by going to https://DOMAIN/_gcp_iap/clear_login_cookie. (Note that if a *Google* session is still active, anyone with access to the browser can log back into IAP after /_gcp_iap/clear_login_cookie without re-entering a password or second authentication factor.)

That is to say, the IAP session lifetime would increase to 20 hours and we would additionally verify 2[a-c] on every request. The reason we've left the current session length capped at 1 hour in spite of the pain this causes for AJAX is that today we do *not* verify any of 2[a-d], and we rely on the Google identity system to check these properties when IAP establishes a new session every hour.

I'd love to get some feedback on this. In particular, are there existing IAP customers for whom increasing the session length to 20 hours would be an unpleasant security surprise? Would the answer change if we added a check for (2d)?

Also, if you're willing to take (1) *without* any of the additional checks in (2) -- a 20-hour session lifetime where IAP sessions will be valid for up to 20 hours after an account is suspended or disabled (e.g. employee exit), password is changed (e.g. account compromise), or user signs out of Google session without also signing out of IAP session (e.g. shared browser / shared computer scenarios), it's *possible* that we could implement that sooner (probably in the 2-3 weeks timeframe) and put it behind a project-specific whitelist (e.g. the change would be off by default but we could whitelist specific projects for it.) Let me know if that's something you're interested in.

Re: #13

Thanks for the update. If I understand what you're describing, we'd still have to use the session_refresher tab in our case. One of our primary uses for IAP is for unsecured internal utilities (e.g. Prometheus monitoring dashboards that are on wall-mounted screens). The 20-hr session would mean we'd still have to re-log in every day.

A 30-day session like gmail (GSuite generally, I guess) has would be fine for our case.

Hi Matthew,

2[a-c] all seem like great changes, and would satisfy a lot of concerns around using IAP with more sensitive data. In light of those, 2d seems like behavior that we wouldn't mind, but don't have a particular need for.

We tend to prefer longer session lifetimes, and I think we'd always be happy with 20+ hours as long as check 2a happens on each request. (We'd love pretty much anything up to 30 days.)

One additional check that would be useful with a change to longer sessions is whether the user is still on the project's IAP user whitelist. Invalidating sessions after a user's account has been disabled / suspended seems like the highest priority from a security standpoint, but a more common use case might be removing a user's access to an application by taking them off the whitelist (or removing them from a whitelisted group). For example,  an employee changes departments and still has an account, but should no longer have access to their previous department's apps.

Thanks for the feedback, Michael and Zach.

Zach: Correct that you would need some page-refresh mechanism for that use case. Request for gmail-esque session length noted.

Michael: We're already doing an ACL check on every request, independent of the IAP session length. (The session length we're talking about here only applies to authentication, not authorization.) There's some caching involved so access revoke isn't instantaneous, but off the top of my head I think access revoke should typically take effect on the order of minutes.

Hi, sorry for the delay here, this is taking longer than expected. We're still working on implementing the #13 checks, but there's a temporary workaround that we can turn on for specific projects if anyone wants to try it. The way it works is, we attempt to detect whether a request is an AJAX call or not, and *for AJAX calls only*, we have an increased session length *without* the additional checks described in #13.

From a security standpoint, this has some risk. An attacker who obtains an IAP session cookie could trivially issue a request that appears to be an AJAX call (e.g. by adding "X-Requested-With: XMLHttpRequest") to trigger the increased session length. However, if you have a limited-sensitivity application where you're willing to turn this on until we can get a better solution in place, send me an email with your project number and desired session length (it's configurable per-project, so we can set it for 30 days, Zach): cloud-iap-session-length-increase-request-external-apr2018@google.com

The proposal from #13 is now ready for testing, please contact cloud-iap-session-length-increase-request-external-apr2018@google.com if you'd like to try it.

The iframe solution e.g.  e.g. <iframe src="/_gcp_iap/session_refresher" style="width:0;height:0;border:0; border:none;"></iframe> was working well for us but recently we've started to get issues.

Users are receiving an error message saying:

There was a problem with your request. Error Code 13.

This happens once / twice a day for a user.

If the user hits refresh in the browser and tries the same action again it all works fine.

Any progress on a permanent solution for this issue? It has been quite some time since this was last updated.

I have noticed in our use case that sometimes a simple refresh does not solve the timeout issue. If we navigate to our IAP protected app and create a session, then close the app tab and come back some hours later, the app will load but all AJAX will return 401. We also see similar errors to #11. Subsequent refreshes do not resolve this unless the user performs a "hard refresh" (Ctrl + F5). The iframe session refresher does appear to work for long sessions on an active tab of the app despite this issue.

At long last, this issue is fixed. IAP sessions for all applications will be valid as long as the underlying Google login session is valid. You should no longer need to use the "/_gcp_iap/session_refresher" mechanism.

Thank you for your patience!

I have a Twitter thread with more background and technical detail on the solution if folks are interested: https://twitter.com/mattsachs/status/1136327101731049472

This link https://twitter.com/mattsachs/status/1136327101731049472 is no longer working, do you still have details on this?

We are having similar issues, would like to resolve it.