How can we resolve issues with Replay attack, also how can we check the origin of the certificate.
We maintain a cache of assertion IDs and check for replay attacks. If a SAML assertion is replayed an exception is thrown.
Do you mean the certificate embedded in the XML signature? This certificate is useful for debugging purposes but we don’t recommend using it for the actual signature verification. Instead, a separately configured certificate that you can trust should be used.
[quote][/quote]
We maintain a cache of assertion IDs and check for replay attacks. If a SAML assertion is replayed an exception is thrown.
Do you mean the certificate embedded in the XML signature? This certificate is useful for debugging purposes but we don't recommend using it for the actual signature verification. Instead, a separately configured certificate that you can trust should be used.
Do you mean the certificate embedded in the XML signature? This certificate is useful for debugging purposes but we don't recommend using it for the actual signature verification. Instead, a separately configured certificate that you can trust should be used.
Thank You for you prompt response, I will explore storing assertion ID's option.
Also I need suggestions on how to verify the signature in the certificate before authenticating user.
You don’t have to store assertion IDs. This is done automatically and the check for replay attacks is made when you call SAMLServiceProvider.ReceiveSSO.
SAMLServiceProvider.ReceiveSSO also checks the XML signature of the SAML assertion or response. You don’t have to do anything to make this happen other than supply a partner certificate in your SAML configuration (eg saml.config) as documented in our Configuration Guide and Certificate Guide and demonstrated by our ExampleServiceProvider project.