ComponentSpace

Forums



SAML Assertion Replay attacks


SAML Assertion Replay attacks

Author
Message
karun
karun
New Member
New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)New Member (8 reputation)

Group: Forum Members
Posts: 5, Visits: 121
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  "expirationDateTime" parameter in ADD method of IIDCache?Thanks,
Karun

ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)

Group: Administrators
Posts: 3.1K, Visits: 10K
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.

Regards
ComponentSpace Development
satish
satish
New Member
New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)

Group: Forum Members
Posts: 1, Visits: 5
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. ?



ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)ComponentSpace Development (4.2K reputation)

Group: Administrators
Posts: 3.1K, Visits: 10K
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.

Regards
ComponentSpace Development
GO


Similar Topics


Execution: 0.000. 1 query. Compression Enabled.
Login
Existing Account
Email Address:


Password:


Social Logins

Select a Forum....












Forums, Documentation & Knowledge Base - ComponentSpace


Search