What
saml.doc_assertions reports method for every SubjectConfirmation it reads, and confirmation_ok in lua/resty/saml.lua never looks at it. Every method is treated as satisfiable once the Recipient and the time window hold.
Why it matters
The method states how the presenter is meant to prove they are the subject. urn:oasis:names:tc:SAML:2.0:cm:bearer asks for nothing beyond presentation, and it is the one this callback implements. holder-of-key asks for proof of a key and sender-vouches rests on an attesting party, and nothing here performs either. Accepting them claims work that never happened.
The practical impact is small for the deployments this library serves. An IdP configured for browser SSO issues bearer assertions only, and AudienceRestriction already refuses an assertion minted for whatever other service a holder-of-key flow serves.
It sits above zero because a holder-of-key assertion is built to be safe to leak: its security rests on the recipient checking the key, so it circulates with far less care than a bearer one. One reaching this callback under a matching audience is accepted today as though it were bearer.
Fix
Count a confirmation as satisfiable only when its Method is bearer. There is nothing extra to verify, since bearer means presentation is the proof, so the change only refuses the methods this code cannot honour. The alternative is dropping method from the reader, so that no unused field dangles for the next person auditing this.
Noticed on #42, which added the field. Left out of that PR to keep it to the scope of #37.
What
saml.doc_assertionsreportsmethodfor everySubjectConfirmationit reads, andconfirmation_okinlua/resty/saml.luanever looks at it. Every method is treated as satisfiable once theRecipientand the time window hold.Why it matters
The method states how the presenter is meant to prove they are the subject.
urn:oasis:names:tc:SAML:2.0:cm:bearerasks for nothing beyond presentation, and it is the one this callback implements.holder-of-keyasks for proof of a key andsender-vouchesrests on an attesting party, and nothing here performs either. Accepting them claims work that never happened.The practical impact is small for the deployments this library serves. An IdP configured for browser SSO issues bearer assertions only, and
AudienceRestrictionalready refuses an assertion minted for whatever other service a holder-of-key flow serves.It sits above zero because a holder-of-key assertion is built to be safe to leak: its security rests on the recipient checking the key, so it circulates with far less care than a bearer one. One reaching this callback under a matching audience is accepted today as though it were bearer.
Fix
Count a confirmation as satisfiable only when its
Methodis bearer. There is nothing extra to verify, since bearer means presentation is the proof, so the change only refuses the methods this code cannot honour. The alternative is droppingmethodfrom the reader, so that no unused field dangles for the next person auditing this.Noticed on #42, which added the field. Left out of that PR to keep it to the scope of #37.