How long does it take to complete the login for adfs2016 to access the external claim relying party?

Question

I developed my own IDP based on the saml2 protocol
I use my own IDP to add to the claim relying party of ADFS. When the client accesses sp and jumps to adfs, it will jump to my claim relying party.
At this time, the url given to me by adfs is:
https://saml.contoso.com/idp/sso/redirect/?SAMLRequest=XXXXXXX&RelayState=b36733da-e218-4c14-9e76-ca8936ef314b&Signature=XXXXXXXXXSigAlg=http%3a%2f%2fwww.w3.org%2f2001%2f04%2fxmldsig-more%23rsa-sha256
The url format is parsed as shown in the figure below

After I decrypt the SAMLRequest, it is as follows

samlValue <?xml version="1.0" ?>  
<samlp:AuthnRequest Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" Destination="https://saml.contoso.com/idp/sso/redirect/" ID="id-1a73e702-1721-40e4-8a04-878429e43492" IssueInstant="2021-05-27T06:33:52.525Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">  
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://adfs.contoso.com/adfs/services/trust</Issuer>  
<samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>  
</samlp:AuthnRequest>  

After my idp completed the login verification, when I made the login completion response and returned it to ADFS, I used the value of the RelayState parameter in the url and the value of the ID parameter in the samlp:AuthnRequest decrypted by the SAMLRequest
How long is the survival period of these two values? Is it how long after I use these two values to complete the ADFS login?

Just after my test, I waited for about 30 minutes. When I logged in, it prompted adfs to report an error, and there were corresponding records in the event viewer. I guess it is caused by RelayState or ID expiration, but I don't know the specific expiration time or how to set the expiration time. Does adfs have an existing interface to query whether the current RelayState or ID has expired?

An error has occurred. For more information, please contact your administrator.  

Exception details:  
Microsoft.IdentityServer.Web.CookieManagers.InvalidContextException: MSIS7001: The passive protocol context was not found or it is invalid. If the context is stored in a cookie, the cookie provided by the client is invalid. Please make sure that the client browser is configured to accept cookies from this website, and then retry this request.  
    Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.GetOriginalRequestFromResponse(ProtocolContext context, Boolean deleteCookie)  
   Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)  
    Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)  

Answer 1

I don't have a lab to repro this. But you are right about the error cause. It shows up because we lost track of the session. When ADFS redirects the user to the IDP, we set a cookie MSISContext<Session GUID> with the some session info (URLs, copy of the SAMLRequest, binding info, signature...). That cookie is valid for 10 minutes. So my guess is that if you come back on ADFS more than 10 minutes later, we just forgot about you...