Solved

Very difficult question regarding jsp, http and authentication.

Posted on 2002-07-02
36
242 Views
Last Modified: 2010-05-18
Hello,
I am wondering how to accomplish the following scenario:
Server A hosts jsp-page A.jsp.
A.jsp contains a link to B.html at server B.
The web-server at B is using HTTP
basic authentication to protect B.html from unauthorized
access.
My problem is that a.jsp knows the credentials for B.html
but I just can't find a way to supply the credentials to the web-server at B and then access B.html.
And I have tried several ways to do this.
For example, I have tried to implement a http-socket
client in A.jsp that authenticates with the web-server at B, this works of course, but then only the web-server at A gets authenticated and not the client who will actually display A.jsp.
Another way is to retrieve the html-code for B.html through a similar http-socket connection in A.jsp but this will not solve relative links in B.html and the same problem occurs if B.html contains links to other resources at B that are also protected.

The whole idea is to avoid the login-operation by knowing the credentials in advance.
Can this be done in any way?
I think not.

I am very grateful for your help!

Best regards Mathias
0
Comment
Question by:MathiasJ
  • 16
  • 8
  • 6
  • +3
36 Comments
 
LVL 9

Accepted Solution

by:
Venci75 earned 167 total points
ID: 7124646
have you tried:
http://user:pass@host/...
0
 
LVL 86

Assisted Solution

by:CEHJ
CEHJ earned 167 total points
ID: 7124655
>>Another way is to retrieve the html-code for B.html through a similar http-socket connection in A.jsp but this will not solve relative links in B.html

You could, of course, dynamically rewrite (all) the urls in B.html to use A as the proxy, whether the urls are relative or not. This is not an elegant approach, but it would work and I can't think of another!
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 7124693
Venci's proposed solution would seriously compromise security :-)
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 7125165
Come to think of it, url rewriting is not that bad. In fact as you probably know, it is a common technique in web/application servers to maintain session information where cookies are disabled on the client. You could probably find a class that does this for you.
0
 

Author Comment

by:MathiasJ
ID: 7125424
Hello CEHJ,
url rewriting is not perfect in this case.
It makes A.jsp very dependend on any changes to B.html as well as the web-server at server B.
Also, it does not solve the case where B.html has links to other HTTP-authenticated resources at B, this will lead to  that the browser's authentication window pops up and demands credentials.
Or am I wrong?

/Mathias
0
 

Author Comment

by:MathiasJ
ID: 7125433
Hello Venci,
your idea is probably working, I havent
tried it quite yet. However, as CEHJ points out the
credentials are out in the open. Of course, it can
be argued that the HTTP basic authentication anyway
has the credentials out in the open, just embedded in
base64 encoding.
Is there no way around this dilemma?

/Mathias

Ps. Thank you both for your comments, I appreciate them a lot.
0
 
LVL 3

Expert Comment

by:mjzalewski
ID: 7125524
Actually, you might try to have the JSP page open a URLConnection with an URL address like http://user:password@host..., then send the output back to the client from server A.

Basically, use URLConnection.getInputStream() to retrieve the contents of the protected page on B into a JSP or other servlet on A. Read the contents of that input stream and write it out to the servlet's output. Not really as hard as a http socket.

This way, the browser never sees the password. Images, relative links, and cookies are a problem though, if any of those resources are also protected.
0
 
LVL 16

Assisted Solution

by:heyhey_
heyhey_ earned 166 total points
ID: 7126019
> I just can't find a way to supply the credentials to the web-server at B and then access B.html.

if you insist on using "HTTP basic authentication" , the only possible solution is to retrive all the protected data form one central place, i.e. a.jsp
0
 

Author Comment

by:MathiasJ
ID: 7126199
Hello Mjzalewski,
what you suggest is basically what I have tried already
with the http-socket connection described above. It does not solve the problem since relative links are broken for example.
/Mathias
0
 
LVL 16

Expert Comment

by:heyhey_
ID: 7126207
>  since relative links are broken for example.

you have to rewrite all links (as CEHJ already suggested). this is the only possible solution if you insist on using "HTTP basic authentication"

0
 

Author Comment

by:MathiasJ
ID: 7126210
Hello heyhey,
it is not me who insist on using the authentication schema, it is a remote web-site which I have no control over. And since you say that the only possible solution is to retrieve the protected data, then the solution becomes too unstable to be usable in a production environment. Then url-rewriting needs to be used with it's problems as described above. And when the remote web-site moves pages, or rewrites them, renames them etc, then there is a nasty problem to keep track of.

I guess the conclusion of this problem is that it cannot be solved in an elegant way, if the credentials shouldn't be open to any sniffer.
Or am I wrong? :)

/Mathias
0
 
LVL 9

Expert Comment

by:Venci75
ID: 7126212
I was actually looking for a way to supply the user/pass to the browser (in my case IE). I had a particular success, but only on IE. I found a way to set an http header field for a certain request. Unfortunately IE doesn't use this values for the following requests, which (as I understood) can't help you.

I will be really lucky to see a better solution of this problem.
0
 

Author Comment

by:MathiasJ
ID: 7126219
Hello Venci75,
a solution for just IE is not strong enough :)
0
 

Author Comment

by:MathiasJ
ID: 7126220
Hello Venci75,
a solution for just IE is not strong enough :)
0
 
LVL 9

Expert Comment

by:Venci75
ID: 7126221
I've heard for a 'http form authentication'. I am actually not sure what does this mean, but sounds like appropriate solution for you. Are you 100% sure that you *must* use basic authentication?
0
 
LVL 16

Expert Comment

by:heyhey_
ID: 7126223
> And when the remote web-site moves pages, or rewrites them, renames them etc, then there is a nasty problem to keep track of.

you will dynamically rewrite HTML content so there won't be any problems.
0
 

Author Comment

by:MathiasJ
ID: 7126235
Venci75,
http form authentication is a better choice than the
basic one, but as I said above, it is not my choice what kind of authentication that is used at the remote web-server.
/Mathias
0
Enabling OSINT in Activity Based Intelligence

Activity based intelligence (ABI) requires access to all available sources of data. Recorded Future allows analysts to observe structured data on the open, deep, and dark web.

 

Author Comment

by:MathiasJ
ID: 7126262
Heyhey,
I guess the solution works when it is combined with the
http://user:pass@...  idea.
Then the fetched page will contain the credentials so that any links from that page can use the same credentials thus no additional authentication required.

However, this will Anyway send the credentials out in the open, but I guess this won't ever be avoided with the basic http authentication scheme.
Assuming this, then it is easier to just render the link to the remote web-server with the user:pass@ method.
Or can it be argued that the url-rewriting is better?
Especially considering the additional work and performance hits that are included in that solution.

/Mathias
0
 

Author Comment

by:MathiasJ
ID: 7126272
Heyhey,
I guess the solution works when it is combined with the
http://user:pass@...  idea.
Then the fetched page will contain the credentials so that any links from that page can use the same credentials thus no additional authentication required.

However, this will Anyway send the credentials out in the open, but I guess this won't ever be avoided with the basic http authentication scheme.
Assuming this, then it is easier to just render the link to the remote web-server with the user:pass@ method.
Or can it be argued that the url-rewriting is better?
Especially considering the additional work and performance hits that are included in that solution.

/Mathias
0
 

Author Comment

by:MathiasJ
ID: 7126278
Heyhey,
I guess the solution works when it is combined with the
http://user:pass@...  idea.
Then the fetched page will contain the credentials so that any links from that page can use the same credentials thus no additional authentication required.

However, this will Anyway send the credentials out in the open, but I guess this won't ever be avoided with the basic http authentication scheme.
Assuming this, then it is easier to just render the link to the remote web-server with the user:pass@ method.
Or can it be argued that the url-rewriting is better?
Especially considering the additional work and performance hits that are included in that solution.

/Mathias
0
 

Author Comment

by:MathiasJ
ID: 7126286
Heyhey,
I guess the solution works when it is combined with the
http://user:pass@...  idea.
Then the fetched page will contain the credentials so that any links from that page can use the same credentials thus no additional authentication required.

However, this will Anyway send the credentials out in the open, but I guess this won't ever be avoided with the basic http authentication scheme.
Assuming this, then it is easier to just render the link to the remote web-server with the user:pass@ method.
Or can it be argued that the url-rewriting is better?
Especially considering the additional work and performance hits that are included in that solution.

/Mathias
0
 

Author Comment

by:MathiasJ
ID: 7126310
Oh jesus christ,
why doesnt this page has a reload button......
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 7128492
>>Or am I wrong?

Yes, I think so - although as it's late now I'll come back to you on this!

>>
Of course, it can
be argued that the HTTP basic authentication anyway
has the credentials out in the open, just embedded in
base64 encoding.
>>

Well there are degrees of 'in the open'! Basic authentication is only out in the open if someone's packet sniffing. Having the username and password in the (unhideable) html source is tantamount to publishing them.
0
 

Author Comment

by:MathiasJ
ID: 7129294
CEHJ,
yes, I agree that there are different degree of out in the open and most people would never be able to find the credentials with the basic authentication, but to a certain group of people it is out in the open.
/Mathias
0
 
LVL 9

Expert Comment

by:Venci75
ID: 7129322
... another suggestion - you may create something like proxy on A. This proxy will listen on a specific port - say 12345.
When A generates a page with a link to B, the link will be:
http://A:12345/...

in this case you need only to change the links from the pages on A.

... a problem comes when a page from B has a link to a third server - C. In this case you won't be able to supply the user/pass for C to the browser.
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 7129523
>>
It makes A.jsp very dependend on any changes to B.html as well as the web-server at server B.
>>

No it doesn't, as the rewriting would occur on the fly. You would cope with relative and absolute link addressing schemes.

>>
Also, it does not solve the case where B.html has links to other HTTP-authenticated resources at B, this will lead to  that the browser's authentication window pops up and demands credentials.
>>

This isn't a special case: see first comment.

>>a problem comes when a page from B has a link to a third server - C. In this case you won't be able to supply the user/pass for C to the browser

This is not a consideration is it (it wasn't part of your 'spec')?
0
 

Author Comment

by:MathiasJ
ID: 7129822
Alright, I am grateful for your answers and time devoted
to this scenario. How do you feel I should divide points between yourselves? It feels most fair to let you divide them since you have given thinkable solutions where each solution has its drawbacks.

/Mathias
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 7129834
OK by me. Even better to divide them and later to give a bonus to the guy whose solution (or concept)you finally implement!
0
 
LVL 9

Expert Comment

by:Venci75
ID: 7129847
I agree with CEHJ
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 7129865
Since 500 % 3 != 0 why not divide 402 points between us and give out the remaining 98 later [if you can remember :-)]
0
 

Author Comment

by:MathiasJ
ID: 7130417
Alright, I will divide 500 by 3 and then you three will get like 160 points each. I am not quite sure how to do this but I'll post three new questions with 160 points each addressed to each one of you.

/Mathias
0
 
LVL 9

Expert Comment

by:Venci75
ID: 7131326
I think that there is another way to split the points - but probably you should ask the CS
0
 

Author Comment

by:MathiasJ
ID: 7131484
Hmmm, it does seem like the only possible solution
is to perform url rewriting after all. It simply doesn't
work with just the user:pass@ idea. It seems like a servlet redirect on an url with user:pass wont send the credentials so that it works as I want. However, if I refresh the error page that comes up then it works...
That's what I call nice, why on earth is it like that?

/Mathias
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 7131649
This *may* be something to do with the browser. The usual authentication sequence is somewhat broken by your modus operandi:
http://frontier.userland.com/stories/storyReader$2159
0
 
LVL 35

Expert Comment

by:girionis
ID: 8893737
No comment has been added lately, so it's time to clean up this TA.

I will leave a recommendation in the Cleanup topic area that this question is:

- split points between CEHJ, Venci75 and heyhey_

Please leave any comments here within the
next seven days.

PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER !

girionis
Cleanup Volunteer
0

Featured Post

Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

Join & Write a Comment

Suggested Solutions

Title # Comments Views Activity
Receive file in Servlet 1 36
Java Message handling in Service Layer 3 37
backtracking recursion  code 19 40
maven project error 5 21
For customizing the look of your lightweight component and making it look opaque like it was made of plastic.  This tip assumes your component to be of rectangular shape and completely opaque.   (CODE)
Introduction Java can be integrated with native programs using an interface called JNI(Java Native Interface). Native programs are programs which can directly run on the processor. JNI is simply a naming and calling convention so that the JVM (Java…
Viewers will learn about the different types of variables in Java and how to declare them. Decide the type of variable desired: Put the keyword corresponding to the type of variable in front of the variable name: Use the equal sign to assign a v…
This video teaches viewers about errors in exception handling.

759 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now