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

[Hal Lockhart <hal.lockhart@entegrity.com>]

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

Ahmed,
 
> All three use cases below are important w.r.t. B2B apps.

Very interesting. What kind of use case do you see for proxy login, given that we have two single sign-on Profiles for HTTP? What kinds of authentication methods must be supported? password? standard Kerberos? Microsoft Kerberos? SSL/TLS with client certs?

 
> You can add to the mixture ebXML and UDDI also, both based on
> SOAP messsage packaging.

I don't understand this comment. If you mean they can share the same technology, this is certainly true. However, does this satisfy the required use cases? I am ignorant on this point.

> 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.

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.

> 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 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 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.

My first message was intended as an invitation to help us add the small missing piece, that I believe is all you require. However, perhaps I am wrong. Please educate me as to the requirements, instead of simply repeating that SAML does not support credentials, which is simply FALSE.

Regards,

Hal