Implement Auth.get_last_response_in_response_to()

[guneskaan]

In an SP initiated flow, last_response_in_response_to() will give flexibility to the developers when performing validation of the SAML Response.

Currently process_response() takes in a single response id to compare with the InResponseTo value of the response. However, the current get_last_request_id function only returns the most recent ID, and this is not very helpful in these cases:

• User A starts SAML authentication process with a SAML request. Before User A completes authentication, User B starts an authentication process, but user A completes their authentication first, sending SAML Response back to the SP. Now, if we call get_last_request_id when processing the SAML Response, this will yield the ID of User B's SAML Request.
• To avoid the situation above, we might want to store request IDs, right after the request is sent, in a database. If we have a collection of request IDs, we cannot validate the InResponseTo id by passing only one of them to process_response(). By storing a collection of request IDs, we can also associate other information with the ID to perform additional validation and processing on the SAML Response (e.g the IP address of the User who made the request, expected user name, platform information)

Currently the Response model has a get_in_response_to() function, but this is not exposed to the Auth model. This PR allows developers to easily retrieve the InResponseTo from the last processed SAML Response.

[pitbulk]

User A starts SAML authentication process with a SAML request. Before User A completes authentication, User B starts an authentication process, but user A completes their authentication first, sending SAML Response back to the SP. Now, if we call get_last_request_id when processing the SAML Response, this will yield the ID of User B's SAML Request.

Why not store the request_id in a session before the redirection to the IdP, storing such data in a cookie, so later you can read the cookie value (that belong this specific user) and be able to provide it to the process_response method?

To avoid the situation above, we might want to store request IDs, right after the request is sent, in a database.

If you store request IDs, you only know what IDs were generated, but not what ID belongs to what user.

[guneskaan]

Why not store the request_id in a session before the redirection to the IdP, storing such data in a cookie I think this is a great idea, thank you. If you store request IDs, you only know what IDs were generated, but not what ID belongs to what user. I was thinking about a case where I know the user prior to SAML login, and I expect this user to be returned in the SAML Response. If I know the user at the time of the login request, then I can store the Request ID with the user information. An example to this situation would be an Active Directory user being requested to log in to a native windows application using an external Identity Provider (which verifies the user through the active directory API) that can enforce two-factor authentication - In this case the application would know which user is currently logged in to Windows through the Windows API, and expect the same user to be returned in SAML Response.

I know this is not a common case - but I believe adding this tool will be useful for implementations similar to this.