Using the just-released (enterprise) version of Visual Studio 2013, we created a (2013-era) web forms project, hosted in IIS express. The setup wizard required us to choose an authentication mechanism, which was selected to be “none”
As we see above, the “member Profile” module renders under the “IMS” title. The rendering code detects that the browser fails to present a suitable session cookie. It thus renders both a popup indicating this fact (not shown) and thereafter a login control (as shown).
Our next goal is to augment this project with ws-fedp SSO, in order that an IDP delivers an assertion that not only induces creation of a webapp session (using WIF mechanism for maintaining WIF-sessions) but also happens to deliver a particular attribute (opaque to WIF): session-ID. This value will (once cast suitably as a cookie) unlock the guard that currently, being locked due to the absence of the cookie, induces the login form for the membership profile module.
Before we delve further, we decide to abandon this non-SSO-enabled web forms demo and start again – this time requesting that the 2013-era web forms project wizard create a “multiple-cloud” SSO authentication-ready project. This will allow us not only to inherit working SSO but also the oauth-powered mechanism that enables several subsequent IDPs (logically “realty partners”) to federate wit the main IDP guarding this site. Under the control of the OAUTH consent process, these parties will signup to then supply identities of user – who will presumably be allowed to access the page bearing the IMS module. Of course, the assertions of such identities will still need to convey a netmagic-specific-sessionid (to unlock the guard on the resource). But let’s now see how such logic plays out.