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