Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta-httpclient Wiki" for change notification.
The following page has been changed by RolandWeber: http://wiki.apache.org/jakarta-httpclient/FrequentlyAskedApplicationDesignQuestions The comment on the change is: extended version of "Server Performing Login for Client" ------------------------------------------------------------------------------ then handing the session over to the client. Since the authentication is already performed by the server or proxy, the client is not supposed to ask the user for credentials. - This is '''not possible'''. We mean it. It is '''not''' possible. Seriously. + In general, this is '''not possible'''. We mean it. It is '''not''' possible. Seriously. + Unless very specific conditions are met, there is '''no way'''. - Unless the server or proxy is in the same domain as the server to which you want to log in, - there is '''no way'''. - [[BR]] - If you find a way to make this work across domains, please report a security vulnerability against the browser. + === Why It Should Not Work === + + Imagine you are a server called Bob. + Alice logs in to you, providing her credentials. + Then Charlie appears, trying to access Alice's data. + Charlie has no credentials, he just says: "Alice logged in on my behalf." + Sounds fishy, does it not? + ''Would you believe Charlie?'' + + So, what are the conditions which might allow this to happen anyway? + Firstly, authentication must apply to a session rather than the individual requests. + This usually implies form-based authentication (see above) and the existence of a session ID. + Secondly, the server configuration must be a bit negligent regarding security. + The rest depends on the type of session tracking. + + === URL-based Session Tracking === + + If the user session is tracked in the URL, the handover is simple. + Just send the URL including the session ID from the proxy or server to the client. + If the server does not notice the change of the client IP address, you are lucky. + A URL with session identifier could look like this: + http''''''://webmail.where.ever/xml/webmail;jsessionid=89702CCE20F2401326843985B0FB546F.TC159b + + === Cookie-based Session Tracking === + + If the user session is tracked with a session cookie, the handover is problematic. If your server or proxy is in the same domain as the site you want to login to, - you can ''try'' to send the session cookie obtained from the target site on to the client, + you can send the session cookie obtained from the target site on to the client, setting it at the domain level. - This may or may not work, depending on the configuration of the target server, and of other servers in the domain. + This may or may not work, depending on additional security checks by the server. + It may interfere with session tracking of other servers in the same domain, + causing 'inexplicable' malfunctions of seemingly unrelated web applications for the client. [[BR]] - If you don't know what all that stuff means, you shouldn't implement + A better solution would be to create a Single Sign-On (SSO) domain for your server or proxy and the target site. + Check the documentation of your application server(s) for information on Single Sign-On. + + If your server or proxy is ''not'' in the same domain as the site you want to login to, you are out of luck. + [[BR]] + ''If you find a way to make this work across domains, please report a security vulnerability against the browser.'' + + If you don't know what all that stuff about cookies and domains means, - this kind of security sensitive application in the first place. + you shouldn't implement this kind of security sensitive application in the first place. + + === Further Reading === + + [http://en.wikipedia.org/wiki/Alice_and_Bob Wikipedia: Alice and Bob] + + [http://java.sun.com/javaee/5/docs/tutorial/doc/Servlets11.html#wp64784 Java EE 5 Tutorial: Session Tracking] + + [http://en.wikipedia.org/wiki/Cross-site_cooking Wikipedia: Cross-site Cooking] + + [http://en.wikipedia.org/wiki/Single_sign-on Wikipedia: Single sign-on] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
