Visual Studio websso with MVC4, dotnet 4.5 identity model, and ACS v2

As promised, Microsoft delivered for the Visual Studio 2012 tool chain an addon (the “identity and access” tool) that empowers MVC web projects with WIF – the dotNet 4.5 variety, this time. ONe installs the tool using the Extensions and Updates command, in the Tools Menu.

To use the tool, create a new project using the MVC4 web application template, choosing the internet option. Then right click on the project and invoke the identity tool. Select the ACS option, form the list of types of IDPs.

Above, I assumed you have been to the access control portal in Azure and  had created yourself an ACS namespace.

If not, in summary you must create yourself a Federation provider service in the cloud, which bridges the MVC4 application to IDPs, of various types. From the new azure console, invoke the old ACS console by first viewing the old Azure portal (in which the ACS namespaces can be managed).

Creating a namespace creates the websso bridge – an agent in the Federation Provider role – to which the Windows Live IDP is automatically added as an IDP that an RP entity may be bound. You can see all this by clicking the big green button to go manage the entities in this namespace, including IDPs and RP (if any) bound to this bridge.

A brand new name space, e.g. trialrap, has no RP entities (i.e your MVC app is not registered). To link up your Visual Studio MVC RP project to this new service, collect the symmetric key from the console and apply it in the identity access control wizard:

Select Windows live and OK – to see the project automatically configure itself and its supports namespace. If you now return to the console (for trialrap, here), you can now add other IDPs to the RP entity just created for you, automatically:

Returning to the identity and access tools allows one to reconfigure the project  to accommodate multiple IDPs, now:

The net result in the MVC project is configuration that, on access, passes control to the ACS namespace:

since the dotnet framework’s built-in WIF extensions to ASP.NET were inserted into the modern pipeline::

We used our Google IDP (which presented the usual Google UI and consent experience): with the result being that the Google openid assertion id bridged by the ACS namespace into a ws=fedp response, that drives the WIF pipeline integration on the MVC application, producing:

Next, we armed the dotnetopen auth features of the MVC application.

We launched the application anew, choosing this time the windows live IDP.

which causes a failure …

…probably on the basis that the WIF features is just NOT supposed to be used with the account linking feature, armed once one adds the local Google capability! This code generator from the folks who actually know what they are doing doesn’t seem to improve much on the work I did myself, when adding to the SP the ability to talk to the Azure AD Directory IDP…similarly.

Anyways, lets see if we can fix it the same way as in our earlier effort by adding a suitable default claim mapper for the nameid:

    <securityTokenHandlers>
      <remove type=”System.IdentityModel.Tokens.Saml2SecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ />
      <add type=”System.IdentityModel.Tokens.Saml2SecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″>
        <samlSecurityTokenRequirement>
          <nameClaimType value=”http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier” />
          <roleClaimType value=”schemas.microsoft.com/ws/2006/04/identity/claims/role” />
        </samlSecurityTokenRequirement>
      </add>
    </securityTokenHandlers>
  </identityConfiguration>
</system.identityModel>

Since that doesn’t work any better, lets map the claim at ACS into a name (rather than nameid), first  removing our altered saml2 token handlers change:

This gets us passed the initial flaw, and we see something novel – along with such excellent IDE support (well done!) on how to address the programming issue:

A brief review of http://brockallen.com/2012/07/08/mvc-4-antiforgerytoken-and-claims/ tells us what to do. So we add:

:

And so finally, we get the masked id (per RP) from windows live, driving the UI, as expected:

Going to the management page (click on the name), we have some strange behavior – in that the password mechanism fails to persist the change.

Using the Google name federation option (“external login”) seems unlike to work either – probably because there is no actual membership or binding record been setup, in the WIF flow. Even the logout button doesn’t work, even for local logout!

Using the Google option gets to an old friend (this time cued off failure to recognize, correctly, the WIF name claim from Windows LiveID)

On a hunch, lets put forms auth handlers back into the pipeline – since we have two technologies conspiring against each other, each assuming a different mechanism of ticket management:

This gets us to the local OAUTH-centric apparatus, and when we use the Google button… it happens now to goto ACS (!) – as somehow the WIF pipeline suddenly kicks in. ANyways, once granted a WIF session (see above), we once again get toe the google account linking experience, which does go to Google (not ACS!). Looking at our old friend, we see the simplemembershipprovider from the webmatrix class is fussy

 

Could it be that the particular OAUTHClient tied to the Google provider somehow registers a membership provider that is somehow fussy about name forms (any why not, given the NSTIC goals, concerning “verified emails”)?

anyways, lets remove the offending lines, and fall through to the register account view – since the create user account seems tied up with non WIF logic:

using from ACS the google account, we fall through to a screen where we choose the user name:

Anyways, things really don’t work, and we can guess that the simple membership provider is tied for a formsauth principal/identity specifically rather than the IIdentity interface, somehow, given for a normal flow:

does this imply we should in WIF flow manufacture ourselves a RolePrincipal and FormsIdentity(sourced to the WIF session/User object)?

This leads us to understand the current mess concerning old membership framework and the new framework, depending on project type (sigh!). I’m glad… we always chose to avoid all this part of the microsoft libraries, since it all seems so half baked, and unfinished 10 years later…). Always wait 2 years before using any membership or login stuff… is the rule. NEVER FORGET

Anyways, we learn a lot from http://weblogs.asp.net/jgalloway/archive/2012/08/29/simplemembership-membership-providers-universal-providers-and-the-new-asp-net-4-5-web-forms-and-asp-net-mvc-4-templates.aspx and the associated http://blog.osbornm.com/archive/2010/07/21/using-simplemembership-with-asp.net-webpages.aspx.

Lets make all the account controllers accessible to the anonymous user (hoping not to cause the WIF interceptors to intercede):

Now, the clicking on Google does invoke the OAUTH process (not WIF!). OK. its time to go back to our webrole project where we started to emulate a WIF FP in an OAUTH custom client. This is going nowhere…