[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
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> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC