feat: allow request uuid to be stored

[Jamedjo]

What

Introduces a :store_request_uuid option for later comparison with InResponseTo

By default it saves the request uuid in the session as "saml_transaction_id",
but also accepts a proc that will then be called with the uuid for custom storage.

Why

Needed for #172, although we may also want to pass the value to ruby-saml with matches_request_id:.

[coveralls]

Coverage remained the same at 100.0% when pulling 8ac901c on Jamedjo:jej/allow-storing-request-uuid into 715cc44 on omniauth:master.

[Jamedjo]

@md5 @supernova32 Does this look ok?

[suprnova32]

@Jamedjo the code looks good. Are you using this already in your apps?

[alexrecuenco]

Was this ever solved in a different way? I see no updates here, and I was trying to do SP-initiated only log-in by looking at the InResponseTo, but I don't think that is currently possible, is it?

Is there any recommendation to avoid CSFR otherwise?

How do you recommend to go about this?

[alexrecuenco]

I just want to mention, if you are reading this 6+ years later, because you are using omniauth-saml and trying to do a SP flow by implementing a patch like this.

If you use SameSite Lax or Strict on your session cookies, which you probably should do, it won't work because the reply back is a POST request, so it doesn't have any session cookie.

Use a separate cookie/session [signed and/or encrypted] to store the session id, possibly using __Host- that has SameSite none, and perhaps with a name that contains the provider name and a short expiration time.

For further checks, read this comment that explains some other considerations with storing authenticated ids and validating if you see them re-used.
simplesamlphp/simplesamlphp#230 (comment)