Raised on #41, and only became possible with the change in that PR.
What
idp_issuers gates the login callback. The logout callback reads an issuer too, at lua/resty/saml.lua:443, compares it against the one on the session and only warns:
if issuer ~= saved_issuer then
ngx.log(ngx.WARN, "issuer different: issuer=", issuer, ", data.issuer=", saved_issuer)
end
It then destroys the session whatever the outcome. So of the two paths where a message arrives from outside, the pin is enforced on one.
Why it is worth doing now rather than before
Until #41 a LogoutRequest could carry its identity in a message the signature never covered, so pinning its issuer would have compared text the sender typed. That PR makes such a message fail verification, so the value is now covered by the signature and a comparison against it means something.
Shape
Weigh the issuer of a logout message against idp_issuers the way the login callback does, and decide what the existing session comparison should be: a warning that precedes an unconditional sess:destroy() is either a check or it is not.
Impact is bounded either way, since the outcome is the caller's own session being destroyed. It matters more for anything downstream that consumes doc_name_id from a logout message to drive its own session store.
Raised on #41, and only became possible with the change in that PR.
What
idp_issuersgates the login callback. The logout callback reads an issuer too, atlua/resty/saml.lua:443, compares it against the one on the session and only warns:It then destroys the session whatever the outcome. So of the two paths where a message arrives from outside, the pin is enforced on one.
Why it is worth doing now rather than before
Until #41 a
LogoutRequestcould carry its identity in a message the signature never covered, so pinning its issuer would have compared text the sender typed. That PR makes such a message fail verification, so the value is now covered by the signature and a comparison against it means something.Shape
Weigh the issuer of a logout message against
idp_issuersthe way the login callback does, and decide what the existing session comparison should be: a warning that precedes an unconditionalsess:destroy()is either a check or it is not.Impact is bounded either way, since the outcome is the caller's own session being destroyed. It matters more for anything downstream that consumes
doc_name_idfrom a logout message to drive its own session store.