Open Bug 1439858 Opened 7 years ago Updated 3 years ago

Make the Treeherder Auth0 session window be greater than 24 hours

Categories

(Tree Management :: Treeherder, enhancement, P3)

enhancement

Tracking

(Not tracked)

REOPENED

People

(Reporter: emorley, Unassigned)

References

Details

(Whiteboard: [iam-RFE])

Currently Treeherder's Auth0 session is silently maintained so long as Treeherder is visited at least once every 24 hours. However this means that for weekends/single vacation days/... it's common to get logged out. As such, I was hoping to raise the window to at least 3 days (which would mean a session last used on Friday would still work on Monday), if not a week. Regarding security impact, the Auth0 session is used in two places: 1) client side by taskcluster-client-web for requesting taskcluster tokens 2) on the backend via the custom d-r-f login API For #1, it is my understanding that: (a) the taskcluster credentials are very short lived (how long?), (b) the taskcluster login service performs validation of the user each time new credentials are requested ...so if a user's permissions changed or their LDAP account were disabled, then even with a long-lived Auth0 Treeherder session, their access would be limited. For #2, the Treeherder backend session doesn't really give access to anything dangerous. Most users have the same permissions as brand new user would (and anyone can create a new account), and even 'sheriff' permissions only allow access to fairly low-risk features (like triaging performance alerts). As such, it seems safe to increase the expiry time. Dustin/Hassan, is there anything I'm overlooking?
(a) yes, 15 minutes (b) yes so yes, access would be limited. This sounds fine to me.
Sounds good to me. To raise the window, I believe you need to get in touch with the IAM team and request they raise it to 3 days.
I think that's done through Slack or Discourse or Service-Now. They don't really use Bugzilla.
The session lifetime is currently set to our standard 604800
The ID token (guaranteed to be a JWT) is set to 604800, however the access token is set to 1 day. We are currently refreshing the token every 15 minutes but would like a way to keep treeherder users not get logged out every weekend.
After speaking with :kang and :andrew, it turns out the API access tokens has a limited maximum life time of 86400 (1 day) for browser and server flows. So I'm not sure we can raise the window higher here. Having long sessions with privileges is dangerous and not recommended. Many of these applications store the tokens in localStorage which can open doors for XSS. You can even reuse these tokens from different RPs. Kang recommends to use http-only cookies for the session, which is a safer solution, however, should still expire but can be much longer lived.
fwiw, the new login experience now has an automatic login on auth0 which should ease the login pain. Love that feature :)
Ed, can we close this bug? The Auth0 session window is already set to max and cannot be greater than 24 hours.
Flags: needinfo?(emorley)
Cannot be, or they would rather it not be? I agree the Auth0 auto-login makes this less annoying, however I'd still like to increase the session window if possible.
Flags: needinfo?(emorley)
Cannot be. From a previous conversation: kang [7 days ago] the api access token lifetime itself is already set to maximum kang [7 days ago] ie this will not allow a higher value kang [7 days ago] (for the same reason that the RP access tokens are not settable, the API access tokens have a limited maximum life time) kang [7 days ago] we set it to max per your or dustin ask in the past (might be dustin if you don't remember it) kang [7 days ago] its set to 86400 for browser flows (and server flows) right now on the TC authorizer (which again is the max it will allow regardless)
Ah thank you. In that case, I guess can't increase it even if we wanted to - easy decision! :-)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID

Via #servicedesk this morning:
10:22 AM <evilpie> is it normal that I have to login into Auto0 basically every day?
10:31 AM <burningchrome> evilpie: is this for all services, or specific ones?
10:32 AM <evilpie> burningchrome: I think I actually just use lando
10:34 AM <burningchrome> ok, I don't have details on the settings for lando but I've looped in the rest of the service desk team so someone should have answers for you soon
10:35 AM <evilpie> burningchrome: thank you
10:39 AM <burningchrome> evilpie: sounds like the EIS team are more likely to have answers
10:42 AM <lucius> evilpie: as far as I know, we (EIS) don't own lando. Do other folks on your team who use lando have a similar experience?
10:42 AM <evilpie> I don't know, I will ask around
10:44 AM <lucius> I'm told that smacleod might be a good person to talk to if your team says that your experience isn't normal
10:44 AM <lucius> although I think ckolos runs the service
10:47 AM <evilpie> thanks for your help, it's really not a big deal
10:47 AM <lucius> Eh, it sounds annoying :)
10:50 AM <kwierso> evilpie: fwiw, the same thing happens for auth0 via treeherder. If I don't have authenticated activity in treeherder within 24 hours, it usually signs me out.
10:50 AM <evilpie> kwierso: oh that sounds right on the mark
10:50 AM <kwierso> I think it just has a really short session time
10:51 AM <kwierso> can't really fault it for that since it gives access to so many things
10:56 AM <lucius> We dug around a little on our end, and it looks like this is expected, but session times could be extended on the Auth0 side for this application. Service owners just need to submit a request here: https://mozilla.service-now.com/sp?id=sc_cat_item&sys_id=1e9746c20f76aa0087591d2be1050ecb and we could technically make the session expiration up to 7 days (which
10:56 AM <lucius> is the max time we allow session tokens in any auth0 connected system to exist as far as I know)

Maybe we can revisit this?

Flags: needinfo?(emorley)

I think it was the security team's guidelines that set the 24 hours limit perhaps then. Have those guidelines changed?

Status: RESOLVED → REOPENED
Flags: needinfo?(emorley)
Resolution: INVALID → ---

Anyone who really wants to take this and run with it is welcome to pick it up, however, it is not a P1 for the Treeherder team.

Priority: P1 → P3
Whiteboard: [iam-RFE]
You need to log in before you can comment on or make changes to this bug.