Hi, we are using High level SAML API provided by component space for our application and our application is a Service Provider…
When isassertion expiration checked? Is it When RecieveSSO is processing the response from IdP, the assertion expiry check done?
If it checks, does it depend on SamlSession to verify the assertion timeout. I am asking this to make sure we don’t expire or delete saml session.
Also when we extend IIDCache and store the assertionIDs to prevent replay attacks, what is the use of <code hljs"=“”> “expirationDateTime” parameter in ADD method of IIDCache?Thanks,
Karun
Hi Karun,
The various SAML assertion security checks are made when you call SAMLServiceProvider.ReceiveSSO.
This includes checking the SAML assertion hasn’t expired or isn’t being replayed.
The SAML assertion includes NotBefore and NotOnOrAfter timestamps in UTC which define the period for which it’s valid. The current UTC time on the SP web server is used to determine if it’s within this period. If it isn’t, the assertion is considered to have expired. For this to work correctly, both the IdP and SP clocks should be correct. We do allow for a configurable amount of clock skew which default to a couple of minutes.
The expirationDateTime specifies when the assertion ID may be removed from the cache. This corresponds to the NotOnOrAfter timestamp of the SAML assertion plus clock skew. It’s safe to remove the ID from the cache after expirationDateTime as the SAML assertion has expired.
What is the default duration for Assertion id Cache (memory cache) ? as we haven’t implemented DB Cache yet.
and what would be the best approach to test replay attach, I tried calling ReciveSSo() twise in the same event, and I keep getting
‘An SP-initiated SAML response from <> was received unexpectedly)’ is this the correct exception message what is expected when replay attack takes place. ?
SAML assertions normally have NotBefore/NotOnOrAfter fields that specify the time period for which the SAML assertion is valid. Typically this is just a few minutes. We set the cached SAML assertion ID to timeout at NotOrAfter plus a clock skew value of three minutes. So, if the SAML assertion will expire in two minutes, the cache entry will expire in five minutes. If the SAML assertion doesn’t include a NotOnOrAfter field, the default timeout for the cache entry is one hour.
The error you’re seeing is most likely because you’re replaying a SAML response with an InResponseTo field which is causing a protocol related exception prior to the assertion replay check. Try sending a SAML response that’s part of an IdP-initiated SSO (ie no InResponseToField) multiple times.