[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] SOAP 1.1 schema namespace processsing
The schema issue I was mentioning on the call today is basically due to something I ran into while trying to avoid use of a full SOAP implementation in the SOAP binding. I guess it seemed to me to be desirable to be able to parse an incoming SOAP envelope with SAML inside it and validate the whole thing in one gulp. The older Apache SOAP kit doesn't schema validate (except by hand), so it hands you the DOM tree from the body without any validation. The advantage to that is you don't have to worry about a mismatch between the schema namespace of your XML parser (likely 2001 now) and the schema namespace that may be specified in the SOAP envelope for some reason (declaring xsi being the most likely). My question, I guess, is whether or not any SOAP processors one might use to construct a SAML request are likely to embed xmlns:xsd or xmlns:xsi anywhere, possibly referencing 1999 (since that's SOAP 1.1's timeframe)? If not, my thought was to suggest a small addition to the SOAP binding that mandated *not* specifying an older schema namespace in the SOAP envelope that would collide with the newer one SAML validators would want to use. The upside is a slightly simpler binding implementation that doesn't lose either flexibility or performance by having to either code around the schema namespace issue or possibly revalidate the body after the SOAP processor spits it out. I know some people were sensitive to how complex the binding might be (eg. for SSO use only). Just a thought. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC