2
votes

We have a non-SSL ASP.NET web app that allows a user to login (ASP forms authentication, inproc).

Once authenticated, we redirect their browser to an external, SSL secured page on another web site / domain altogether that we do not control.

The client is redirected back to a pre-configured url on our original http web app when done.

However, the customer is then asked to "re-login" again on our side which is undesired...

It seems the forms authentication cookie is destroyed when transitioning between HTTP and HTTPS and back again.

How can I keep the forms authentication cookie alive so that the customer does not have to re-authenticate on the round trip?

3
FYI: The remote SSL site uses ASP, our site uses ASP.NET.Konrad

3 Answers

1
votes

It's not being destroyed; you're not authenticating on your domain, so the cookie's not being set on your domain, and thus requests on your domain will not contain said authentication cookie.

This is GOOD. If this didn't happen, then every cookie from every domain you ever visited would get sent with every request. Which is obviously 1) crazy and 2) a security hole. Setting a cookie on mydomain.com should never be visible to pages on myotherdomain.com.

If you're using a 3rd party authentication system, like google, facebook, etc, they'll all have some sort of callback token that you'll have to process and set your own cookies.

1
votes

Consider to set cookie's domain property for your cookies with more specified can be found here or try this code:

Response.Cookies["your_cookie_name"].Domain = "yourdomain.com";
0
votes

You're looking for a Single Sign On solution. It might be a little overkill for your problem, for which you might just want to get the same domainname. But if that isn't an option you might want to take a look at: Windows Identity Foundation