WIF SDK, and Studio 2012...windows 2012 Server, etc

Question

I think folks know I love WIF (and the whole Microsoft SSO story). Its sensible, and not religious.

But there are "delivery" matters that can be improved.

Ive forced myself in the last 3 months to use only Windows 8, Windows server 2012, etc. Ive also read modern books... on SSO for the platform. ITs all very confusing.

It is possible to install WIF SDK, for studio 2012 on Server 2012. But, its a right royal pain.

It is possible to install the latest identity training kit, but once again, if you dont know to install the visual c++ libs (sp1) dont expect teh dependency manager to work (and install the prereqs).

It is possible to run SOME of the WIF SDK samples, on IIS. BUt, none of its uses the internal webserver or iis express 8. Its very confusing, "generational cap".

Quite what the relationship is between the wif sdk TEMPLATES installed into 2012 visual studio and the "identity and access tool" ... I dont know. I&A tool runs some kind of STS, with a little UI, for testing. How it relates to the STS project source previously generate dby WIF STS templates, I dont know.

Dont try to install the I&A tool per the instructions. It doesnt work (i.e. download and  click). Do use the etension manager of studio (which works fine).

Finally, Ive been reading books. One "cookbook" explains how to make an STS by injecting one's own servercedential "framework" into WCF. Another book explains how WIF works (which does the same, more comprehensively, exploiting the same WCF extensibility model).

And then there is the wonderful world of ACS v2, in which some training samples show how to use MVC for provisioning tenants of a companion app (shipping), while also provisioning a RP (+IDP) entities in the ACS world for said new tenant. the MVC patterns are explored, showing how "WIF + URL routing"  is supposed to be used, with the "enrollement app" using a common realm (which the audienceURI function enforces), but the "shipping app" uses "per-tenant realms" (which audience URI ACS verified doesnt enforce).

You know, If I had not spent 1+ year studying all this, Id be lost. And, I still cannot do it... though I can at least follow the code ...those who can (and just copy).

Then there is WebAPI and OAUTH, and then the OpenAUTH libs that come built into the default web app for studio 2012. They nicely do openid/oauth-style websso, but dont know how to make delegate tokens to actually go consume a google API, say, having done a google IDP websso session!

Just some user feedback - from someone who is very positive about it all, typically.

Answer 1

Yep, its a pain! I believe the 4.5 Identity SDK is still in beta (CTP?) so there is some expectation that things will go screwy.

Personally, I'm annoyed that the O+ libraries are included, but from the ASP.NET/VS team's point of view it makes lots of sense to have them in there. Get the developers set up with the most-used SSO platform out there (also the most hated IMO) quickly and easily. Since the libraries are not made by Microsoft the support is lacking and the documentation, while fairly good, is simplistic in some areas.

And since WIF is now fully part of 4.5 its now already a part of the ASP.NET projects. This act alone I hope will make the documentation better, but it may take a while.

Overall I agree with the pains you are feeling -- they could use a bit of work.

---

Developer Security MVP | www.syfuhs.net

Answer 2

I started a similar thread last November (http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/ec74c94d-e3e5-4cc8-94e4-8fd3ad4698f3) where Alan Smith advised me to look at http://thinktecture.github.com/.

Now, few months later, where .NET 4.5 includes WIF, I was hoping to find a different situation, but unless I missed something well hidden, every single tutorial, lab or sample is based on Visual Studio 2010. A good example is the collection "Windows Azure AD Access Control Service (ACS) 2.0 Code Samples" at http://code.msdn.microsoft.com/Windows-Azure-AD-Access-0dcde385.

Using Visual Studio 2012 requires the installation of the Identity and Access Tool (http://visualstudiogallery.msdn.microsoft.com/e21bf653-dfe1-4d81-b3d3-795cb104066e) adding a lot nicer interface for configuration of trust between the ASP.NET RP and ACS, but there is no example that show the use of this tool. Even most basic (almost canonical) sample

    "How to: Create My First Claims-Aware ASP.NET Application Using ACS"

at http://msdn.microsoft.com/en-us/library/gg429779.aspx is only Visual Studio 2010 based (see step 8 in that article).

Anyone with the hints how to get to same .NET 4.5 based samples?

---

Nik

Answer 3

As it often happens, few seconds after posting this I found the link Claims Aware MVC Application - which is precisely what I was after. 

Edited a day after: This is not what I hoped for; it is a finished sample, which does not use the Identity and Access tool to configure trust between ASP.NET RP and ACS

---

Nik

Answer 4

Don't know if this helps, but here's a post on how to use the SAM for modern claims-aware authentication (this example isn't using federation).

http://brockallen.com/2013/01/26/replacing-forms-authentication-with-wifs-session-authentication-module-sam-to-enable-claims-aware-identity/

---

Brock Allen http://brockallen.com | DevelopMentor http://www.develop.com | thinktecture http://www.thinktecture.com/

Answer 5

Thank you Brock - at the moment, I am after a sample that illustrates federated authentication with Google, Yahoo, Facebook and AD as shown in the sample http://msdn.microsoft.com/en-us/library/gg429779.aspx - using WIF version distributed as a part of .NET 4.5

---

Nik

Answer 6

Right -- so you're using federation and it looks as if you're doing it via ACS.

---

Brock Allen http://brockallen.com | DevelopMentor http://www.develop.com | thinktecture http://www.thinktecture.com/

Answer 7

Correct :-)

---

Nik

Answer 8

The requirements are trivially satisfied. No sample code is required. The requirements are satisfied by stable ACS and WIF libraries, in normal configuration. Setup ACS, per conventional means, to talk to the IDPs listed. If you want, add Azure AD to the list (rather than enterprise AD). One uses the ACS UI wizards for each, where AD and Azure AD leverage the IDPs' ws-fedp metadatas. Typically, I create a throw-away ACS RP registration, so ACS indicate URIs by which to test the IDPs at this point using a nothing more than a browser. A meaningless assertion sent to the RP's nominal-endpoint I goodnews, even though no RP actually exists. Launch visual studio 2012 to create a simple RP project. Use the project chooser to pick a classical asp.net webforms C# project type say, for internet applications. That is, it creates a classical forms-auth type project and web.config for you. Don't listed to religious of doctrinaire drivel about forms-auth being dead (since Elvis still lives on, if only as cover acts). Good stuff typically never dies, if used properly (to guard access to ASP.NET server side sessions). Assuming you have added the I&A tool to visual studio's toolbox, use it now, for said project. Point to the ACS metadata - citing its URI address. The ACS UI screens provide the ACS tenant's resource URI. Do host the project in IIS8 express, and do host the site on an https endpoint. Do ensure you have added the IIS express self-signed cert to the browser PC's trust store for root authorities. Ideally, ensure you can browse the IIS8-hosted https site BEFORE using the I&A tool. While none of these steps are requirements, they are conventions that typically make life easier to get set. Life is easier if you go to school before the bell, in school uniform, with your school books, looking like and talking like you care. But, you can also (in the US) go high on drugs, or pregnant, or concussed from yesterday's sports, if you must. Expect a harder time later on, if you choose the latter course. Having used the I&A wizard correctly, use the RP site. Note how the ACS UI of several IDPs is presented. If its not, you have done SOMETHING out of the ordinary, somewhere. Fix it. I am available for fixing at $1000 an hour (1 hour minimum, paid upfront, no refunds), for this. This fee covers the cost of 100 times I've been stupid on norms, and had to spend hours bringing myself into compliance with norms (at which points things work flawlessly, typically). Now install and invoke fiddler. Watch the HTTP flow. Identify the URL to which your project redirect the browser to the ACS site. Drop the URI onto fiddler composer window. You are about to alter it, so you have an "URI" interface to ACS. note that the forms-auth project's redirect generates no whr=XYZ parameter on the URI addressing ACS. You can now, however, add a value for XYZ - one of the keywords for an IDP (established in your ACS setup) that obviously denotes the IDP. Now go and make your own webapp code that formulates such redirect URI, one per IDP of choice. You have got the means now to remotely-control ACS. Yes, in some MVC applications in some cases, the I&A tool can make controllers and insert them into the webapp's controller-firing tree that formulate up the URIs as above, and present some local-chooser UI. But, there is little canonical about that pattern, being essentially demo-ware for teaching. What MATTERS is that protocol beneath all the UI is working.

Answer 9

I decided to add to this thread because I really liked your first post here. Now, I am even more impressed with your explanation above, as it shows lots of emotion and it was clearly written in a "single breath" indicating deep knowledge of this subject, knowledge achieved by persisting on a subject until it becomes crystal clear (This fee covers the cost of 100 times I've been stupid on norms, and had to spend hours bringing myself into compliance with norms)

My aim is a lot bigger than the context of my post, as I am just visiting any possible issue that will be relevant to deploy a large distributed application to Azure. You helped me a lot by typing the explanations above - a big thank you Peter Williams Security :-)

---

Nik