[security-services]

["Mishra, Prateek" <pmishra@netegrity.com>]

Eve Maler pointed me to this message on the conformance
sub-group.
 
http://lists.oasis-open.org/archives/security-conform/200111/msg00006.html
<http://lists.oasis-open.org/archives/security-conform/200111/msg00006.html>

 
I am sending my responses to the general list as it seems
to me the message raises questions beyond those
of conformance.
 
>>By mandating one baseline binding, are we implying that all users of SAML
will have to support it in
>>addition to any other bindings they care about, or is it only a matter of
picking a single binding to work 
>> on in the V1.0 timeframe?  What will be the timeframe/mechanism for
documenting other bindings, even if 
>> they're not "blessed" by the TC yet?  Our original plan  was to
eventually offer multiple bindings; using 
>> SAML across domains should be a matter of picking a common (and
standardized) binding. Conformance 
>> in this area should be a "set of binding protocols" to choose from and
let the parties in SAML transactions
 >>negotiate the binding by picking one from the "set of binding protocols".
This should be something similar 
>> to the cipher negotiations that happen in SSL connections, for example. 
 
The current situation is that the TC has agreed to use SAML over SOAP/HTTP
as a mandatory-to-implement
binding. This means that every vendor should provide such a binding as part
of their SAML implementation and in this way inter-operability between
different vendors is guaranteed. Notice that this is NOT
mandatory-to-deploy --- if you dont want to use it, you can simply ignore
it. 
 
Further, vendors are free
to implement other bindings (SAML over HTTP, SAML over TCP/IP, SAML over
RMI). We are in
the process of creating some infra-structure at the SSTC so that vendors (or
even better a group of vendors) can publish a specification describing a
profile or binding
at the SSTC.  This type of "informational" or "Experimental" draft would not
have the status
of a standard but would be based on standards. As an open published document
it would
have a somewhat different status from a purely proprietary document. 
 
>>The market is gung-ho about SOAP and web services but do NOT want to
deploy them right away 
>>because they perceive SOAP as a "discontinuous change" or a "disruptive
technology" despite the base 
>>HTTP layer over which most SOAP implementations are implemented. So if
HTTP binding is not one of the 
>>"set of binding protocols", then SAML will hurting its chances of quickly
and widely being adopted by the 
>>market, and will be left out of tons of markets. Customers are concerned
about deploying SOAP because 
>>of immaturity of its firewall technology and SOAP, inadequate skilled
system administrators to configure 
>>and manage SOAP traffic, relatively new support in the leading application
servers, SOAP standardization 
>>and evolution, etc. 
 
I am a little puzzled by this. Whether using SAML over SOAP/HTTP or plain
HTTP, admins have to
open a single HTTP port. Is there really a sharp distinction between the
two? 
Our use of SOAP is extremely modest: all we are doing is wrapping
SAML in a SOAP body and taking advantage of standard SOAP error codes and
header structure.

It can be implemented by the doPOST method servlet in any servlet container;
the servlet
would use an XML parser to extract the SAML body from the SOAP message and
forward it to
the SAML processor. If it unable to extract the SAML body then some SOAP
error is
returned. Maybe this isn't the "correct" way of implementing SAML over
SOAP/HTTP
but it certainly gets the job done. 
 
I will make some more enquiries locally (Simon, can you also check with your
people?) about this
issue. In any case, if there is a concern that we really, really need a
separate HTTP binding 
we can pick up the materials from binding-05 and publish it as a separate
draft. Of course,
some volunteers are needed to take this forward (hint, hint...)
 
>>SAML in non-web scenarios is also severely hampered because of lack of
bindings such as Socket 
>>bindings, for example. For example, what about using SAML in Netware/Lotus
Notes SSO? How to bridge 
>>the existing non-web applications with web apps and SAML? 
 
As above. The group of interested vendors should publish a draft of an
appropriate binding
such as, for example, SAML over TCP/IP.
 
 
>>If we had to pick the next few bindings that should be worked on, they
should be HTTP and sockets.  If the 
>>HTTP binding is nearly there, we should publish it as a draft anyway, so
people can get started with 
>>it. This will get the industry on SAML lot quicker, easier and sooner. A
socket binding would be even 
>>simpler, since it doesn't have to worry about SAML information that would
go into a header.
 
Agreed, if there is interest in bindings other than SAML over SOAP/HTTP, we
should definitely
publish drafts describing these bindings.
 
 
- prateek