W3C home > Mailing lists > Public > www-ws-desc@w3.org > September 2003

RE: IBM/MSFT whitepaper on secure, reliable, transacted Web serv ices

From: Anne Thomas Manes <anne@manes.net>
Date: Tue, 30 Sep 2003 09:49:19 -0400
Message-Id: <5.2.1.1.0.20030930092731.0355eb08@localhost>
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>, Sanjiva Weerawarana <sanjiva@watson.ibm.com>, www-ws-arch@w3.org, www-ws-desc@w3.org

Mike's right. SAML and WS-* are very complementary. But let me give you a 
little more detail.

SAML supports general-purpose security. It is not focused only on Web 
services or SOAP. SAML defines three core capabilities:
1- how to represent security tokens in XML. These tokens are called 
assertions, and SAML defines three types of assertions -- authentication, 
authorization, and attributes. (attributes provide qualifying information 
that constrain the other assertions -- such as spending limits or timing 
contraints). An assertion is made by some type of trust authority. So for 
example, it says that the ChevronTexaco single sign-on service asserts that 
Roger Cutler passed a userid/password challenge at 9:00 AM on 9/30/03, and 
this assertion is good for 2 hours.
2- a process model for obtaining security tokens from a trust authority. 
This includes a set of protocols for accessing a trust authority. SAML 
defines two types of trust authorities: Policy Decision Points (PDPs) and 
Policy Enforcement Points (PEPs). SAML has defined bindings for multiple 
protocols, including SOAP/WSDL.
3- a set of protocol bindings for conveying SAML tokens. SAML 1.1 defines 
how to pass SAML tokens for browser applications. It does not define 
bindings for how to pass SAML tokens in SOAP messages -- it left that task 
to the WS-Security team.

WS-Security and the related specs focus on securing SOAP messaging. 
WS-Security defines two core capabilities:
1- how to use XML-Signature and XML-Encryption with SOAP messaging. It 
specifies how to pass signatures and key information in a SOAP header.
2- how to pass security tokens with a SOAP message. WS-Security supports a 
variety of security tokens (each defined by its own binding specification), 
such as userid/password, X.509 certificates, Kerberos tickets, and SAML tokens.

Regards,
Anne

At 06:54 PM 9/29/2003 -0400, Champion, Mike wrote:

>
>
> > -----Original Message-----
> > From: Cutler, Roger (RogerCutler)
> > [mailto:RogerCutler@chevrontexaco.com]
> > Sent: Monday, September 29, 2003 5:39 PM
> > To: Sanjiva Weerawarana; www-ws-arch@w3.org; www-ws-desc@w3.org
> > Subject: RE: IBM/MSFT whitepaper on secure, reliable,
> > transacted Web services
> >
> >
> > I know that this is a dumb question, but could you explain
> > how the WS-* specs relate to SAML?  Is the SAML functionality
> > in WS-* somewhere, so that the specs are incompatible?  Or
> > does WS-* operate in a different space and interact with SAML somehow?
>
>As best I understand it, WS-Security provides a framework for exchanging /
>negotiating security-related information, and SAML would describe one
>particular type of payload for WS-Security messages, i.e. those that make
>assertions about identity, authentication, authorization, etc.  They are
>definitely complementary, not competitive: WS-Security talks about SOAP
>headers and provides a generic security processing model; SAML doesn't know
>anything about SOAP but knows a lot more about the details of security
>semantics.
Received on Tuesday, 30 September 2003 09:49:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:26 GMT