Windows Live with e-mail through Azure Access Control Service

Question

I am trying to allow users to sign in to the ASP.NET MVC web site with their Google, Facebook, and Windows Live accounts. I am currently using the Azure App Fabric ACS, which made it almost too easy. The catch is I need the e-mail address. Google and Facebook provide the e-mail as a claim, but Windows Live doesn't. From the LiveConnect site it seems like this is easily possible using the wl.basic (to get the user's name) and wl.emails (to get the user's email address) scopes, but I haven't been able to influence the ACS in order to obtain this information. I also tried implementing the OAuth2 web server flow to get it from my site after the user has signed in. I was able to get the information I needed, but I became stuck in an infinite loop of signing on because the FedAuth cookies were removed when I redirected to https://oauth.live.com/authorize to start the flow. Has anybody been able to get this to work (on the server side)? Should I just scrap the ACS altogether and provide a custom page with uses the custom code from each provider to enable sign in?

I retrofitted a previous demo (blog engine ala smarx) with the code so that I wouldn't have to expose anything proprietary. In my web.config FedUtil has inserted the following:

<httpModules>
  <add name="WSFederationAuthenticationModule" type="Microsoft.IdentityModel.Web.WSFederationAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
  <add name="SessionAuthenticationModule" type="Microsoft.IdentityModel.Web.SessionAuthenticationModule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</httpModules>

I removed the deny all users

But I have a particular action method (post of a new blog) that forces users to be authorized

    [Authorize]
    public ActionResult New()
    {
        var principal = Thread.CurrentPrincipal as IClaimsPrincipal;
        if (principal == null)
            return new HttpStatusCodeResult(403);

        // if this is a Windows Live User we have more work to do 
        string redirectUrl = CheckForWindowsLiveUser(principal);
        if (redirectUrl != null)
        {
            return Redirect(redirectUrl);
        }

Inside the New request the first time the cookies (FedAuth and FedAuth1) have been filled in. After the redirect comes back they are gone. I haven't done anything to the session provider (maybe I should).

score 1 · Answer 1 · answered Jun 30 '14 at 19:05

In my case, the issue was caused by an incorrect configuration of the domain names between ACS, the Windows Live application, and the URL I was using to access the site. In development, I was using a single host name, localhost, for all of my redirections. However, Windows Live application API settings do not allow the localhost domain and so I used a host entry to work around it, myapp.localhost. The cookies were correctly being set on the ACS logon redirect (localhost) and, also correctly, not being sent on the authorization redirect (myapp.localhost) because the domains were different.

Incorrect

Development URI: http://localhost/app

ACS Redirect URI: http://localhost/app/sso

Windows Live Connect Authorization Redirect URI: http://myapp.localhost/app/sso/authorizations

Correct

Development URI: http://myapp.localhost/app

ACS Redirect URI: http://myapp.localhost/app/sso

Windows Live Connect Authorization Redirect URI: http://myapp.localhost/app/sso/authorizations

score 0 · Answer 2 · answered Mar 18 '12 at 23:59

I think you're on the right track with oauth2 and live connect and it should be possible to solve your infinite loop issue. Where in your site's code are you performing your redirect to oauth.live.com/authorize? I think at the very least, it must happen after the user completes a full conventional sign-in to LiveID via ACS.

Take a look at this blog post for context

If your site is making the oauth.live.com/authorize call before step 5, before WIF has the chance to establish a session, then you'll get this infinite loop.

However, if you wait until step 6, then your FedAuth cookie should be written and the user has a session established. You should be able to make a further redirect to oauth.live.com/authorize to collect the user's email without risk of an infinite loop. The user will be prompted by live connect about releasing emails the first time, but this should be seamless. The other advantage is at step 6 you have the ACS token available in HttpContext.User.Current, you can make use of the IdentityProvider claim that ACS issues, since you only need to make this further oauth redirect when IdentityProvider == LiveID.

It is getting past step 6 because I am getting the cookies back from the result of the authentication. I edited the post above to include a more concrete description of what I am doing. — sreed, Mar 19 '12 at 16:53
Hmm I see. I think it would help to see a fiddler trace (fiddler2.com) of this to see when exactly the cookie is being written and when it disappears. — Andrew Lavers, Mar 24 '12 at 16:00

Windows Live with e-mail through Azure Access Control Service

2 Answers2