[Fwd: Re: [security-services] Mistaken Use of SAML Specification inArticle on]

[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).
Additionally the comparisonof Subject was far from clear in that version
of spec too.

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

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

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.

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.

Please send any comments you have, we are looking for advice in this
case.

Sincerely,

Jan Alexander
WASP Server Chief Architect, Systinet (formerly Idoox)
www.systinet.com


> I don't see how to contact the author of this article:
>
> http://www.theserverside.com/resources/articles/Systinet-web-services-
part-6
> /article.html
>
> Perhaps you could forward this message.
>
> The article describes an invalid use of SAML. In the article, the
> author shows some XML which provides a password and expects the
> Authentication Authority to validate the password and issue an
> Authentication Assertion.
>
> This is an incorrect use of the specification. SAML assumes that a user
> has previously authenticated by some standard means to the
> Authentication Authority. The Authentication Request is a request by an
> Relying Party for information about this previous event.
>
> The Oasis SSTC has recognized that our specification is not clear
> enough in this area and is attempting to improve it.
>
> We appreciate your interest in SAML and your efforts to educate people
> on its use.
>
> If you want to see how SAML can be used for single signon in the
> context of HTTP, I suggest you look at the Browser Profiles describes
> in the SAML Bindings specification.
>
> A pointer to the current version can be found on this page:
>
> http://www.oasis-open.org/committees/security/index.shtml
>
> If you are interested in the use of SAML in the context of Java, you
> should be aware of the Java Community Process JSR 155. The goal of this
> activity is to make the use of SAML from Java easy.
>
> Hal
>
> =======================================================
> Harold W. Lockhart            Entegrity Solutions
> 2 Mount Royal Avenue          Marlborough, MA 01752 USA
> V: 1-508-624-9600 x 260       hal.lockhart@entegrity.com
> F: 1-508-229-0338             www.entegrity.com
> =======================================================