Store IdP session token/cookie for IdP-side session maintenance

[emmanuel]

At my org we use Okta as our IdP, with Okta configured to issue an MFA challenge once every 12h. Our AWS roles, by contrast, are configured for the default 1h expiry. I am aware of the (fairly recently added) ability to configure IAM roles for longer sessions. However, this issue is meant to open a conversation to discuss another option.

Namely, if the session token returned by Okta were retained by saml2aws after initially authenticating, it could be used in follow-up calls to fetch updated SAML assertions without needing to authenticate to Okta each time. Because of the sensitivity of the Okta session token, I would imagine storing it in secure local storage (e.g., the macOS Keychain or equivalent).

Given that it is a temporary credential, I'm not sure exactly how the flow would work around IdP session token expiry. One question: is there a way to set an expiry time on a Keychain entry such that it 'disappears' at a specific time? If yes on Keychain expiry, then the implementation could utilize an existing session token when available and initiate authentication when not. If no on Keychain expiry, then I think the implementation be similar, but would utilize an existing session token when present, and re-authenticate if the IdP refuses the existing session token (which, frankly, would need to be handled even if the Keychain supports expiry).

Other IdPs (other than Okta) may use a session cookie for the same purpose, especially where they are more browser-oriented. That said, I believe the same approach could be used for session cookies as well, presumably by storing/retrieving the cookie jar into/from secure local storage (e.g., Keychain).

Does this make sense (have I misunderstood things)? Does anyone else think this would be useful/valuable? And finally (most importantly), is there any desire to include functionality like this in saml2aws?

[emmanuel]

To answer my own question, from a brief Google search, it appears that macOS keychain does not support expiry for arbitrary secrets: https://apple.stackexchange.com/a/266493.

So, saml2aws would have to just look in the Keychain, and try to fetch SAML from the IdP when a session is there and authenticate if/when the IdP refused to return a SAML assertion (2nd option from above description).

[emmanuel]

Here is further corroboration that the above StackOverflow answer is accurate and that macOS Keychain does not support setting expiry for arbitrary secrets (that it merely reports expiry, e.g., for certs).

The two classes of Keychain entries that could apply in this scenario are kSecClassInternetPassword and kSecClassGenericPassword. Neither support setting expiry.

Anyhow, all of the rest of my question remains.

[wolfeidau]

@emmanuel I tried this for Ping Fed, but it turns out the tokens are normally issued with a brief expiry, in my case 5 minutes. This is by design so the SAML assertion can be converted to the service providers token.

You can decode and extract view expiry from your SAML assertion, it is in the XML.

[emmanuel]

@wolfeidau, I think you are misunderstanding my proposal. I’m not suggesting holding on to the SAML assertion itself, rather the session token that is presented to the IdP and exchanged for the SAML assertion. At least, that’s how it works for Okta: authentication yields a session token (from IdP), which is exchanged for a SAML assertion (from IdP), which is exchanged for a set of AWS creds (from STS). I’m proposing holding on to the session token, but I think you’re talking about the limits of trying to hold on to the SAML assertion.

Did I misunderstand you? Or did you misunderstand me? ;)

[emmanuel]

Another thought that occurs to me is to imitate a browser for the Okta provider, and to retain the cookie that is set after authentication with an MFA challenge (storing the cookie in the keychain).

This would clear the way toward a --re-up mode, by allowing the user to answer an MFA challenge and indicate that they don’t want to be challenged again for X days (on this device, i.e. saml2aws).

Does this make sense?

My whole point with this line of inquiry is to achieve the ease of use of the browser experience with saml2aws, while remaining compliant with org-level MFA policies. With saml2aws as it stands today, in my org I have to answer an MFA challenge every hour. With the browser I have an MFA challenge once every day. I’m trying to get to parity between the two.

[cervantek]

This is a great idea! saml2aws should match a browser's treatment of IDP session cookies (or the Duo iframe used by Okta and Shib). This would greatly reduce the amount of times our staff have to answer MFA prompts when logging in with saml2aws.

If someone created an implementation of this for one of the identity providers, @vacovsky or I could port it to the Shibboleth identity provider.

Please consider doing this feature! Thanks.

[josqu4red]

From a Google IdP user's point of view, this could also avoid getting a "Security alert" email at each login, so big 👍 .

[dorki]

This could really help us as well (also using Google as Idp). Any chance there's an update on this ?

[adammw]

As a point of comparison, https://github.com/segmentio/aws-okta stores the okta session cookie in the keychain. Although open question if you would want this to be provider specific or simply a cookie jar for all HTTP requests that persists between executions.

[faridnsh]

We are using ADFS and this would make the process of logging in as painless as possible. I'd be happy to help with the implementation of this, if project owners could provide some directions.

[archoversight]

I'd love it if saml2aws stored the cookie that gets set on successful login to Keycloak, so that the next time it goes through the process of getting a SAML assertion it can bypass the MFA requirement until Keycloak deems it necessary again.