[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: Summaryand an Action Plan
Zahid, Good three point summary ! Agree with them all. Re WS-Confidentiality and WS-Integrity, I do not think MS has added anything. Just two more elements and a very generic syntax. IMHO, both are superfluous (for now) unless there are some new syntax and semantics around them, which ds:Signature and EncryptedData elements from their respective specifications couldn't capture. In this respect, I am agreeing with Hal. BTW, can anybody tell me what *real* function does the WS-Confidentiality and WS-Integrity elements serve in the WS-Security specs ? How would these two elements make any difference ? Consolidating multiple-signatures ? Distributing encrypted data at different places in a packet ? Re Ws-Credential, SAML needs a Credential Assertion which is what WS-Credential has defined. (while we are on this subject, SAML needs the Session Assertion as well, which I hope we will tackle soon after 1.0 is released) I really do not think we would get anything from the WS-XXXX specifications (as they stand now) for the SOAP binding. But, as Zahid points out, with a *first class* credential assertion and some more maturity from the WS-XXXX specifications, hopefully, we would have a better SOAP binding in the next rev. cheers & have a nice weekend | -----Original Message----- | From: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com] | Sent: Friday, February 15, 2002 1:05 PM | To: 'Hal Lockhart'; security-services@lists.oasis-open.org | Subject: RE: [security-services] SOAP Profile of SAML vs WS-Security: | Summ ary and an Action Plan | | | Hal, | | Thanks for your questions/response. | | >> 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. | .... | >I don't under your viewpoint. SAML has defined the semantics of | attributes | and a method of | >including any schema. It has defined some simple cases and a method for | profiling new usages. | >Since what you seem to want to do is use a ds:KeyInfo in an Attribute | Assertion, there does | >not seem to be anything left to define. You can use this today | and anyone | can interoperate. | | I believe we have discussed the definition of credentials in | this TC before. | For the | purpose of this discussion, if we re-use a variant of those set of | definitions: | | "Credential specify the subject's authentication data that can be used to | verify | the identity of the subject by a target application's security service | provider. The | process of verifying a subject credential is part of authentication | process." | | It is possible that SAML enabled application could import their own | "attribute" | schema which encapsulates semantics of credentials. If the credential | specification | is from the ds:KeyInfo, then yes we can conceivably have some level of | interoperation. | If, however, the credential definition is not from a | well-defined namespace, | then | two applications using SAML will not achieve interoperability via the | "assertion-orienetd" | credential approach suggested above unless they go through a cumbersome | process of installing these specialzied credential schema definitions. | Proliferation | of multiple definitions of credential schema is not going to work. | | Hence, it would be useful to define a set of concrete | definitions of useful | Credentials that should be part of the SAML Content Model, i.e., | Assertion | specification. | Using attribute assertion to model credential I believe is only a | workaround to the | current limitation in SAML 1.0 of not being able to employ well-known | "authentication data" elements from standard namespaces. | | | >> 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 disagree completely. I am looking at the WS-Security and WS-License | specifications. Are | >you perhaps refering to some other specifications? They do not | define any | semantics. As | >far as syntax, they basically define an empty bucket in which | one can put | an ill spefified | >object. For example, take Kerberos ticket. What kind of ticket? Only a | service ticket addressed | >to the relying party is of any use. Can it be cross realm? Does | it include | an Authenticator? | >Microsoft frequently encrypts with RC5, instead of DES. How do | I know what | the ticket | >is encrypted with? In my view, MS-License and MS-Security provide an | incompeltely specified | >format for sending unknown objects for unknown purposes. I | assert that SAML | has done far | >more than that, and if we had the help of interested parties, we could | conmplete this process | >in a week or so. | | I think we are more in agreement here w.r.t. status of Microsoft's GXA | ws-security | specification and their latest schema (dated 1/17/02): | | http://msdn.microsoft.com/ws/2002/01/Security/ | | http://schemas.xmlsoap.org/ws/2002/01/secext | | | Difference between ws-security and SAML 1.0 and some limitations: | | 1. Inclusion of Credential (Authentication data) in SOAP Message | ws-security includes an approach of including credentials, among | additional | other security extensions, as part of SOAP messages. SAML 1.0 does not | have the explicit capability to attach credential in SOAP envelopes. I | believe | that is one of these reasons why we had to delay the release of SOAP | Binding of SAML. | | 2. Schema Definition of Common Credentials and | ws-security includes some commonly used schema definitions of | some commonly used Credentials and also a way to import other | credentials from foerign namespaces. SAML content model lacks | definition of such elements currently although in some cases | attributes | could be overloaded with credential semantics.It is true that the | abstract definition of Credential currently lacks an | authenticator. | | 3. Credential Authentication Model | ws-security also lacks any discussions of authentication | process, i.e., | credential data validation. However, that is consistent with | design goals | of | ws-security w.r.t. its focus on application security. So, we | agree that | semantic processing of credentials (i.e, authentication data) is not | included in ws-security nor is it included in SAML 1.0. This is | possibly an area that could be fixed in both ws-security and SAML | in the future. | | | thanks, | Zahid | | | | | | | | | | | | | | | ---------------------------------------------------------------- | 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