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

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:]

Sent: Monday, January 21, 2002 11:24 AM

To: 

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>