Set up STS but keep formsauthentication in webapp

I'm enabling an windows identity foundation on an existing webapp.

I want to mess as little as possile with the existing code so I would like to the login page which uses formsauthentication left in the application and I just connect with the STS if the user enters the application via a specific page e.g "im_comming_from_some_other_site.aspx".

in the "im_comming_from_some_other_site.aspx" the code would be like:

Page_Load(...)
{
   if(verifyAgainstSTS()
   {
        FormsAuthentication.SetAuthCookie(<some_STS_Userid), ...)
        Response.Redirect("default.aspx")
   }
   else
   {
        Response.Redirect("http://<STS_server_name/<STS_service...etc>")
   }
}

Is there someone who knows if this may be done and how? Any links to example code (if available) deeply appreciated.

(Of course some code would be needed when to determine what to do when the authentication is timed out; either go to local login page or goto STS-login page)

I know this may seem like a bad design, not going all the way with STS, but I need to implement this ASAP and I want to keep the original site as untouched as possible.

It is not a bad design, it's your requirement and you try to fulfill it. We have working system built like that and it's not a rocket science. The only difference is that we switch it to forms/sam statically (via global settings), not dynamically.

Anyway, you keep your forms authentication in web.config so that when there's no authorization for current user, forms redirects the request to the login page.

In the login page you have two options. One creates the forms cookie somehow. The other option involves WIF's FederatedPassiveSignIn control.

If a user follows forms authentication, the cookie is set and you are done. If a user follows the STS login control, sooner or later he/she will come back with valid SAML token. The FederatedPassiveSignIn will pick it up automatically and you just handle the redirect in the SignedIn event.

You will even not need the if you mention in your question.

There's one caveat from what I remember. When a user is authenticated by STS, the WS-Federation cookie is created, you can read claims etc. Everything works.

However, if a user is authenticated by forms, the SAM (SessionAuthenticationModule) will REPLACE forms cookie by the WS-Federation cookie in ASP.NET pipeline upon EACH request (I guess it's because the SAM is later in the pipeline that forms authentication module).

This will NOT blow up your context.User.Identity.IsInRole(...) also authorization works correctly because SAM will copy user roles to corresponding claims.

However, if at any place in your code you try to extract information directly from the forms cookie (instead of using general APIs), you could find out that the forms cookie is not present even if the user was authenticated by forms in first place (and the cookie is not present because it will be replaced by the WS-Federation cookie).