4 ms·

There's a reason for that. The attribute statement / attribute name / attribute value style has a consistent schema that won't change despite any custom attribu

There's a reason for that. The attribute statement / attribute name / attribute value style has a consistent schema that won't change despite any custom attributes that are being added. Your "claims" example does not have a consistent schema; it changes when new claims are added, and therefore makes it impossible to validate the response (the notion of arbitrary objects does not exist in XML schemas).

hvidgaard 5y ago
Surely there are better ways to do that, if it is even needed. If your validation only validates that you have > attribute statement / attribute name / attribute value style Does that even have a benefit? Is it any different that simply validating that a string is valid xml/json/something syntax?
jiggawatts 5y ago
Typically this would be implemented by having a set of predefined elements in the XSD (name, email, etc...) and also an 'additional' element that has a list of "Any" as the children. Easy! E.g.: <claims> <nameid>foo.bar@test.com</nameid> <givenname>Foo</givenname> <surname>Bar</surname> <extensions> <myCustomClaim>010231239dfadsf</myCustomClaim> </extensions> </claims> It's also possible to use namespaces for extensibility, and this can even be used to guarantee that the tag names don't conflict. So instead of this garbage: <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef> You'd have standard namespaced and extensible elements such as: <claims xmlns:saml="urn:oasis:names:tc:SAML:2.0:ac:classes" xmlns:adfs="urn:com:microsoft:ADFS"> <saml:nameid>foo.bar@test.com</saml:nameid> <saml:givenname>Foo</saml:givenname> <saml:surname>Bar</saml:surname> <adfs:securityId>S-0-1-52534-12362341234-12312315</adfs:securityId> <adfs:objectGuid>47e3a2d3-266a-48ad-b080-b785b4d0b45f</adfs:objectGuid> </claims> This would enable clients to validate the claims they do understand and ignore the claims they don't. Similarly to how X.509 does it, elements could be added to "must process" or "optional" parent elements to ensure correctness and security even in the face of a wide range of client capabilities. This is common in the XML world, but SAML had to invent its own wheels.

hvidgaard 5y ago

Surely there are better ways to do that, if it is even needed. If your validation only validates that you have > attribute statement / attribute name / attribute value style Does that even have a benefit? Is it any different that simply validating that a string is valid xml/json/something syntax?

jiggawatts 5y ago

Typically this would be implemented by having a set of predefined elements in the XSD (name, email, etc...) and also an 'additional' element that has a list of "Any" as the children. Easy! E.g.: <claims> <nameid>foo.bar@test.com</nameid> <givenname>Foo</givenname> <surname>Bar</surname> <extensions> <myCustomClaim>010231239dfadsf</myCustomClaim> </extensions> </claims> It's also possible to use namespaces for extensibility, and this can even be used to guarantee that the tag names don't conflict. So instead of this garbage: <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef> You'd have standard namespaced and extensible elements such as: <claims xmlns:saml="urn:oasis:names:tc:SAML:2.0:ac:classes" xmlns:adfs="urn:com:microsoft:ADFS"> <saml:nameid>foo.bar@test.com</saml:nameid> <saml:givenname>Foo</saml:givenname> <saml:surname>Bar</saml:surname> <adfs:securityId>S-0-1-52534-12362341234-12312315</adfs:securityId> <adfs:objectGuid>47e3a2d3-266a-48ad-b080-b785b4d0b45f</adfs:objectGuid> </claims> This would enable clients to validate the claims they do understand and ignore the claims they don't. Similarly to how X.509 does it, elements could be added to "must process" or "optional" parent elements to ensure correctness and security even in the face of a wide range of client capabilities. This is common in the XML world, but SAML had to invent its own wheels.