RE: [security-services] SOAP Profile of SAML vs WS-Security: Summ aryand an Action Plan

["Ahmed, Zahid" <zahid.ahmed@commerceone.com>]

Hal -
 
All three use cases below are important w.r.t. B2B apps. 
 
You can add to the mixture ebXML and UDDI also, both based on 
SOAP messsage packaging.
 
I agree that we can model a credential with an appropriate attribute schema.
It is unfortunate that users of SAML need to go about defining a Credential
via SAML attribute assertion. Furthermore, I agree that protection of
verification data in such "attribute oriented" credential assertions would
need to be application dependent meaning that interoperability of
Credentials will be questionable. We lack a standard in this area
although I think we did have a good starting point in S2ML in this 
area.
 
SAML 1.0's lack of standardized Credentials is one area that 
ws-security has attempted to address. I agree that Microsoft's GXA
does not address the semantic processing requirements of Credentials.
But in some ways thay have taken the first step in specifying a
flexible model of associating Credentials in SOAP messages. They
also claim that such procesing of security extensions in application
dependent which is correct design goal for SOAP messaging
systems, IMO. Authentication protocols was an area that
ws-security has prudently not included in their specs via their
design goal of application level security.
 
I think we may get some questions of why SAML 1.0 lacks this
capability as part of 1.0 acceptance. Post 1.0 we will have to fix
this in SAML.
 
regards,
Zahid
 
 
 
 
 
 
 
-----Original Message-----
>From: Hal Lockhart [ mailto:hal.lockhart@entegrity.com
<mailto:hal.lockhart@entegrity.com> ]
>Sent: Thursday, February 07, 2002 2:18 PM
>To: 'Ahmed, Zahid'
>Subject: RE: Missing Credential Feature in SAML vs Credential Definition a
nmd Extensibility in WS-Security/WS-License 
....

 
> I am not sure from your message whether you are trying to do #1, #2 or # 3
below, but if it is #2, I don't think it >would be to difficult to define an
appropriate schema.
 

-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
Sent: Thursday, February 07, 2002 9:41 AM
To: 'Krishna Sankar'; Mishra, Prateek;
security-services@lists.oasis-open.org
Subject: RE: [security-services] SOAP Profile of SAML vs WS-Security: Summ
ary and an Action Plan



I have been meaning to comment on this for some time. 

First let me note that the SAML definition of credential is different from
the one (implied) in the Microsoft documents. I will use the more general
(MS) one in this email.

Second note that the MS specifications do not define any semantics for
credentails at all, just some syntax. IMO this is an error and has led to no
end of confusion, (but full employment for consultants) in the past.

There are (at least) 3 reasons for sending credentials: 

1. To allow a RP to confirm the association between the Subject of an
assertion and some party to a network interaction, such as the orginator of
a request.

2. To enable access to some legacy (back-end) system by means of these
credentials. (In this context, legacy means a system that does not
understand the specification in question, e.g. SAML or WS-Security).

3. To implement a proxy login or pass-thru login service, which allows the
party collecting authentication evidence to be separate from the party
actually determining if authentication has succeeded or failed.

SAML currently provides for #1 by means of the SubjectConfirmation element. 

SAML can provide for #2 by means of an assertion containing an attribute
statement where credentials are an attribute. All that is required is the
definition of an appropriate attribute schema. Of course, there are a number
of security considerations, not the least being thta SAML does not currently
specify the use of XML encryption, but it is arguable that this is an
inherently insecure use case anyway.

SAML split out the work on #3 last year. This was what was expected to
define the SAML Credentials Assertion. 

Since MS does not specify semantics, there is no way to be sure what use
they intend. However, the context of their proposal to insert this
information in a SOAP header and the fact that they single out what they
call a license, makes me suspect that it is case #1 they have in mind.

I see no evidence in these documents that they wish to support #3. 

Hal 

> -----Original Message----- 
> From: Krishna Sankar [ mailto:ksankar@cisco.com <mailto:ksankar@cisco.com>
] 
> Sent: Monday, January 21, 2002 2:38 PM 
> To: Mishra, Prateek; security-services@lists.oasis-open.org 
> Subject: RE: [security-services] SOAP Profile of SAML vs WS-Security: 
> Summary and an Action Plan 
> 
> 
> Hi all, 
> 
>       If we are discussing this, we also should explore 
> possibilities of the 
> Credential Assertion (which the WS-XXX specifications define) 
> as part of 
> SAML. The four specs are tied together in some ways, so we 
> might have to 
> deal with *all* of them. 
> 
> cheers 
> 
>  | -----Original Message----- 
>  | From: Mishra, Prateek [ mailto:pmishra@netegrity.com
<mailto:pmishra@netegrity.com> ] 
>  | Sent: Monday, January 21, 2002 11:24 AM 
>  | To: security-services@lists.oasis-open.org 
>  | Subject: [security-services] SOAP Profile of SAML vs WS-Security: 
>  | Summary and an Action Plan 
>  | 
>  | 
>  | SOAP Profile of SAML vs WS-Security 
>  | ------------------------------------------------- 
>  | 
>  | The SOAP profile of SAML (Section 4.2, bindings-09) 
> describes the secure 
>  | attachment 
>  | of SAML assertions to SOAP messages. The main idea here is 
> that SAML 
>  | assertions may be placed within the SOAP envelope and XML-DSIG 
>  | may be used 
>  | to ensure the secure attachment of assertions to a 
> specific payload. 
>  | 
>  | In October 23, 2001, a family of specifications concerned with SOAP 
>  | messaging were 
>  | published on MSDN. Of these, two are of particular 
> interest to the SAML 
>  | community: 
>  | 
>  | WS-Security 
>  | http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/>  
>  | dnsrvspec/h 
>  | tml/ws-security.asp 
>  | < http://msdn.microsoft.com/library/default.asp?url=/library/en-us
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us>  
>  | /dnsrvspec/ 
>  | html/ws-security.asp> 
>  | 
>  | WS-License 
>  | http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/>  
>  | dnglobspec/ 
>  | html/wslicspecindex.asp 
>  | < http://msdn.microsoft.com/library/default.asp?url=/library/en-us
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us>  
> /dnglobspec 
> /html/wslicspecindex.asp> 
> 
> WS-Security is concerned with several different security topics (e.g., 
> encryption) but two components are relevant to the SAML SOAP Profile. 
> 
> *     The Credentials section discusses a mechanism for associating 
> security information, such as Kerberos tickets, with a message. 
> *     The Integrity section discusses how to use XML-Signature 
> [XML-Signature] 
> < http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-se
<http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-se>  
curity.asp?fra 
me=true#ws-security_xml-signature>  to ensure that SOAP messages are not 
tampered with during message transmission. 

A general construction is given for attaching a "credential" to a SOAP 
message. Use of an "integrity header" (utilizing XML-DSIG) is described to 
ensure message integrity. 

WS-License describes XML elements that can be used to express several 
different types of credentials: X.509 certificates, Kerberos tickets and 
arbitrary binary blobs. 

CONCLUSION: 
------------------- 
The proposals in WS-Security and WS-License are clearly relevant to the SAML

SOAP 
Profile. They do not in any way make the contents of the SOAP profile 
redundant; on 
the contrary, by proposing "infrastructure" for the inclusion of generic 
"credentials" in 
SOAP messages they highlight the importance of the SAML SOAP Profile in XML 
messaging. 

We need to review the current contents of the SOAP profile in light of the 
WS-Security and 
WS-License proposals. One possible outcome would be to build the SOAP 
profile as an instance of WS-Security and expose SAML assertions as a 
specific instance of the credential notion described in WS-License. However,

all of this will take some time and considerable discussion. 

I would therefore propose the removal of the materials on the SOAP profile 
from the current bindings draft. These materials, together, with the 
WS-Security and WS-License proposals, would be used as the basis for a new 
draft SOAP profile document. The TC would review this information and submit

a SOAP profile to OASIS in the near future (Q2/02). 

NOTE: 
-------- 
For reasons unknown to me, the above links do not always correctly lead to 
the two specifications. An alternative path is to view the table of contents

displayed on the 
LHS frame and directly access the specifications from the TOC. 


---------------------------------------------------------------- 
To subscribe or unsubscribe from this elist use the subscription 
manager: < http://lists.oasis-open.org/ob/adm.pl
<http://lists.oasis-open.org/ob/adm.pl> > 


---------------------------------------------------------------- 
To subscribe or unsubscribe from this elist use the subscription 
manager: < http://lists.oasis-open.org/ob/adm.pl
<http://lists.oasis-open.org/ob/adm.pl> >