3

I have a web application (C# - ASP.net) that needs to pass a user to a page on a remote Apache server using HTTP Basic Authentication. I need to be able to pass a user name and password to this server to allow users authenticated by my application to seamlessly use the other application without being prompted to enter credentials he doesn't have. The hand-off should be secure since both systems require SSL as long as the user name and password are not in client-side script. Is there a way to do this?

MPelletier
  • 16,256
  • 15
  • 86
  • 137
Steven Scott
  • 31
  • 1
  • 2
  • Are both on the same server? eg could pass some random tie in string to pick up from a database to reload the session credentials into the new session on another site. – BugFinder Jun 16 '11 at 15:43
  • No, they are on different servers. One (mine) is running IIS7. The other is running Tomcat7 a few thousand miles away. – Steven Scott Jun 16 '11 at 16:05
  • Hmm, only thing I can think of is some form of UID which the remote server can use to call back to receive data from yours.. if you dont have any way to get them todo that, sorry, I cant think of a way round that. Hope some others have better ideas. – BugFinder Jun 16 '11 at 16:15
  • Unfortunately, I do not have the ability to alter the remote server configuration or application at all. It is essentially a black box with a single door protected by HTTP Basic Auth. – Steven Scott Jun 16 '11 at 17:19

3 Answers3

4

Basic authentication details are encoded in the request header named "Authorization" from the client. The header contains the base64 encoded result of "username:password".

e.g. Aladdin:open sesame = Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

There are more details on the Basic Access Auth wikipedia page.

For basic authentication, the Authorization header needs to be added to every request. Usually the browser will take care of this after the user has entered their credentials into the dialog presented by the browser. If you want to avoid having your users enter these credentials, then your ASP.net server will need to sit in between the user and the Apache server (acting as a reverse proxy) adding the auth headers to every request that it forwards on behalf of your users.

It is not possible to simply visit your server once and for it to add a "token" to the request then redirect to the apache server. This approach would be possible if you were using forms/cookies for authentication and your servers presented themselves to the user as within the same domain (e.g. asp.domain.com & apache.domain.com) then the auth cookie could be set on the parent domain (e.g. domain.com) and shared - see Forms Authentication across sub-domains.

Assuming that the basic auth scheme on the Apache server is not something you can easily change, it seems like the reverse proxy is the best option. In the reverse proxy code, the HttpWebRequest is the means to create each request to the apache server and add the additional authentication headers to it.

.net will deal with encoding the credentials in the proxied request using something like:

RemoteServer remoteServer = new RemoteServer(httpContext);
HttpWebRequest request = remoteServer.GetRequest();
request.PreAuthenticate = true;
request.Credentials = new NetworkCredential(UserName, SecurelyStoredPassword);
Community
  • 1
  • 1
diffa
  • 2,986
  • 1
  • 22
  • 35
  • A proxy is an interesting idea. I kicked the tires on this yesterday and may test it further. The WebRequest idea (and WebClient and HTTPRequest) seems like an obvious solution until you realize that the page requests are originating at the server, so no Auth token is set in the browser allowing the user to be redirected with no further Auth prompts. – Steven Scott Jun 16 '11 at 17:33
  • I think proxy is the only way if the users dont have the credentials, but you want to give them access through your server. I have updated my answer to hopefully be clearer. – diffa Jun 16 '11 at 22:55
  • The reverse proxy problem gets a bit harder if the apache site has absolute (on-site) links. Then you have to worry about html rewriting. – diffa Jun 16 '11 at 23:08
0

Try using the url format https://username:password@example.com

Gray
  • 2,333
  • 1
  • 19
  • 24
  • I don't think this is well supported anymore (not to mention insanely insecure). – Rob Jun 16 '11 at 16:28
  • @Rob I'd like to see you site information that shows that's not supported, I think it's supported by every server even though it's one of those "no no"s according to spec docs. But in regards to insanely insecure there's nothing inherently insecure about that as long as the username/password are allowed to be owned by the user. – Chris Marisic Jun 16 '11 at 16:36
  • 1
    The username/passwords will be available in clear text in server request logs etc. I think some browsers will keep these URLs in their history too. It seems as though support in IE at least is removed (http://support.microsoft.com/default.aspx?scid=kb;[LN];834489) – diffa Jun 16 '11 at 16:42
  • I tried this. IE no longer supports it and FF pops up security dialogs. In addition, the user name and password cannot be known to the user since there is only a single pair securing the remote server. Knowing the credentials would allow a user to bypass my portal, which defeats the purpose on some levels. – Steven Scott Jun 16 '11 at 17:32
  • @Steven Scott that sounds like something that should be interacted with as a web service then. – Chris Marisic Jun 17 '11 at 14:16
0

Only other thing I can think of - if the page doesnt force its way out, load a page of their site in a frame, send it data+ controls, via javascript so it sends the login and so on. Might be feasible.

BugFinder
  • 17,474
  • 4
  • 36
  • 51