Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a mechanism for longer-lived authentication sessions #1018

Open
jsimpso opened this issue Jul 31, 2023 · 3 comments
Open

Provide a mechanism for longer-lived authentication sessions #1018

jsimpso opened this issue Jul 31, 2023 · 3 comments

Comments

@jsimpso
Copy link

jsimpso commented Jul 31, 2023

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
Copy link
Contributor

kian99 commented Aug 10, 2023

@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
Copy link
Contributor

kian99 commented Aug 22, 2023

@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
Copy link
Author

jsimpso commented Aug 23, 2023

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants