What
The condition readers match on element name. SAML allows the same condition to be spelled through the generic element, <saml:Condition xsi:type="saml:OneTimeUseType"/>, and ConditionsType in the bundled XSD admits it. That spelling lands in unknown_condition and is refused, for AudienceRestriction, ProxyRestriction and OneTimeUse alike. TEST 13 pins this on purpose with xsi:type="saml:AudienceRestrictionType" as its unrecognised case.
Since #53 the XSD leaves Condition as the only element that can reach unknown_condition, so the refusal always reads carries a condition this SP cannot satisfy: Condition, whatever xsi:type it carried.
Why it is not in #53
Refusing is fail-closed and in spec: Core 2.5.1.1 rule 3 makes a condition the SP does not recognise Indeterminate. Accepting the spelling means resolving xsi:type in C for every reader at once; an xsi:type AudienceRestriction accepted as known with its audiences unread would be a bypass. No browser-SSO IdP writes this spelling.
The asymmetry is new
Before #53 both spellings produced the same 401, so behaviour across serializers was at least uniform. #53 promotes the element spelling to accepted while this one stays refused, so an IdP that switches serializers flips from working logins to a hard 401 for every user. #53 also makes Condition the only element that can reach the refusal, which is what reduced the message to a fixed string.
What to do
- Append the
xsi:type value to the refusal message, so the one case the log can fire in names the type.
- Decide whether to accept the spelling for the three spec conditions. If yes, resolve
xsi:type once and feed every reader from it.
Raised by @jarvis9443 reviewing #53.
What
The condition readers match on element name. SAML allows the same condition to be spelled through the generic element,
<saml:Condition xsi:type="saml:OneTimeUseType"/>, andConditionsTypein the bundled XSD admits it. That spelling lands inunknown_conditionand is refused, forAudienceRestriction,ProxyRestrictionandOneTimeUsealike. TEST 13 pins this on purpose withxsi:type="saml:AudienceRestrictionType"as its unrecognised case.Since #53 the XSD leaves
Conditionas the only element that can reachunknown_condition, so the refusal always readscarries a condition this SP cannot satisfy: Condition, whateverxsi:typeit carried.Why it is not in #53
Refusing is fail-closed and in spec: Core 2.5.1.1 rule 3 makes a condition the SP does not recognise Indeterminate. Accepting the spelling means resolving
xsi:typein C for every reader at once; anxsi:typeAudienceRestrictionaccepted as known with its audiences unread would be a bypass. No browser-SSO IdP writes this spelling.The asymmetry is new
Before #53 both spellings produced the same 401, so behaviour across serializers was at least uniform. #53 promotes the element spelling to accepted while this one stays refused, so an IdP that switches serializers flips from working logins to a hard 401 for every user. #53 also makes
Conditionthe only element that can reach the refusal, which is what reduced the message to a fixed string.What to do
xsi:typevalue to the refusal message, so the one case the log can fire in names the type.xsi:typeonce and feed every reader from it.Raised by @jarvis9443 reviewing #53.