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

I do not understand the vertical axis of your visualization.  It seems
to put proprietary environments on the same footing as standards-based,
interoperable ones.  This is not, in my view, a very useful view of the
world.  However, if you really want to pursue this sort of analysis, I
think you'd probably better put .Net on the vertical axis.  You may not
like it, but .Net is a major player in that space.

Moreover ... It is by no means clear to me that the cells in your matrix
are really distinct.  Or even "reasonably distinct".  To think of them
as being distinct would seem to me to imply that various proprietary
technologies, like Java, .Net and the various database systems that we
know and (sort of) love, cannot connect to the same capabilities or to
each other -- or to the interoperable standards.  That doesn't make a
lot of sense to me.  Maybe that just means that I don't understand your
visualization very well -- but then I started out by saying that I
didn't find it very helpful.

-----Original Message-----
From: Hal Lockhart [] 
Sent: Tuesday, September 30, 2003 6:51 PM
To: Abbie Barbir; Anne Thomas Manes; Champion, Mike; Cutler, Roger
(RogerCutler); Sanjiva Weerawarana;;
Subject: 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 []
> > Sent: Tuesday, September 30, 2003 9:50 AM
> > To: Champion, Mike; Cutler, Roger (RogerCutler); Sanjiva 
> > Weerawarana;;
> > 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

> 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

>(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) 
> > > > []
> > > > Sent: Monday, September 29, 2003 5:39 PM
> > > > To: Sanjiva Weerawarana;;
> > > > 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.


Received on Wednesday, 1 October 2003 00:39:35 UTC