- From: Anne Thomas Manes <anne@manes.net>
- Date: Tue, 30 Sep 2003 09:49:19 -0400
- 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 UTC