Windows phone 8 development & WebAPI - аутентификация через формы auth?

Question

Я создаю API с WebAPI, который будет принимать информацию аутентификации через SSL через HTTPS от клиента веб-браузера. Веб-браузер использует проверку подлинности форм и требует HTTPS, чтобы он мог безопасно отправлять имя пользователя/пароль конечной точке API. Мой API использует Websecurity.Login() и Websecurity.Logout() для проверки подлинности для веб-клиента.

Как это можно обработать в приложении WP8/универсальном приложении, построенном с помощью WinJS? Могу ли я сделать то же самое - отправить учетные данные для входа/регистрации через HTTPS и использовать Websecurity для обработки форм auth?

Вот как мой WebAPI в настоящее время настроен для идентификации:

public HttpResponseMessage LogIn(LoginModel model) 
{ 
    if (ModelState.IsValid) 
    { 
     if (User.Identity.IsAuthenticated) 
     { 
      return Request.CreateResponse(HttpStatusCode.Conflict, "already logged in."); 
     } 

     if (WebSecurity.Login(model.UserName, model.Password, persistCookie: model.RememberMe)) 
     { 
      FormsAuthentication.SetAuthCookie(model.UserName, model.RememberMe); 
      return Request.CreateResponse(HttpStatusCode.OK, "logged in successfully"); 
     } 
     else 
     { 
      return new HttpResponseMessage(HttpStatusCode.Unauthorized); 
     } 
    } 

    // If we got this far, something failed 
    return new HttpResponseMessage(HttpStatusCode.InternalServerError); 
} 

public HttpResponseMessage LogOut() 
{ 
    if (User.Identity.IsAuthenticated) 
    { 
     WebSecurity.Logout(); 
     return Request.CreateResponse(HttpStatusCode.OK, "logged out successfully."); 
    } 

    return Request.CreateResponse(HttpStatusCode.Conflict, "already done."); 
} 

Является ли этот подход совместим с WP8 или другой родной аутентификации развития мобильных приложений?

Answer 1

Это определенно работает, предполагая, что последовательные запросы несут cookie, который прилагается к первому запросу к действию Login.

В случае браузера, использующего ajax, это работает из коробки, так как последовательные запросы ajax несут все файлы cookie, выпущенные одним и тем же доменом и добавленные в текущий сеанс браузера.

В случае родного приложения это может быть запутанным, поскольку это означает, что нужно использовать один и тот же экземпляр прокси-сервера клиента, или вы найдете способ иметь временное локальное хранилище для файлов cookie для аутентификации и добавлять эти файлы cookie к каждому запросу.

Однако существует потенциальный недостаток этого запроса: вы предполагаете, что метод входа в систему может использовать логин/пароль в активном сценарии для создания форм cookie. И это не всегда так просто.

Это связано с тем, что ваш сайт потенциально может быть объединен с внешним провайдером идентификации (ADFS, Azure Active Directory, Google, Facebook и т. Д.), Чтобы фактическая проверка подлинности происходила на другом веб-сайте, и ваш сайт получает ответ, который соответствует к используемому протоколу единственного знака (OAuth2, WS-Federation).

В таком случае, действительно, нет простого способа использовать парную логин/пароль на стороне сервера, чтобы получить личность пользователя.

Обходной путь в таком случае, когда поставщик идентификации неизвестен, заключается в размещении элемента управления веб-браузером (если это возможно) и позволяет ему выполнять сценарий пассивной аутентификации, что означает, что вы переходите на страницу приложения и позволяете веб-браузеру автоматически контролируйте 302 на странице входа, независимо от того, сколько переадресаций требуется. Затем пользователь предоставляет учетные данные на странице поставщика, а веб-браузер перенаправляет все обратно в ваше приложение, и именно там вы поймаете личность на стороне сервера, закройте элемент управления веб-браузером и каким-то образом (в зависимости от фактического хоста веб-браузера) прочитайте файл cookie для проверки подлинности, чтобы его можно было присоединить к дальнейшим запросам.

Звучит сложно, но мы нашли несколько сценариев федерации, где фактические протоколы SSO между сторонами не были гарантированы, и такое симуляция пассивного сценария из встроенного веб-браузера была единственным надежным способом.

Answer 2

Я использую WebAPI сделать формы AUTH с помощью JS, это как с CORS

контроллер украшают (если вам нужно использовать CORS) (думаю, что вам может понадобиться пакет NuGet для этого).

[EnableCors(origins: "*", headers: "*", methods: "*")] 

После того, как ваш доволен мандатной набор печенья

FormsAuthentication.SetAuthCookie 

Это Ajax для страницы HTML,

$.ajax({ 
    type: 'Post', 

    url: 'http://' + api + '/?alloworigin=true', 
    data: { Username: "test", Password: "test12" }, 
    dataType: 'json', 
    xhrFields: { 
     withCredentials: true 
    }, 
    success: function(data) { 
     var x = data; 
    }, 
    error: function(msg) { 
     alert(msg.responsetext); 
    } 
}); 

Тогда любой аутентификации, украшенных контроллер можно получить, куки затем направляется по каждому запросу

[Authorize] 

кричать, если у вас есть вопросы.

Microsoft_Press_eBook_Programming_Windows_8_Apps_HTML_CSS_JavaScript_2E_PDF.pdf

http://aka.ms/611111pdf имеет некоторые подробности о прохождении XHR с WinJS