共用方式為

Windows Identity Foundation Tools for Visual Studio 11 Part II: Manipulating Common WIF Settings From the UI

  • 發行項

Welcome to the second walkthrough of the new WIF tools for Visual Studio 11 Beta! This is about using the tools to modify common settings of your app without editing the web.config.

The complete series include Using the Local Development STS, manipulating common config settings, connecting with a business STS, get an F5 experience with ACS2.

Let’s say that you downloaded the new WIF tools (well done! Smile) and you went through the first walkthrough, and you are itching to go deeper in the rabbit’s hole. Pronto, good Sir/Ma’am!

Let’s go back to the tool and take a look at the Configuration tab. What’s in there, exactly?

In V1 the tools operated in fire & forget fashion: they were a tool for establishing a trust relationship with a WS-Federation or WS-Trust STS, and every time you opened them it was expected that your intention was to create a new relationship (or override (most of) an existing one).

The WIF tools for .NET 4.5 aspire to be something more than that: when you re-open them, you’ll discover that they are aware of your current state and they allow you to tweak some key properties of your RP without having to actually get to the web.config itself.

The main settings you find here are:

  • Realm and AudienceUri
    The Realm and AudienceUri are automatically generated assuming local testing, however before shipping your code to staging (or packaging it in a cspack) you’ll likely want to change those values. Those tow fields help you to do just that.
  • Redirection Strategy
    For most business app developers WIF’s default strategy of automatically redirecting unauthenticated requests to the trusted authority makes a lot of sense. In business settings it is very likely that the authentication operation will be silent, and the user will experience single sign on (e.g. they type the address of the app the want, next thing they see the app UI).
    There are however situations in which the authentication experience is not transparent: maybe there is a home realm discovery experience, or there is an actual credentials gathering step. In that case, for certain apps or audiences the user could be disoriented (e.g. they type the address of the app the want, next thing they see the STS UI). In order to handle that, the tool UI offers the possibility of specifying a local page (or controller) which will take care of handling the authentication experience. You can see this in action in the ClaimsAwareMVCApplication sample.
  • Flags: HTTPS, web farm cookies
    The HTTPS flag is pretty self-explanatory: by default we don’t enforce HTTPS, given the assumption that we are operating in dev environment; this flag lets you turn the mandatory HTTPS check on.
    The web far cookie needs a bit of background. In WIF 4.5 we have a new cookie transform based on MachineKey, which you can activate by simply pasting the appropriate snippet in the config. That’s what happens when you check this flag.

image 

Those are of course the most basic settings: we picked them because how often we observed people having to change them. Did we get them right? Let us know!

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.

Comments

  • Anonymous
    October 03, 2012
    Checking the RequireHttps seems to have no difference on the LocalSTS.exe hosting URL. I was assuming it will host the STS on a Https endpoint. Is there any way to host LocalSTS.exe on a HTTPS endpoint. The July2012 Identity Training Kit's  lab ACS2Federation tries to configure LocalSTS.exe as an IdP in ACS, but it fails as ACS expects all IdPs to be available on https endpoints.