WIF and MVC – How it works

I got a few questions from people on how the “Federation with Multiple Partners” sample of the guide works, so I figured I would just write it down in one place for eternity.

The guide explains all sequence in quite some detail (see pages 88 to 97), but sometimes a diagram is more helpful, so here’s a sequence diagram that describes all interactions:



  1. An un-authenticated user browses a protected resource, say the “Shipping” page (which translates into a method in a Controller).
  2. The Controller is decorated with the AuthenticateAndAuthorizeAttribute which implements MVC’s IAuthorizationFilter interface. Because the user is not authenticated yet, it will issue a SignInRequest to the configured issuer (this results in a redirection to the issuer). Among other tings it passes the user original URL in the context (wctx) of the request (in this example is the “Shipping” page).
  3. The Issuer authenticates the user with whatever means and if successful, it issues a token for the user for that application.
  4. The Token and the the context information is passed back to the app to a specific destination (indicated in the realm). In the MVC application, this is just another controller (“Home” in our sample, method “FederationResult”). This controller is not decorated by the AuthenticateAndAuthorizeAttribute.
  5. The request however, does go through the WIF Module (the “FAM” in the diagram above). WIF will validate the token and create a ClaimsPrincipal that is eventually passed on to the controller.
  6. The Home Controller inspects the context parameter, extracts the original URL (remember the context is preserved throughout all hops) and then redirects the user there.
  7. The redirect will go again through the filter, but this time the user is authenticated.
  8. Any authorization rules are performed (in our example, we checked for specific Roles) and if all checks pass…
  9. The specific controller is finally called (e.g. Shipping).

A couple notes:

Everything within the green box above happens only when there’s no session established or when the session expires. Once there’s a session, the requests only go through the filter.

In our sample, there’re actually two Issuers. This is because the sample deals with “Multiple Partners” each one with its own Identity Provider, a scenario that makes convenient to have another intermediate Issuer (a.k.a. “Federation Provider”). I didn’t add it in the diagram above just to keep things simple and focus on the specifics of MVC and WIF.

Because the protocol uses redirections, interactions in the diagram above are “logical”. Whenever you see an arrow with “redirection” label, what actually happens is that the response is sent to the browser and then the browser initiates the interaction with whatever you are redirected to:




In our sample we chose to use “roles” as a way of providing access:


But it should be clear that you could use anything. Repeat: “roles are claims, but not every claim is a role” 🙂

Also, this declarative model might not always work. You might have to make decisions on the parameters of the call, and since you have access to the claims collection (through the principal), you can programmatically use them for more advanced behavior. Using roles is just convenient for an examples.

Comments (8)

  1. Russ Cam says:

    Is there anything in the WIF SDK that can be used in an ASP.NET MVC similar to the FederatedPassiveSignIn control? For example, Users attempting to access a restricted resource would be redirected to a login action on a LoginController with a view providing username and password fields along with a submit button. Upon submit, a request would be sent to an STS for authentication (in a similar fashion to how the control does so), supplying the username and password to be used in the authentication process. In essence, keeping the login screen/view as part of the application as opposed to FAM redirecting to an ASP.NET STS that contains a login screen. Are there components in the WIF SDK to easily do this?

  2. Thanks Russ,

    Why do you want to keep user/pwd screen in the application?

    The whole point of federation is to get rid of any authentication in the app.

    But, you can have your own STS with the login screen that you can customize as you wish.

    Makes sense?


    BTW, I don’t think FederatedPassiveSignin gives you user/pwd controls.

  3. Russ Cam says:

    My thinking behind keeping the actual login screen within the application is for look and feel. For example, say I am a large business that owns a number of brands (within the same market). Ideally, I like possibly to have to implement only one STS for authenticating users to sites associated with my different brands. How could this be handled by delegating the login screen to an STS? Could I have multiple login URLs for an STS, with each URL being associated with a different brand and styled according to that brand?

  4. Eugenio Pace says:


    You would only implement your *own* STS if the customer using your applciation doesn't have an identity provider. If you sell your service to a big company (like Microsoft), then you would have your application trust such company's STS not yours. Otherwise you'd be defeating the purpose of externalising Authentication.

    (its employees would have 2 distinct username/passwords: one for MSFT and one for your system).

    Makes sense?

    For campnies with NO STS of their own, then you would roll out your STS (with your custom look and feel) and have your app rely on that for authentication. From an app perspective, it's completely decoupled and independent.

    re: "Could I have multiple login URLs for an STS, with each URL being associated with a different brand and styled according to that brand?"  The answer is yes.

    Happy to follow-up on e-mail. Contact me through the blog if you are interested.

  5. Russ Cam says:

    Thanks Eugenio. I have a few more questions, so I'll fire over an email with them. Really appreciate your time in resolving my questions 🙂

  6. Vasilio Ruzanni says:

    Well, if I understand it right Russ wants to have a "login/passwd" form at his site (sites) index page(s) just for user convenience. User may want to login right here and right now on a particular page while reading something and suddenly desired to leave some comments.

    This is what I'm interested too in context of using WIF with ASP.NET MVC.

    Is it clearly possible to support such a transparent scenario?:

    – you have a login form right on the every page of your site

    – you want to allow user to login whenever he wants

    – you want it without any user redirection (visually), user had to just put login/passwd in a form on a page which just refreshes and conceals all the movings behind itself (like STS working somewhere on background user would never see but it is used by RP-app itself)

    – the desire is not to have the same look and feel of STS but to have a form on your page (along with other elements) and to let zero-friction login for user.

    P.S. Hope I described the problem right 🙂

  7. John says:


    I am using MVC app with adfs for auth..

    from reading msdn.microsoft.com/…/ff359105.aspx. which you talk about in a post


    "passiveRedirectEnable=true In a MVC app you will turn that off and handle that programmatically as explained in my blog post. – In an MVC app you typically implement an IAuthorizationFilter attribute. In Web forms, that doesn't exist and you simply rely on the existing ASP.NET authorization mechanism (or call IsInRole, etc) "

    I am geting "ID3206: A SignInResponse message may only redirect within the current web application: '/[APP]' is not allowed"

    Does this mean i have to modify my web.config making passiveRedirectEnable=false. and create an AuthenticateAndAuthorizeAttribute class and annoate all my controllers with It..

    like when they type in https://domain.com/[myapp] – they should just get to the default homecontroller..

    I think we dont want to use the claims/roles for authorization, we will build our own security permissions module.. I really just want adfs to do the authentication.

    It seems very overkill that this doenst work out of the box. The claims aware application seems to be simple enough to use, but try with MVC and whole other ballgame.

    Any help would be greatly appreciated.



  8. Pete says:


    At my company we're using MVC 2 webapps as RPs and ADFS 2.0 for authentication. We have passiveRedirectEnable=True and our Custom IAuthorize Attribute simply throws an HttpUnauthorizedException when the user isn't authenticated and it's working fine.

    I've seen several posts/articles that state that you need to set passiveRedirectEnable=False and handle the redirecting in a custom IAuthorize attribute. Why? We're not doing that and it's working fine. Where is this information coming from?