SAML flow within MFA flow - possible c14n problem

Mon Sep 19 09:07:40 UTC 2022

I have gone nuclear on this and done a fresh 4.2.1 install to make sure I didn't have any odd config hangovers, flow lifetimes and timeouts set individually via properties to PT5M for testing and all settings other than SameSite conditions (TRUE) and the supported prinicipals are the defaults. I turned on trace on the org.opensaml.storage to see what was being written to storage. Each storage entry has two parts, the "_session" and then one depending on the single flow used "authn/SAML" or "authn/Password". I've been looking at the two epoch numbers in each entry, one marked "ts" (presumably timestamp) and "x" (expiry?), e.g for Password flow....

2022-09-16 14:11:09,064 - XX.XX.XX.XX - TRACE [org.opensaml.storage.impl.client.JSONClientStorageServiceStore:152] - StorageService shibboleth.ClientSessionStorageService: Data before encryption is {"5a6......15d71b":{"authn/Password":{"v":"{\"id\":\"authn/Password\",\"ts\":1663333868928,\"princ\":[{\"typ\":1,\"nam\":108},{\"typ\":3,\"nam\":200},{\"typ\":1,\"nam\":107},{\"LDAPN\":\"myuid\",\"LDAPE\":{\"dn\":\"cn=MYUID,ou=staff\",\"passwordExpirationTime\":[\"xxx\"]}},{\"U\":\"myuid\"}]}","x":1663334768928},"_session":{"v":"{\"ts\":1663333368653,\"nam\":\"myuid\",\"v4\":\"172.20.150.42\",\"flows\":[\"authn/Password\"]}","x":1663337459069}}}

I notice that "x" for the login flow entry (and not the _session) always seems to be ten minutes ahead of the current time plus the timeout i have set, so I guess this has got the default cleanupInterval time added? In any case these "x" numbers update with every service visit for both Password and SAML flows as expected so that is all working OK.

However, the flow "ts" epochs behave differently for Password and SAML. After the first lifetime expiry, the Password flow updates with the time of the next authentication in the ts number and is subsequently reusable, but when running the SAML flow the ts number remains the same as the first expired flow (despite the "x" updating successfully). This SAML flow result is then permanently unusable due to it always being past the permitted lifetime.

I'm still not discounting other factors external to the IdP, but the trace from the Storage Service "Data before encryption" is directly after the reported successful update of the session details with the new authentication, so presumably there isn't any interaction outside the IdP during this stage. Is there any extra trace I can run to see if there was a problem with the authentication from the SAML flow, as the logs we get at this level indicate everything was successful, but the "ts" number in the "Data Before Encryption" trace is the timestamp of the previous authentication and not the most recent one.

The log snippet below is for the SAML flow, after the second authentication after first flow expiry, but the events leading up to the storage write in the Password flow are the same.

(This is all me presuming that the "ts" epoch is the lifetime sliding window, apologies if this isn't the case!)

Thanks for all the help and advice again,
John

 2022-09-16 12:21:40,601 - XX.XX.XX.XX - INFO [net.shibboleth.idp.authn.impl.FinalizeAuthentication:196] - Profile Action FinalizeAuthentication: Principal myuid authenticated
2022-09-16 12:21:40,602 - XX.XX.XX.XX - DEBUG [net.shibboleth.idp.session.impl.UpdateSessionWithAuthenticationResult:201] - Profile Action UpdateSessionWithAuthenticationResult: Adding new AuthenticationResult for flow authn/SAML to existing session 98b1973c98....2249157a76
2022-09-16 12:21:40,602 - XX.XX.XX.XX - DEBUG [net.shibboleth.idp.session.impl.StorageBackedIdPSession:572] - Saving AuthenticationResult for flow authn/SAML in session 98b1973c98...2249157a76
2022-09-16 12:21:40,604 - XX.XX.XX.XX - TRACE [org.opensaml.storage.AbstractMapBackedStorageService:402] - Updated record 'authn/SAML' in context '98b1973c98...2249157a76' with expiration '1663328200593'
2022-09-16 12:21:40,604 - XX.XX.XX.XX - DEBUG [net.shibboleth.idp.session.AbstractIdPSession:300] - IdPSession 98b1973c98...2249157a76: replaced old AuthenticationResult for flow ID authn/SAML
2022-09-16 12:21:40,746 - XX.XX.XX.XX - TRACE [org.opensaml.storage.impl.client.ClientStorageService:498] - StorageService shibboleth.ClientSessionStorageService: Preserving storage state from session
2022-09-16 12:21:40,747 - XX.XX.XX.XX - TRACE [org.opensaml.storage.impl.client.JSONClientStorageServiceStore:151] - StorageService shibboleth.ClientSessionStorageService: Size of data before encryption is 1117
2022-09-16 12:21:40,747 - XX.XX.XX.XX - TRACE [org.opensaml.storage.impl.client.JSONClientStorageServiceStore:152] - StorageService shibboleth.ClientSessionStorageService: Data before encryption is {"98b1973c98...2249157a76":{"_session":{"v":"{\"ts\":1663326815575,\"nam\":\"myuid\",\"v4\":\"XX.XX.XX.XX\",\"flows\":[\"authn/SAML\"]}","x":1663330899891},"authn/SAML":{"v":"{\"id\":\"authn/SAML\",\"ts\":1663326812947,\"princ\":[{\"NID\":\"myuid\",\"F\":\"urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified\"},{\"typ\":1,\"nam\":\"https://refeds.org/profile/mfa\"},{\"AA\":[\"https://sts.windows.net/6e725c29-763a-4f50-81f2-2e254f0133c8/\"]},{\"IDPATTR\":\"azureObjectidentifier\",\"VALS\":[{\"STR\":\"b260....a7a\"}]},{\"IDPATTR\":\"azureIdentityprovider\",\"VALS\":[{\"STR\":\"https://sts.windows.net/6e7....3c8/\"}]},{\"IDPATTR\":\"azureTenantid\",\"VALS\":[{\"STR\":\"6e7...3c8\"}]},{\"IDPATTR\":\"azureAuthnmethodsreferences\",\"VALS\":[{\"STR\":\"http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password\"},{\"STR\":\"http://schemas.microsoft.com/claims/multipleauthn\"}]},{\"IDPATTR\":\"azureMailnickname\",\"VALS\":[{\"STR\":\"myuid\"}]}]}","x":1663328200593}}

________________________________
From: Cantor, Scott <cantor.2 at osu.edu>
Sent: 13 September 2022 17:36
To: John Watt <John.Watt at glasgow.ac.uk>; Shib Users <users at shibboleth.net>
Subject: Re: SAML flow within MFA flow - possible c14n problem

> from this I assume that (in the SAML flow in isolation, no MFA flow calling it)
> there is also nothing stopping a new result from being loaded into a new
> session in the user's browser after the old one expires? (as it does in
> Password flow).

No, that's all general code, it doesn't know anything about the specifics of what the login mechanism is.

> I can't see why this SAML flow can't load a new session/result after the first
> one expires

It can't not be there, the issue is reuse and why it doesn't believe it can do that. Or the issue is something with the session as a whole, such as it being too big for a cookie and local storage not being enabled, that kind of thing. Or even SameSite or frames, I suppose. I suspect you have cookie problems, not session issues.

> Out of interest, is there a way to set an individual flow to have no lifetime or
> timeout in its own properties? Or does this rejection of idp sessions need to
> be set globally in the idp.session.enabled?

There is no way for them to be unset, but a reuseCondition of false will obviate any reuse of a result regardless of the other settings, as of course in practice would a lifetime that's very short.

-- Scott

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220919/25032135/attachment.htm>