<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<span style="font-size:12pt;margin:0px">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....</span>
<div style="font-size:12pt;margin:0px"><br>
</div>
<div style="font-size:12pt;margin:0px">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}}}<br>
</div>
<div style="font-size:12pt;margin:0px"><br>
</div>
<div style="font-size:12pt;margin:0px">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.</div>
<div style="font-size:12pt;margin:0px"><br>
</div>
<div style="font-size:12pt;margin:0px">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.</div>
<div style="font-size:12pt;margin:0px"><br>
</div>
<div style="font-size:12pt;margin:0px">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. </div>
<div style="font-size:12pt;margin:0px"><br>
</div>
<div style="font-size:12pt;margin:0px">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.</div>
<div style="font-size:12pt;margin:0px"><br>
</div>
<div style="font-size:12pt;margin:0px">(This is all me presuming that the "ts" epoch is the lifetime sliding window, apologies if this isn't the case!)</div>
<div style="font-size:12pt;margin:0px"><br>
</div>
<div style="font-size:12pt;margin:0px">Thanks for all the help and advice again,</div>
<div style="font-size:12pt;margin:0px">John</div>
<div style="font-size:12pt;margin:0px"><br>
</div>
<div style="font-size:12pt;margin:0px"> 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
<div style="margin:0px">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</div>
<div style="margin:0px">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</div>
<div style="margin:0px">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'</div>
<div style="margin:0px">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</div>
<div style="margin:0px">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</div>
<div style="margin:0px">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</div>
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}}</div>
<span style="font-size:12pt;margin:0px"></span><br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Cantor, Scott <cantor.2@osu.edu><br>
<b>Sent:</b> 13 September 2022 17:36<br>
<b>To:</b> John Watt <John.Watt@glasgow.ac.uk>; Shib Users <users@shibboleth.net><br>
<b>Subject:</b> Re: SAML flow within MFA flow - possible c14n problem</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">> from this I assume that (in the SAML flow in isolation, no MFA flow calling it)<br>
> there is also nothing stopping a new result from being loaded into a new<br>
> session in the user's browser after the old one expires? (as it does in<br>
> Password flow).<br>
<br>
No, that's all general code, it doesn't know anything about the specifics of what the login mechanism is.<br>
<br>
> I can't see why this SAML flow can't load a new session/result after the first<br>
> one expires<br>
<br>
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.<br>
<br>
> Out of interest, is there a way to set an individual flow to have no lifetime or<br>
> timeout in its own properties? Or does this rejection of idp sessions need to<br>
> be set globally in the idp.session.enabled?<br>
<br>
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.<br>
<br>
-- Scott<br>
<br>
<br>
</div>
</span></font></div>
</body>
</html>