Consider the steps involved in WS-Federation Passive Requestor Profile1:

The above figure shows a sequence diagram of a user (requestor) accessing a web application with his browser. Since the user was not authentication due to a recent session, the application redirects the user to the IDP for a user login (1). The IDP collects the credentials from the user and uses a Security Token Service (STS) to validate the credentials and also to get a SAML token from the STS (2). The STS itself is connected to a LDAP data store to validate the user credentials and also to retrieve additional information (claims) about the user, e.g. roles. On successful authentication (3) the IDP returns the SAML token issued by the STS (4) to the user and advices (auto-submitting form) the user to send this SAML token to the originally requested web application (5). The IDP takes care of providing a web user interface and handling URL redirects, whereas the STS is responsible for generating SAML Token and validating of user credentials. The web application validates the SAML token (6) and on success returns the desired web page (7).

In step 4, we can return a form to the user that automatically submits itself. Does this form require any CSRF protection on it?

I am looking for confirmation, but I think the answer is "no". Even if a malicious website could cause a user to POST this form, it would also have to successfully forge a security token.


  1. http://janbernhardt.blogspot.com/2014/12/understanding-ws-federation-passive.html

1 Answer 1


CSRF requires the client to have a token that is submitted passively, e.g. a cookie. The attack, also known as "session riding," forges a request that takes advantage of passively-submitted tokens-- the forged request "rides" on a legitimate session that is already established.

In step 4, the browser doesn't have SAML token quite yet, so CSRF mitigation is not necessary.

Step 6 might require a CSRF mitigation, but only if it has some effect, e.g. changing a password, transferring money, etc. If its only purpose is to retrieve a web page for display purposes, CSRF mitigation is not needed. (The goal of a CSRF attack is to issue a command, not eavesdropping.)

Presumably there may be steps 8, 9, 10, etc. where the user can actually have an effect on something. Those sorts of transactions would require CSRF mitigation.

On a side note, step 0 does require a mitigation against session fixation.

  • CSRF mitigation is only required when an action is taken and the client can passively submit credentials (aka cookies or BASIC authentication). It's not obvious from the question if both of those requirements are met. I suspect they aren't, in which case CSRF mitigation is not required at all. However, your answer is a bit confusing when discussing step 6. Regardless of whether or not an action is taken, CSRF mitigation is not required if the token is not passively submitted. Commented Dec 11, 2017 at 13:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .