Federated authentication application that also reads Forms cookie

Question

At our company we are planning to move our IIS applications from forms based authentication to federated authentication. We want to move one application first (big bang is difficult). All applications currently share a forms cookie (in the same domain,
same IIS server). I am looking for a way to move one application to federated authentication while still supporting users that are logged in with forms authentication.
I am thinking about the following scenario's:
IIS application 'A' has federated authentication configured (ADFS)
IIS application 'B' has forms authentication.
User request page in iis app 'A'   -> authentication mechanism checks if a forms cookie from app 'B' exists. (form cookie exists because user has already logged in via username/password webform in app 'B')
If yes, the info in this cookie is used to build a valid claim (custom code), federated cookie is set with  this claim.  User session can start 
If no, claim is obtained via ADFS server, federated cookie is set with claim. User can start session.
In this way, users that are authenticated via Forms authenticated are supported in an application that is configured for ADFS claims. That gives us the possibility to gradually move all users from our custom security system (based on .net forms) to AD.
How can this be done?
Bert-Jan

Answer 1

The legacy forms logon (non-federated) with the cookie is independent of the federated logon process. You can always stand-up a separate IIS website (federated) to point to your application in a side-by-side capacity, thereby meeting the requirement for
federated logon (assuming the application supports that) and legacy forms, but crossing trust boundaries between the legacy and federated logon for SSO purposes is not possible OOTB. If you want AD FS to issue claims from the "classic" forms logon
alternate, then that forms logon provider would need to also be a trusted claims provider and possess its own Security Token Service. In general I try, and emphasis on the word try ;-), to shy away from customizing AD FS logon screens, primarily because it
can come back and bite you. While AD FS 2.0 provided some latitude for these sorts of practices, AD FS 3.0 (and beyond) does not ...
http://blog.auth360.net