[security-conform] FW: Feedback on the SAML conformance documents,from Sal Allavarp u

[Robert Griffin <Robert.Griffin@entrust.com>]

hi Sal -

 

thanks for the comments!  i'm figuring to have a call in the week after Thanksgiving, and would be interested to discuss them in more detail then.

 

regards,

 

bob

 

-----Original Message-----
From: Sai Allavarpu [mailto:sai.allavarpu@sun.com]
Sent: Tuesday, November 13, 2001 6:21 PM
To: eve.maler@sun.com; Robert.Griffin@entrust.com; joe_pato@hp.com
Subject: Fw: Feedback on the SAML conformance documents

I am not authorized to send an email to security-conform alias. Can you forward this on my behalf to the sub-committee members?

 

Thanks,

Sai.

----- Original Message -----

From: Sai Allavarpu

To: security-conform@lists.oasis-open.org ; Sai Allavarpu

Cc: Aravind Ranganathan

Sent: Tuesday, November 13, 2001 3:14 PM

Subject: Feedback on the SAML conformance documents

I have to appreciate the SAML conformance documents and the dual approach taken toward them. The approach where the conformance is determined by a questionnaire is more useful to both the vendors and the market to understand what it means to claim SAML conformance at various levels.

 

After having discussed this in the market and with customers, I have some feedback to share on the SAML compliance doc.

 

First, the market is clearly excited about the SAML standard, especially the standardized schemas (data formats) for all the 3 global types of assertions and the standardized request/response formats/schemas. The major refrain from the market is that they want to ensure SAML is widely adopted by different vendors and the industry. Toward this ultimate goal of wide adoption, they want to ensure that SAML conformance specs are not only simple and specific but also reflective of the existing market deployments. SAML should not be a "discontinuous" or a "disruptive" change to deployments; SAML should help past and current deployments get to the future desired deployments of web services and SOAP.

1. The conformance model should be based on (A) multiple dimensions and (B) multiple levels of conformance within each dimension. The idea of a supplier and a consumer is one dimension. But other dimensions that the market cares about are (in the increasing order of conformance)
   • conforming to the data format/schema of assertions (authentication/authorization/attribute)
   • conforming to the data format/schema of the SAML request/response (authentication/authorization/attribute)
   • conforming to the SAML bindings (SOAP, HTTP, Socket, etc)
2. Within each of the above dimensions, there can be levels of compliance. For instance, some one who wants to be the Authentication authority but not the attribute authority should be able to claim conformance to the AA assertions and request/response schemas.
3. 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.
4. 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.
5. 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?
6. 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.

Sai.