[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] SOAP Profile of SAML vs WS-Security: Summ aryand 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]
> 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]
> | 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/
> | dnsrvspec/h
> | tml/ws-security.asp
> | <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/
> | dnglobspec/
> | html/wslicspecindex.asp
> | <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
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>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC