Closed guneskaan closed 2 years ago
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.
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.
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 theInResponseTo
value of the response. However, the currentget_last_request_id
function only returns the most recent ID, and this is not very helpful in these cases:get_last_request_id
when processing the SAML Response, this will yield the ID of User B's SAML Request.InResponseTo
id by passing only one of them toprocess_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 aget_in_response_to()
function, but this is not exposed to theAuth
model. This PR allows developers to easily retrieve theInResponseTo
from the last processed SAML Response.