Re: SOAP 1.1 Protocol Binding

[Evan Prodromou <eprodromou@securant.com>]

>>>>> "OD" == Orchard, David <dorchard@jamcracker.com> writes:

    OD> If we don't have any rules for intermediaries and headers,
    OD> then I propose we preclude their use completely.  How can we
    OD> have interoperability if we don't have a clue how these things
    OD> will be used.

Well, I'm inclined to agree, but it may be possible that SOAP
libraries or platforms or processors or what-have-you add headers
without the knowledge or consent of SAML processing code. For example:

        <SOAP-ENV:envelope>
           <SOAP-ENV:header>
              <apache:soap-processor>
                Apache SOAP 0.5
              </apache:soap-processor>
           </SOAP-ENV:header>
           <SOAP-ENV:body>
              <SAMLQuery>
              <!-- ... -->

It might be too much of a burden to say that SAML-over-SOAP can't have
*any* headers whatsoever -- just that the headers have no SAML
meaning, and should be ignored.

    OD> I think people who want intermediaries are going to have to
    OD> propose what the processing model should be.

Agreed. I have some trepidation about the usefulness of intermediaries
for SAML queries, anyways. I think the big use of intermediaries will
probably be for assertions bound to a business payload.

    OD> SOAP 1.1 isn't clear on order of headers.  SOAP 1.2 may make
    OD> this

...yes? And? B-)

    OD> I think I agree with you, but SOAP faults can be used to carry
    OD> SAML errors.  It's just their aren't in the SOAP fault code
    OD> space.  Faults are exactly meant for application errors.

Ah, well, that's a good point. I guess I recall that same kind of
pattern from XML-RPC. A design principle I've tried to follow in the
HTTP and SOAP bindings is to decouple SAML messages as much as
possible from the bound protocol. For implementors, it'd be nice to be
able to do something like this:

        [SOAP receiver] ---------+
                                 |
        [HTTP receiver] ---------+
                                 |
        [BEEP receiver] ---------+------> SAML processor
                                 |
        [SMTP receiver] ---------+      
                                 |
        [... receiver] ----------+      

That is, I want to be able to have SAML data come in or go out through
any number of bound protocols and go to a SAML processor, without the
SAML processor needing to know much of anything about the protocol.

This generalism comes at a trade-off -- the protocol bindings won't
fit hand-in-glove with the bound protocol, or use any of the cool
features of that protocol. But a single SAML processor can present an
interface on any number of protocols with minor effort.

In my mind, that's part of the overall design strategy of having a
"SAML protocol" and then a number of "protocol bindings." Feel free to
shake me hard, people, if I've got that wrong.

    Me> Yikes! See, now, this is the kind of thing that I think is up
    Me> to the underlying protocol.

    OD> No way is it at the underlying protocol.  If there's any
    OD> routing through SAML entities, then the entities have to know
    OD> how to deal with the SAML headers.

OK, well, we probably need to decide if SAML has a routing model with
intermediaries involved at the "SAML protocol" level, or if this is
not really part of SAML.

~ESP

P.S. It's good to know somebody's reading this stuff.

-- 
Evan Prodromou, Senior Architect        eprodromou@securant.com
Securant Technologies, Inc.             415-856-9551