Re: [security-services]

[Sai Allavarpu <sai.allavarpu@sun.com>]

Please see my comments inline below.

----- Original Message -----
From: "Mishra, Prateek" <pmishra@netegrity.com>
To: "'sai.allavarpu@sun.com'" <sai.allavarpu@Sun.COM>; "'eve.maler@sun.com'"
<eve.maler@Sun.COM>; "'Simon Godik'" <sgodik@crosslogix.com>
Cc: <security-services@lists.oasis-open.org>
Sent: Tuesday, November 20, 2001 3:13 PM
Subject: [security-services]


| 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.

Can you provide more clarification? It seems SOAP is mandatory to implement
but not mandatory to deploy. So from a customer standpoint, why would the
customer care what is implemented internally if they don't want to use SOAP?
Customers care about the outward functions. As you say, they can ignore it.
If so, why is SOAP even a requirement for SAML? A vendor can implement
everything in SAML except SOAP bindings, and the vendor's customer can
deploy that implementation. How is this different from a customer deploying
a SAML implementation that supports SOAP but is turned off?

BTW, what is the mechanism to turn off SOAP?

Also, to ensure interoperability between different vendor implementations,
don't we have to have a standardized way to first authenticate each
implementation to the other, have some negotiation (and possibly trust)
setup between them, before exchanging SAML assertions, queries and
responses?

| 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.

This exactly is the issue with security-conscious segment. The current crop
of firewalls aren't mature enough to handle or filter SOAP payload content
treating it as raw HTTP; and that is perceived as a security threat. Some
existing deployments actually have SOAP traffic completely blocked for lack
of better filtering support in firewalls.

| >>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.

Couldn't agree more. This is very strategic to the wide adoption of SAML,
especially the HTTP binding and socket bindings; this will be the "bridge"
to the existing non-HTTP applications and also act as a transition while
majority of the deployments move over to SOAP when the SOAP tools are more
robust and mature (and have better performance).

|
| - prateek
|
|
|
|
| ----------------------------------------------------------------
| To subscribe or unsubscribe from this elist use the subscription
| manager: <http://lists.oasis-open.org/ob/adm.pl>
|