Windows Live с электронной почтой через службу контроля доступа Azure - PullRequest
Новая
       53

Windows Live с электронной почтой через службу контроля доступа Azure

0 голосов
/ 18 марта 2012

Я пытаюсь разрешить пользователям входить на веб-сайт ASP.NET MVC с помощью учетных записей Google, Facebook и Windows Live.В настоящее время я использую ACS Azure App Fabric, что делает его почти слишком простым.Подвох мне нужен адрес электронной почты.Google и Facebook предоставляют электронную почту в качестве претензии, а Windows Live - нет.С сайта LiveConnect кажется, что это легко сделать, используя области wl.basic (чтобы получить имя пользователя) и wl.emails (чтобы получить адрес электронной почты пользователя), но я не смог повлиять на ACS в порядкеполучить эту информацию.Я также попытался реализовать поток веб-сервера OAuth2, чтобы получить его со своего сайта после того, как пользователь вошел в систему. Мне удалось получить необходимую информацию, но я застрял в бесконечном цикле входа в систему, поскольку куки-файлы FedAuth были удалены, когдаЯ перенаправил на https://oauth.live.com/authorize, чтобы начать поток.Кто-нибудь смог заставить это работать (на стороне сервера)?Должен ли я просто отказаться от ACS и предоставить пользовательскую страницу с использованием пользовательского кода от каждого провайдера, чтобы разрешить вход?

Я модифицировал предыдущую демонстрацию (движок блога ala smarx) с кодом, чтобы я не смог 'Не нужно выставлять что-либо частное.В мой web.config FedUtil вставил следующее: 

<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>

Я удалил запретить всех пользователей

Но у меня есть определенный метод действия (сообщение из нового блога), который заставляет пользователейбыть авторизованным 

    [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);
        }

Внутри запроса New при первом заполнении файлов cookie (FedAuth и FedAuth1). После возвращения перенаправления они исчезают.Я ничего не сделал с провайдером сеансов (может быть, я должен).

Ответы [ 2 ]

1 голос
/ 30 июня 2014

В моем случае проблема была вызвана неправильной настройкой доменных имен между ACS, приложением Windows Live и URL-адресом, который я использовал для доступа к сайту. В процессе разработки я использовал одно имя хоста localhost для всех своих перенаправлений. Однако настройки API приложения Windows Live не разрешают использование домена localhost, поэтому для обхода я использовал запись хоста myapp.localhost. Файлы cookie были правильно установлены при перенаправлении входа в систему ACS (localhost), а также правильно не отправляются при перенаправлении авторизации (myapp.localhost), поскольку домены были другими.

Некорректное 

Development URI: http://localhost/app

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

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

Корректное 

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
0 голосов
/ 19 марта 2012

Я думаю, что вы на правильном пути с oauth2 и live connect, и должна быть возможность решить проблему с бесконечным циклом.Где в коде вашего сайта вы выполняете перенаправление на oauth.live.com/authorize?Я думаю, по крайней мере, это должно произойти после того, как пользователь завершит полный обычный вход в LiveID через ACS.

Взгляните на это сообщение в блоге для контекста

Если ваш сайт выполняет вызов oauth.live.com/authorize до шага 5, прежде чем WIF сможет установить сеанс, вы получите этот бесконечный цикл.

Однако, если вы подождетедо шага 6, тогда ваш файл cookie FedAuth должен быть записан, и пользователь установил сеанс.Вы должны иметь возможность сделать еще одно перенаправление на oauth.live.com/authorize, чтобы собирать электронную почту пользователя без риска бесконечного цикла.При первом подключении пользователю будет предложено опубликовать электронную почту, но это должно быть без проблем.Другое преимущество состоит в том, что на шаге 6 у вас есть токен ACS, доступный в HttpContext.User.Current, вы можете использовать утверждение IdentityProvider о том, что ACS выдает, поскольку вам нужно только перенаправить этот дополнительный oauth, когда IdentityProvider == LiveID.

...