ASP.NET MVC ajax для WebAPI, возвращающий ответ перенаправления WIF-адресов

Мы используем пользовательский поставщик WIF 3.0 STS для нескольких проектов. Я интегрирую эту аутентификацию как в новый MVC 4 WebApp, так и в WebAPI 2 Service Layer.

Если я просматриваю данные напрямую (WebApp и WebAPI Service), я могу правильно аутентифицироваться. Он перенаправляет на вход WIF STS, я вхожу в систему, получаю ClaimsToken, а затем перенаправляет и отображает ожидаемую страницу.

Однако, если я уже аутентифицирован, и мой WebApp выполняет вызов jQuery.get() ajax в WebAPI Service, он реагирует так, как будто у него нет ClaimsToken. Он перенаправляет (302), и мое местоположение заголовка ответа имеет вход поставщика STS:

https://sts-provider.my.net/?wa=wsignin1.0&wtrealm=https%3a%2f%2fwebapi.services.my.net%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fapi%252fStuff&wct = 2014-08-11T22% 3A10% 3a43Z & wreply = HTTPS% 3a% 2f% 2f% 2fwebapi.services.my.net

и обратный вызов jQuery.get() дает мне textStatus с "ошибкой". Как Служба не видит cookie ClaimsToken? Пожалуйста помоги.

2 ответа

Выяснил это и надеюсь, что это поможет другим. При создании запроса на перекрестный запрос с учетными данными и ssl secure (из-за аутентификации STS) на обоих концах есть дополнительные настройки. Microsoft кратко описывает это, но недостаточно детально для этой реализации ssl (app) -to-ssl (service) с ssl-STS-auth между ними:

http://www.asp.net/web-api/overview/security/enabling-cross-origin-requests-in-web-api

Поэтому я изменил свой вызов WebApp на jQuery.ajax() и установил следующие дополнительные параметры:

$.ajax({
 url: "https://webapi.services.my.net/api/info/all",
 type: 'GET',
 //this tells my WebApp to send the ClaimsToken to the service call
 xhrFields: { withCredentials: true }, 
 //this tells the WebApp we're making a request against a different domain
 crossDomain: true, 
 ...
});

Затем на моем контроллере WebAPI Service я установил WebApi.Cors и установил как таковой:

[EnableCors(origins: "https://webapp.my.net", 
 headers: "*", methods: "*")]
public class InfoController : ApiController
{

Но по какой-то причине я все еще получал сообщение об ошибке:

Флаг учетных данных является "истинным", но заголовок "Access-Control-Allow-Credentials" равен "". Он должен быть "правдой", чтобы разрешать учетные данные.

Ну, оказывается, я не говорил своей службе WebAPI о том, что он получает учетные данные. В результате мой вызов WebApp просто умирал от перенаправления 302 к STS и никогда не получал ClaimsToken для вызова службы. Мой обратный вызов JQuery в WebApp дал textStatus "error" и jqXHR.status как 0, а не 302. Я исправил это, настроив мой контроллер службы WebAPI с дополнительным параметром SupportsCredentials:

[EnableCors(origins: "https://webapp.my.net", 
 headers: "*", methods: "*", SupportsCredentials = true)]
public class InfoController : ApiController
{

БУМ. Мы в бизнесе. Надеюсь это поможет :)


Я не знаю, чего вы пытаетесь выполнить. Вероятно, все ваше приложение заблокировано от несанкционированного доступа (который является по умолчанию WIF). В этом случае это нормально, что вы получаете эту переадресацию, поскольку модули WIF http видят это как несанкционированный запрос и перенаправляют вас в STS для авторизации. Существует несколько способов решить эту проблему. Первое, что нужно сделать, - убедиться, что вы указали asp.NET, что API-интерфейс "открыт". Вы можете открыть весь файл в вашем web.config:

<system.web>
 <authorization>
 <allow users="*">
 </allow></authorization>
</system.web>

Затем закройте (необходимые или все) MVC-контроллеры, используя атрибуты [Авторизовать]. Преимущество заключается в том, что веб-api также будет "открытым" и, следовательно, не будет перенаправлять. Если вы хотите защитить веб-api с помощью токенов WIF, вам потребуется дополнительная работа. В этом случае вам нужно убедиться, что отправитель каким-то образом отправит маркер безопасности в заголовок запроса web api. Вы можете написать свой собственный фильтр http для этого. Я думаю, что в ThinkTecture nuget уже есть некоторые из них.

licensed under cc by-sa 3.0 with attribution.