RE: [security-services] SOAP Profile of SAML vs WS-Security: Summ aryand an Action Plan

["Ahmed, Zahid" <zahid.ahmed@commerceone.com>]

Title: RE: [security-services] SOAP Profile of SAML vs WS-Security: Summary and an Action Plan

Yes, it is important that SAML Binding and perhaps even
SAML Data Model factor in the Microsoft GXA's WS-Security
and WS-License specifications.

I had originally pointed to the bindings group that WS-Security
needs to be evaluated on Oct. 24, 2001. See:

http://lists.oasis-open.org/archives/security-bindings/200110/msg00023.html

I believe I had also discussed this at the bindings discusison
at F2F#5 meeting on Nov. 14th in San Francisco w.r.t. supporting
an interoperatable authentication data exhanges with Microsoft GXA
Web Services that may be WS-Security aware.

So, I am pleased to see that finally this is becoming of interest
to the WG w.r.t. SOAP Binding:

>We need to review the current contents of the SOAP profile in
>light of the WS-Security and WS-License proposals. One possible
>outcome would be to build the SOAP profile as an instance of
>WS-Security and expose SAML assertions as a specific instance of
>the credential notion described in WS-License. However,
>all of this will take some time and considerable discussion.

I have reviewed WS-Security in some detail and I agree that
current SOAP Profile is compatible with WS-Security since
we are assuming underlying envelope to be SOAP 1.1. However,
I suggest the following set of options that we need to
discuss:

1. Since the currennt WS-Security encapsulates authentication
data into the Credential element defined in a generic way as:

  <xsd:element name="credentials">
    <xsd:annotation>
      <xsd:documentation>
                This element defines the WS-Security credentials header.
                It's purpose is to encapsulate credentials that
                are agreed to between the SOAP producer and consumer.
                    Credentials have additional properties which are defined
                    in the WS-Security specification located at:
                  http://msdn.microsoft.com/ws/2001/10/Security/. 
                    This header is designed to allow all valid SOAP attributes
                    as well as other namespace qualified attributes that
                    are appropriate in the context that this is being used
                   within.
       </xsd:documentation>
    </xsd:annotation>
    <xsd:complexType>
      <xsd:sequence>
        <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:anyAttribute namespace="##other" processContents="lax"/>
    </xsd:complexType>
  </xsd:element>

WS-Security potentially allows SAM enabled appliations to use
any defintion of Credentials. The problem is that SAML WG threw
out Credential from its object model. Instead what we now have
is thje definition of Subject element. We have done some mappings
here at Commerce One between WS-Security Credentials and SAML's
Subject. Sematically, WS-Security Credential can be bridged/integrated
with Subject.

2. Exploiting WS-Security Credential "any namespace"
If we decide to integrated SAML components (such Sibject) with
WS-Security's (see: ws-security.xsd) Credential via "any namespace"
option, there is going to be one drawback for non-SAML compliant,
GXA-enabled .NET applications which is that the .NET app would need to maintain the SAML schema locally to process the Credentials of SAML

flavor unless we include the target namespaces for SAML in the
WS-Security "bindings".

3. Using Subject Type directly w/WS-Security
Directly integrating SAML components w/WS-Security Credential
There is also another option we have to fit in the current SOAP
Binding with WS-Security and WS-License. We don't extend
WS-Security Credential. Instead we propose a direction application
of SAML Subject and Assertions into WS-Security Credential and other
license objects. This option potentially implies providing not
only a SOAP Binding for SAML, but also a WS-Security Binding for
SAML.

4. SAML Extensions of WS-Security/License Abstract Models
We also need to explore the Abstract Credential and Abstract
License model (defined as part of ws-license.xsd), and how
it relates with SAML Object Model. I can provide feedback on
that too.

Finally, I think we should include the above WS-Security
considerations in our Issues List so that it can be tracked.

I have concrete propsoal for some of the above options, whenever
we are ready to talk about it further.

thanks,
Zahid
 

 

 

-----Original Message-----
From: Mishra, Prateek [mailto:pmishra@netegrity.com]
Sent: Monday, January 21, 2002 11:24 AM
To: security-services@lists.oasis-open.org
Subject: [security-services] SOAP Profile of SAML vs WS-Security:
Summary and an Action Plan

SOAP Profile of SAML vs WS-Security
-------------------------------------------------
 
The SOAP profile of SAML (Section 4.2, bindings-09) describes the secure
attachment
of SAML assertions to SOAP messages. The main idea here is that SAML
assertions may be placed within the SOAP envelope and XML-DSIG may be used
to ensure the secure attachment of assertions to a specific payload.
 
In October 23, 2001, a family of specifications concerned with SOAP
messaging were
published on MSDN. Of these, two are of particular interest to the SAML
community:
 
WS-Security
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsrvspec/h
tml/ws-security.asp
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsrvspec/
html/ws-security.asp>
 
WS-License
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/
html/wslicspecindex.asp
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec
/html/wslicspecindex.asp>
 
WS-Security is concerned with several different security topics (e.g.,
encryption) but two components are relevant to the SAML SOAP Profile.
 
*       The Credentials section discusses a mechanism for associating
security information, such as Kerberos tickets, with a message.
*       The Integrity section discusses how to use XML-Signature
[XML-Signature]
<http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-security.asp?fra
me=true#ws-security_xml-signature>  to ensure that SOAP messages are not
tampered with during message transmission.
 
A general construction is given for attaching a "credential" to a SOAP
message. Use of an "integrity header" (utilizing XML-DSIG) is described to
ensure message integrity.
 
WS-License describes XML elements that can be used to express several
different types of credentials: X.509 certificates, Kerberos tickets and
arbitrary binary blobs.
 
CONCLUSION:
-------------------
The proposals in WS-Security and WS-License are clearly relevant to the SAML
SOAP
Profile. They do not in any way make the contents of the SOAP profile
redundant; on
the contrary, by proposing "infrastructure" for the inclusion of generic
"credentials" in
SOAP messages they highlight the importance of the SAML SOAP Profile in XML
messaging.
 
We need to review the current contents of the SOAP profile in light of the
WS-Security and
WS-License proposals. One possible outcome would be to build the SOAP
profile as an instance of WS-Security and expose SAML assertions as a
specific instance of the credential notion described in WS-License. However,
all of this will take some time and considerable discussion.
 
I would therefore propose the removal of the materials on the SOAP profile
from the current bindings draft. These materials, together, with the
WS-Security and WS-License proposals, would be used as the basis for a new
draft SOAP profile document. The TC would review this information and submit
a SOAP profile to OASIS in the near future (Q2/02). 
 
NOTE:
--------
For reasons unknown to me, the above links do not always correctly lead to
the two specifications. An alternative path is to view the table of contents
displayed on the
LHS frame and directly access the specifications from the TOC.
   

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