Sorry for the delay on this, but I'm pretty certain that CXF has a bug. I discovered that Siteminder does indeed blank out the password in the Basic "Authorization" header, once the user is authenticated via Sitemeinder, for security purposes, however there is *still* a colon character, therefore this fulfills the RFC-2617 spec, which allows for a zero-length password. I quote the BNF from the spec: http://www.rfc.net/rfc2617.html#p5 To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a base64 [7] encoded string in the credentials.
basic-credentials = base64-user-pass base64-user-pass = <base64 [4] encoding of user-pass, except not limited to 76 char/line> user-pass = userid ":" password userid = *<TEXT excluding ":"> password = *TEXT As you can see, zero-length passwords are permitted. The fix is a one-liner, in org.apache.cxf.transport.http.AbstractHTTPDestination, line 137 (snapshot 2008-01-30) Change the line from: String password = authInfo[1]; ...to: String password = (authInfo.length>1?authInfo[1]:""); I took the liberty of creating a Jira entry for this bug: https://issues.apache.org/jira/browse/CXF-1495 Thanks, -Chris Wolf -----Original Message----- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2008 8:43 PM To: cxf-user@incubator.apache.org Subject: RE: Error inAbstractHTTPDestination.setHeaders,AbstractHTTPDestination.setHeaders I've been looking at our Basic Authentication recently--the error messages have been cryptic in many cases, not providing acceptable feedback. In your case below, we should have a precise error message about an invalid format in the Authorization header field--not just an NPE of course. If you could submit a JIRA for this it would be appreciated, else I'll try to remember. I don't think we should make an exception for Siteminder though, because that might open up a security hole. Also, Section two of RFC 2617[1] states: "To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a base64 [7] encoded string in the credentials." Apparently both username and password are always needed. I don't know Siteminder but I would think they would have an option to always supply a password in order to be RFC 2617 compliant. If not, please let them know about it. Thanks, Glen [1] http://www.faqs.org/rfcs/rfc2617.html Am Freitag, den 21.03.2008, 11:30 -0400 schrieb Wolf, Chris (IT): > Glen, > > Thanks again for your help. I downloaded the source and looked at it > before going through the laborious task of setting up for remote > debugging. > > I can see the the issue is the code in AbstractHTTPDestination always > assumes the value of the "Authorization" header will always be a > base64 encoded "username:password" value -- in my case, we use > Siteminder authentication, so sometimes the value of the > "Authorization" header is just the base64 encoded username -- without > a colon and password, i.e. no ":passw", which exactly explains this > array index out of bounds exception. > > The workaround is, I'm going to tell my users to log out of Siteminder > and re-authenticate, such that the "Authorization" header always has > both pieces in the value. > > I would like to present a patch for the case where the "Authorization" > header value does not contain a colon character, even for "Basic" > type of authentication, but I'm not sure special accomodation would be > made for Siteminder, unelss the RFC for Basic authentication says the > "Authorization" header may contain just an encoded username in certain > circumstances. > > > -Chris > > -----Original Message----- > From: Glen Mazza [mailto:[EMAIL PROTECTED] > Sent: Friday, March 21, 2008 7:12 AM > To: cxf-user@incubator.apache.org > Subject: Re: Error in > AbstractHTTPDestination.setHeaders,AbstractHTTPDestination.setHeaders > > Am Freitag, den 21.03.2008, 01:27 -0400 schrieb Wolf, Chris (IT): > > If I run my service inside a Tomcat-5.5 runtime configured in > > Eclipse-3.2, all works fine. > > I run the very same code, deployed on Tomcat-5.5 on Linux, I get > > this error. > > If anyone can suggest something short of debuggin the CXF source, > > that > > > would be great. I am using 2.0.4. > > > > If nobody else can answer your question, time to debug the CXF source: > > http://www.jroller.com/gmazza/date/20071212 > > Step #5 would probably be most important for you. > > Glen > -------------------------------------------------------- > > NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.