You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Wolf, Chris (IT)" <Ch...@morganstanley.com> on 2008/03/21 16:30:38 UTC
RE: Error in AbstractHTTPDestination.setHeaders,AbstractHTTPDestination.setHeaders
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.
RE: Error inAbstractHTTPDestination.setHeaders,AbstractHTTPDestination.setHeaders
Posted by "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.
RE: Error in
AbstractHTTPDestination.setHeaders,AbstractHTTPDestination.setHeaders
Posted by Glen Mazza <gl...@verizon.net>.
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.