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

There are a number of errors in these messages. Comments in line.

> Anne,
> very good, Thanks
> I may also add that assertions are only used once.

This is not correct. The two Web Browser Profiles require that SSO
assertions only be used by the first party to receive them, but this was to
attempt to limit the security risks associated with the rather weak security
mechanisms available. That is not the case in general and in particular is
not the case for the Web Services Profile.

SAML 2.0 may in fact define new profiles which eliminate this restriction
even in the browser case.


> Abbie
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Tuesday, September 30, 2003 9:50 AM
> > To: Champion, Mike; Cutler, Roger (RogerCutler); Sanjiva
> > Weerawarana; www-ws-arch@w3.org; www-ws-desc@w3.org
> > Subject: RE: IBM/MSFT whitepaper on secure, reliable,
> > transacted Web serv ices
> >
> >
> >
A good summary, but some details are not correct.

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

Actually SAML supports general-purpose Authorization information exchange.
Other security services (encryption, signatures, etc.) are outside its
scope, as is Authorization Policy (which XACML covers).

The way I usually describe this is to visualize the security space as a two
dimensional grid. Along one dimension are security services. These include
Authentication, Integrity, Confidentiality, Authorization, etc.  SAML lies
in the Authorization stripe.

Along the other dimension are security environments. Web services are one
security environment, as are CORBA, Database, Java, WWW, LDAP, Mainframe,
etc. Web services is a stripe in this dimension.

The cell where the two orthagonal stripes intersect is the WSS SAML Profile.
(I realize this conceptual view is oversimplified in several respects.) I
have attached a rather crude .ppt slide illustrating this viewpoint.

> 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.

More accurately, Assertions contain statements and there are (currently)
three statement types. Authentication (reports an authentication event),
Attribute (reports attributes of some subject, usually a user) and
Authorization Decision (reports the result of an Authorization Policy
evaluation, essentially permit or deny).

An SSO Assertion is a special case defined in the Browser Profiles which
contains one Authentication statement and zero or more Attribute Statements.

>(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.

In SAML they are called Authorities or Asserting Parties. You could say a
"Trusted Authority", but a trust authority is something else.


> > 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.

The three types of Authorities (currently) defined are Authentication
Authority, Attribute Authority and Policy Decision Point (PDP),
corresponding to the three statement types. A PEP is usually a client to a
PDP. There is no real process model, just three request response protocols,
one for each statement type.

Only one Binding has been defined - SOAP over HTTP(S). At the recent F2F the
question was raised if others should be done, e.g. directly over HTTP(S),
but there did not seem to be any interest.

> > 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.

More accurately, it defined a SOAP binding to issue requests and responses
over SOAP, with SAML assertions in the SOAP body, but it did not define a
SOAP Profile, defining how a SAML token could be used in the SOAP header as
a part of protecting the contents of that message, which was left to WSS.

> >
> > 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.

This is roughly correct, but it is the tokens which provide the keys and
attributes that are used by the signature and encryption mechanisms. There
are also some other miscellaneous mechanisms, such as timestamps and
security token references.

As it happens, WSS TC decided to call the per-Token documents Profiles,
which may have been a mistake, but is not going to change at this point.

> >
> > 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.

This is correct, except as noted above, that SAML's scope is limited to
Authorization information.

Hal