RE: [Fwd: Re: [security-services] Mistaken Use of SAML Specificat ionin Article on]

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

Title: RE: [Fwd: Re: [security-services] Mistaken Use of SAML Specification in Article on]

Jan,
 
> thank you for your response to our article. I would like to
> say that our
> WASP Card product is based on the core-25 specification, where it was
> possible to return AuthN assertion with Subject not exactly
> the same as
> in the AuthN request (at least it was not prohibited to do so).

This is not so. In core-25 lines 977-978 it says:

The <AuthenticationQuery> element is used to make the query "What authentication assertions are available for this subject?"

In lines 984-986 it says:

In response to an authentication query, a responder returns assertions with authentication statements as follows: The <Subject> element in the returned assertions MUST be identical to the <Subject> element of the query.

> Additionally the comparisonof Subject was far from clear in
> that version
> of spec too.
 
We agree that the specs are not sufficiently clear. You are not the only ones who have made this mistake. My purpose was not to criticize you. However, since your work has been published, you are obviously in a position to influence many people. We do not want this error to be propogated.

> Because we want to use SAML on the middleware layer not on the client
> (browser layer), we don't need and also don't want to use the
> one-time-use artifacts and such. We just decided to use the
> SAML-RPC to
> request the AuthN assertion and included the username and
> password inside
> the Subject ConfirmationMethod element because the spec
> didn't prohibit
> that (and the XML Schema allowed that) and it saved us one additional
> roundtrip on the transport layer to do the authentication
> separately from
> the actual SAML-RPC request.

The problem is that this is not conformant behavior. If your requester sends this request to a conformant responder, the responder will look for information about past authentication acts and assuming it finds none, return a response with no assertions in it. In no case will it use the username and password to perform an authentication.

If you build a responder that does this kind of pass thru login, it may use SAML syntax, but it will not be SAML compliant.

> Yes, we certainly combined the omitted
> credentials assertion with theauthentication assertion, but frankly I
> don't see any harm in this, actually Ithink, that for this simple
> authentication schemas (like password based or digest based
> authentication) it would be very useful to allow this kind of
> thingshappen in the final SAML 1.0 specification.

There is no credentials assertion. It does not exist. As Figure 1 of core-25 makes clear, the credentials collector is outside the scope of SAML 1.0. This project has been on hold for some time. If you have interest in it, we would be pleased to have you join us in working on it. It is a very difficult problem if other types of authentication are supported than just username/password. I would be glad to explain this in more detail if you are interested.

 
> Of course, when the final SAML 1.0 specification will be out, we will
> modify ourproduct and the samples in accordance to the spec, I'm just
> saying that maybe you are too much concentrated on the client
> (browser)
> level

Actually the opposite is true. SAML is ONLY about infrastructure. It is entirely about how infrastructure components exchange information with each other. Browsers and applications only become involved as a vehicle for passing information between infrastructure components.

 and the middleware layer, which we are particularly
> interested in,
> is very underspecified and with the omission of the SOAP
> profile things
> are getting much more worse, because now it is necessary for
> us develop
> some extensions to the spec to be even able to use it and this will of
> course do harm to the interoperation on the middleware layer between
> multiple vendors using SOAP and SAML together.

First of all, nobody really knows how Web Services Authentication is going to work in the future. I see three possibilities.

1. "Dumb" Username/password with SSO - this case is covered by our two browser profiles. I suggest you use them in your example.

2. SSL/TLS with client certificates - in this case SSO is built-in and transparent to the user. There is nothing for SAML to do here in the way of SSO.

3. No sesssion authentication, just signed transactions. This is what the SOAP Profile is aimed at. In this case no SSO is required or implemented.

The SOAP Profile was held back for only one reason. We wanted to understand its relationship to what Microsoft has proposed. IMO it is very likely that the final Profile will not be substantially different from what has been published previously. There is little more risk to moving forward with it now than with working from core-25.

> Additionally we are missing some type of possibility to provide the
> Kerberos-likeauthenticator to the SAML assertion on the client side to
> prevent the replay attacks, because just limiting the time
> slice when the
> particular
> assertion isvalid is not really enough in many cases, and
> also relying on
> the transport layer security is not enough or you just don't
> want to do
> that.

SAML works just fine with Kerberos or the Microsoft Kerberos-like scheme. The Browser Profiles were required to work with the 99% of Browsers currently in use without any plugins. Therefore it was necessary to accept the limitations of that environment.

It was a specific goal of SAML not to invent things that already exist. TLS and Kerberos (if based on a more modern cryptographic algorithm) are excellent protocols, the trick is to get people to use them.

> However we believe, that SAML will become the security
> assertion "common
> language" and that why we are using it in our product. The version 1.0
> will benice start, but there many things to coped with and we
> have still
> a lot work ahead.

SAML has deliberately provided many points of extension with the idea that many people will need to use its features in different ways. However, we have laid down the rule that you can not alter the basic semantics and still call it SAML.

If you wish to implement SSO in the context of HTTP, I suggest you follow the Browser Profiles. They have been designed and reviewed by a substantial number of security experts.

Regards,

Hal