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

[Jan Alexander <alex@systinet.com>]

Hal,

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

Yes, now I see it, you are right about this, we will fix it in the next
release of WASP Card. We will use some extension to SAML to do this, not
trying to bend existing elements.

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

I completely agree at this point. I'm just saying, that in this particular 
situation, it is beneficial to do it this way, but we should do this using 
some kind of extension element to the original authentication query.

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

Yes I know, that the credentials are not covered by the SAML 1.0 spec, but
originally they were supposed to be, thus my wording about omitted,
meaning omitted from spec.

Yes we will certainly be interested to join you at this work, because I 
think it is essential to have credentials covered to some extent in the 
spec for the SAML to be successful.

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

Yes, it is about, how the components express this kind of information
using XML. But you are mainly showing the use cases with some kind of
client browsers and content provider sites, which is not always the case.
Especially from the middleware point of view. That is all I'm trying to
say here.

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


This is very ultimate answer, because I see many other possibilities how
the Web Service Authentication might work. You are too much concentrated
on the client side, where you suppose, you have only some kind of dumb
browser, unable to do anything else than combination of basic HTTP
authentication and SSL. That is not always true, you can have some kind of
strong authentication mechanism there (like Kerberos or SPKM, or pretty
anything else).

The client might also have some smart card, and using it to authenticate 
itself.

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


Yes, we are aware of this and would be happy, when it will appear in the
spec again.

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

I completely agree, that it is not goal to reinvent the wheel, but if you 
look at this from different point of view, you will discover, that what 
you are saying is not completely true.

Imagine for instance scenario, where you are using SAML to express
authentication assertion and you are transferring it to the other party.
If you are able to talk with the other party using Kerberos or SSL, why
would you need to even use SAML, because these mechanisms already provide
authentication for you. You want to use SAML when you are unable to
authenticate using authentication mechanisms you have available on your
side. You can for instance use only SMTP to pass the request with the SAML
assertion. Therefore you must protect the assertion against eavesdropping
and replay attacks. The protection against these attacks must be done on
or above the assertion level and it would be nice, if this kind of
protection could be expressed using the SAML spec. This is what I was
referring to as Kerberos-like authenticators.

We would like to join our efforts in this area with Security Services TC, 
because we will need this kind of functionality anyway. We already provide 
transports, like JMS or SMTP where this is necessary.

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

Yes, I'm fine with that.

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

Unfortunately, the Browser profile is not enough for us, and one reason
for this is, that we are not using browsers at all. We are using SOAP
Clients, which are usually more capable than browsers, so we really don't
need those "dirty hacks" with artifacts, etc., which you need to make the
SAML work on dump clients (like browsers). I'm not saying that we cannot
do it this way, but this is not the way we want to go.

Again we are more than willing to join our effort with Security Services
TC to create the profile more suitable for environments like ours.

Sincerely,

Jan