Существует ли стандартный / типичный способ пересылки учетных данных во внутренний веб-сервис? - PullRequest
Новая
       13

Существует ли стандартный / типичный способ пересылки учетных данных во внутренний веб-сервис?

1 голос
/ 24 июня 2011

Вот настройка: 1. Внешний веб-сайт, проверка подлинности с помощью форм 2. Внутренние веб-службы (возможно, WCF) в другой сети с включенным протоколом HTTPS.

Таким образом, код для внешнего интерфейса получает данныечерез эти серверные веб-сервисы.

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

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

Это похоже на то, что было бы очень распространено, но я не могу найти хороших идей по поиску.

Обратите внимание, что передний конец будетбыть MVC-приложением, хотя я не думаю, что MVC / Web Forms будут иметь значение - любое решение, вероятно, будет хорошо работать для обоих.

1 Ответ

0 голосов
/ 29 июня 2011

Сверчки из аудитории ........

Стратегия, с которой я решил пойти, заключается в следующем:

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

Итак, теперь, когда веб-интерфейсу необходимо вызвать метод внутреннего интерфейса, он сохраняет файл проверки подлинности внутренних форм.в UserData внешнего интерфейса формы билета аутентификации.Он может присоединить это к HTTP-вызову WCF для аутентификации.

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

Кто-нибудь видит любые дыры в этой стратегии

...