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,

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

I am not saying SAML has not defined Credentials. However, it is clear that this is not the same definition being used by Microsoft. (This is not a criticism, just an observation. Not everybody in the SAML TC agreed with our definition.)

 
>
> 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 don't know what you are referring to here.

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

Since no additional use cases have been provided, I will assert that the SOAP Profile is completely satisfactory for this use. A sender can attach an attribute assertion to a SOAP message and use an appropriate subject confirmation method (e.g. password, Kerberos, PKI) to verify the identity of the sender. What else do you need? Do you want the sender to pass along his secret keys?

In fact, if the the SOAP message is signed, it is not clear to me that an interactive login is required at all.

I freely stipulate that the above may simply reflect my ignorance of SOAP usecases. Please feel free to educate me.

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

I really don't understand this. Password is a string. Kerberos ticket is a base64 string, ds:KeyInfo covers all of PKI. What's this about foreign namespaces?  

I also don't understand the use of the term "overloaded" here. An attribute is an attribute. A credential (either definition) is clearly an attribute.

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

I don't see why. This information is available elsewhere. Why duplicate it? The most to be done here is to assemble references to various standard authentication methods. Many of these are already in the SAML core specification References chapter.

Regards,

Hal