Provide a mechanism for longer-lived authentication sessions

[jsimpso]

Hi,

This is a feature request to introduce some mechanism for user configurable long-lived authentication sessions.

I'm part of a team which holds a shared responsibility over hundreds of Juju models. The way we interact with those models is via a bastion server (network access restricted via VPN and firewall, access restricted via LDAP group membership), where each model is only accessible to a single service account (access to which is restricted by sudoers rules applied to subgroups of users who should have access to that model).

For example, I'm able to sudo -iu my-production-model to access the local user account, who then has access to a Juju client which is configured to talk to the model.

For the models which we've migrated to an internal JAAS controller, we're experiencing some friction from the fact that we need to re-authenticate via SSO daily, since JIMM's macaroons are only valid for 24 hours.

It would really help to reduce this friction if there was some kind of capability to configure the authorized session time (per-user, per-model, per-controller even).

I recognise that this may introduce an increased security risk, which is acceptable to us given the security mechanisms we currently have in place, but may not be acceptable to others. If you have any alternate suggestions which could help us to reduce the re-authentication friction while maintaining that security posture, please let me know!

Thanks

[kian99]

@jsimpso

While we investigate how to enable this functionality, I wanted to mention that I think the source of the 24h expiry on macaroons comes from Candid. The Mojo spec for that deployment can be found here - https://bazaar.launchpad.net/~canonical-is/canonical-mojo-specs/trunk/view/head:/cdo/jaas-candid/bundle.yaml and the line api-macaroon-timeout: 24h. I think modifying that would have the desired effect on JIMM but could also have an unintentional effect on other tools using Candid.

[kian99]

@jsimpso This has been addressed in #1029 (thanks @alesstimec)
Do you know how IS deploys their JIMM instance? Is it via charmhub or a local charm? These days we are publishing the JIMM charm to https://charmhub.io/juju-jimm and https://charmhub.io/juju-jimm-k8s (with tracks 1 and 2 tracking JIMM v1 and v2, I know that IS is using v1 JIMM).

Also, does IS have a staging JIMM instance?

[jsimpso]

@jsimpso This has been addressed in #1029 (thanks @alesstimec) Do you know how IS deploys their JIMM instance? Is it via charmhub or a local charm? These days we are publishing the JIMM charm to https://charmhub.io/juju-jimm and https://charmhub.io/juju-jimm-k8s (with tracks 1 and 2 tracking JIMM v1 and v2, I know that IS is using v1 JIMM).

Also, does IS have a staging JIMM instance?

Thanks @kian99 (and @alesstimec)!

I'll track down how our JIMM instance was deployed and get back to you.

[ale8k]

Hi @jsimpso , has there been any updates on this?

[jsimpso]

Apologies for not coming back to that one. IIRC we discovered shortly after this that JAAS/JIMM were going to undergo a major overhaul, so I think what we have today (or what we're working towards deploying) may be entirely different to what we had when this issue was raised.

I think @alejdg you're probably best positioned to understand if this is still relevant, would you mind weighing in please?

[alejdg]

Yeah, this was raised in another time, based on an old JIMM version we had deployed. Since the new versions (machine and k8s) support the macaroon expiry we are good to close this.

We still have the old jaas-candid deployment as @kian99 pointed-out but there's barely anything connecting to it and in the future everything will use the new deployments.