Build a cloud-identity aware IMS module wrapper site (using visual Studio 2013).

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”

To the default page, we added a division and within that a java script reference which pulls in .js files for a “Rapattoni-IMS” module. The latter is a set of backoffice resources. An event handler  for page load induces the module to self-render. No shown are argument on the URI reference to the module’s javascript which set “per-tenant parameters” – in order that a true SAAS experience is easily enabled. In a better implementation, we might learn the tenant from SSO…



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.


About home_pw

Computer Programmer who often does network administration with focus on security servers. Sometimes plays at slot machine programming.
This entry was posted in oauth. Bookmark the permalink.