RE: Error inAbstractHTTPDestination.setHeaders,AbstractHTTPDestination.setHeaders

["Wolf, Chris (IT)" <Ch...@morganstanley.com>]

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:glen.mazza@verizon.net] 
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:glen.mazza@verizon.net]
> 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.