Basic Auth challanges with reverse proxies

Hi all. I am having problems returning basic auth challenges through my
reverse proxies. The setup is Apache 2.0.52 in the DMZ reverse proxying
to yet another Apache 2.0.52 reverse proxy (with mod_proxy_html
scrubbing the outbound content) behind the second firewall, which
proxies to the back end servers through up to two more firewalls, with
end to end SSL.

If I open a browser on the second (intranet) reverse proxy and point it
at one of the back end apps that uses basic auth challenges I get the
challenge pop up. However, when I attempt to connect to the same
servers through my reverse proxies I get an HTTP 1.1 / 401

To further muddy the waters, the client has Siteminder on my DMZ
Apache's, but some of the back end server admins refuse to integrate
with Siteminder and are demanding I return the basic auth challenges.

Has anyone tried to build anything similar or experienced similar
problems before? My guess is the back end server is attempting to read
the Sietminder cookie, not doing so, and returning a 401. Hence no pop
up auth challenge. But I need a more definitive answer before i go back
to the client. Any input would be greatly appreciated.

Cheers,

Ian

On 2004-12-11, IanB <ianvbevan@yahoo.com> wrote:
> Has anyone tried to build anything similar

No, since I don't really see the point in having so much proxying and
firewalling...

> My guess is the back end server is attempting to read
> the Sietminder cookie, not doing so, and returning a 401.

Can't you try to 'fake' such cookie?

Davide

--
We are very nervous about the release of Windows 2000. This OS takes up
gigabytes of hard drive space. When users 'upgrade' to Win2K, they won't have
any space on their hard drive for our products! We really hate Chairman Bill.

>>> Has anyone tried to build anything similar

>>No, since I don't really see the point in having so much proxying and
firewalling...

Yeah its total overkill, but required by the clients corporate policy.

>>> My guess is the back end server is attempting to read
>>> the Sietminder cookie, not doing so, and returning a 401.

>>Can't you try to 'fake' such cookie?

It looks like i either need to fake it or unset it. I have been looking
at mod_headers, but am wondering how I can unset the auth cookie for
just a handful of the hundreds of servers I am reverse proxying to. I
cannot universally remove the cookie or single sign on for the
integrated servers will be fubared. I just need to unset it for a few
sites. Any ideas?

"IanB" <ianvbevan@yahoo.com> wrote in message
news:1103574503.086054.315530@c13g2000cwb.googlegr oups.com...
>>>> Has anyone tried to build anything similar
>
>>>No, since I don't really see the point in having so much proxying and
> firewalling...
>
> Yeah its total overkill, but required by the clients corporate policy.
>
>>>> My guess is the back end server is attempting to read
>>>> the Sietminder cookie, not doing so, and returning a 401.
>
>>>Can't you try to 'fake' such cookie?
>
> It looks like i either need to fake it or unset it. I have been looking
> at mod_headers, but am wondering how I can unset the auth cookie for
> just a handful of the hundreds of servers I am reverse proxying to. I
> cannot universally remove the cookie or single sign on for the
> integrated servers will be fubared. I just need to unset it for a few
> sites. Any ideas?

Your back-end server is not trying to read the siteminder cookie. Why would
it want to do that? It has no interest in that cookie or even know about
that cookie. The siteminder cookie is for the Siteminder agent to read and
decrypt and understand.

When you backend receives a request, it does what it is expected to do - to
issue the basic auth challenge ('cause it's been configured to do just
that). The client that is issuing the request (whether browser or proxies,
with or without Sitemider agent/plugin) has to be able to respond
accordingly ie. respond to the basic auth challenge by sending back the
correct data stream.. If you do not write the correct response (or somehow
insert the correct data stream), you simply ain't gonna solve the problem.
Period.

Don't waste your time on SM cookies. You are simply on the wrong track
there.

--
When you are about to die, a wombat is better than no company at all.
-- Roger Zelazny, "Doorways in the Sand"

>>When you backend receives a request, it does what it is expected to
do - to
>>issue the basic auth challenge

Actually, its not returning the basic auth challenge. Its returning a
403, thats the problem.

"IanB" <ianvbevan@yahoo.com> wrote in message
news:1103664122.935320.21880@c13g2000cwb.googlegro ups.com...
>>>When you backend receives a request, it does what it is expected to
> do - to
>>>issue the basic auth challenge
>
> Actually, its not returning the basic auth challenge. Its returning a
> 403, thats the problem.
>
Google's your friend -
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated. If the
request method was not HEAD and the server wishes to make public why the
request has not been fulfilled, it SHOULD describe the reason for the
refusal in the entity. If the server does not wish to make this information
available to the client, the status code 404 (Not Found) can be used
instead.
http://www.cknow.com/ckinfo/def_h/httpreturncodes.shtml
403 (Forbidden). This is a sort of catch-all refusal. If the server
understood the request but, for whatever reason, refuses to fill it, a code
403 will often be returned. The server may or may not explain why it is
sending a 403 response and there is not much you can do about it.

Ask the administrator why the server is returning 403 to your request. Maybe
just some particular way the server is configured. He can trawl the logs and
should be able to tell you under what circumstances a 403 is returned.

Good luck.

--
What happened last night can happen again