OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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