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.

For the purposes of this conceptual view, the exact stripes on the vertical
axis are not too important. As long as the parties using the visualization
can agree that they are distinct environments with their own security
requirments and technology choices, that is sufficient. For example, the
domains could be Chevron corp security, 3M corp security, Merck corp
security. Or they could be manufacturing division security, sales division
security, warehouse division security. Or they could be CORBA, J2EE, DCE,
etc. As an example, the existence of a WSS TC implies that many people
believe the WS Security is a distinct environment that can be distinguished
from other environments even though it shares technologies with other
environments and in spite of the fact that the boundaries may not be razor
sharp.

I have actually used this type of chart in consulting engagements with
clients as a tool to understand how to move their environments towards
increased use of standards and increased uniformity.

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

If this chart doesn't help you, so be it. The only I was trying to make was
that the scopes of SAML and WSS are orthogonal and they do intersect at one
point. Perhaps you already knew this, so the diagram added nothing.

Hal

>
> -----Original Message-----
> From: Hal Lockhart [mailto:hlockhar@bea.com]
> Sent: Tuesday, September 30, 2003 6:51 PM
> To: Abbie Barbir; Anne Thomas Manes; 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 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
>
>
>

Received on Wednesday, 1 October 2003 19:28:49 UTC