Welcome to the first walkthrough of the new WIF tools for Visual Studio 11 Beta! This is about using the local STS feature to test your application on your dev machine.
Let’s say that you downloaded the new WIF tools (well done! ) and you are itching to see them in action. Right away good Sir/Ma’am!
Fire up Visual Studio 11 as Administrator (I know, I know… I’ll explain later) and create a new ASP.NET Web Form Application.
Right-click on the project in Solution Explorer, you’ll find a very promising entry which sounds along the lines of “Identity and Access”. Go for it!
You get to a dialog which, in (hopefully) non-threatening terms, suggests that it can help handling your authentication options.
The default tab, Providers, offer three options.
The first option sounds pretty promising: we might not know what an STS exactly is, but we do want to test our application. Let’s pick that option and hit OK.
That’s it? There must be something else I have to do, right? Nope. Just hit F5 and witness the magic of claims-based identity unfold in front of your very eyes. (OK, this is getting out hand. I’ll tone it down a little).
As you hit F5, keep an eye on the system tray: you’ll see a new icon appear, informing you that “Local STS” is now running.
Your browser opens on the default page, shows the usual signs of redirection, and lands on the page with an authenticated user named Terry. Ok, that was simple! But what happened exactly?
Stop the debugger and go back to the Identity and Access dialog, then pick the Local Development STS tab.
The Local STS is a test endpoint, provided by the WIF tools, which can be used on the local machine for getting claims of arbitrary types and values in your application. By choosing “Use the local development STS to test your application” you told the WIF tools that you want your application to get tokens from the local STS, and the tools took care to configure your app accordingly. When you hit F5, the tools launched an instance of LocalSTS and your application redirected the request to it. LocalSTS does not attempt to authenticate requests, it just emits a token with the claim types and values it is configured to emit. In your F5 session you got the default claim types (name, surname, role, email) and values: if you want to modify those and add your own the Local Development STS tab offers you the means to do so, plus a handful of other knobs.
What does this all mean? Well, for one: you no longer need to rely on the kindness of strangers (i.e. your admins) to set up a test/staging ADFS2 endpoint to play with claim values; you also no longer need to create a custom STS and then modify directly the code in order to get the values you need to test your application.
Also: all the settings for the LocalSTS come from one file, LocalSTS.exe.config, which lives in your application’s folder. That means that you can create multiple copies of those files with different settings for your various test cases; you can even email values around fro repro-ing problems and similar. We think it’s pretty cool
Now: needless to say, this is absolutely for development-time and test-time only activities. This is absolutely not fit for production, in fact the F5 experience is enabled by various defaults which assume that you’ll be running this far, far away from production (“you don’t just walk in Production”). In v1 the tools kind of tried to enforce some production-level considerations, like HTTPS, and your loud & clear feedback is that at development time you don’t want to be forced to deal with those and that you’ll do it in your staging/production environment. We embraced that, please let us know how that works for you!
Don’t forget to check out the other walkthroughs: the complete series include Using the Local Development STS, manipulating common config settings, connecting with a business STS, get an F5 experience with ACS2.