[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [Fwd: Re: [security-services] Mistaken Use of SAML Specification inArticle on]
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 > =======================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC