Веб-приложение - аутентификация пользователя на разных доменах

Question

Наш клиент обратился к нам с просьбой разработать приложение, и, как обычно, сфера применения растет с каждым днем.

Первоначально он начинался как отдельное приложение, ограниченное их корпоративной сетью. Аутентификация пользователя была установлена ​​путем запроса имени пользователя в Windows и использования базы данных SQLServer для размещения прав доступа. Все довольно просто.

Теперь им нужно следующее:
- Приложение для работы в Интернете
- Приложение для размещения вне корпоративной сети
- Идентификация пользователя для работы таким же образом (без использования паролей, только входы в Windows)

Чтобы усложнить задачу, они хотят, чтобы различные функции приложения могли использоваться другим приложением, которое просто запускает HTTP-запросы.
- пользователь входит в корпоративную сеть
- Пользователь запускает корпоративное приложение
- Пользователь обрабатывает данные клиента
- пользователь нажимает кнопку
- Корпоративное приложение отправляет HTTP-запрос нашему веб-приложению
- HTTP-запрос включал необходимую аутентификацию и данные клиента
- Аутентификация пользователя завершается «автоматически» (без участия человека)
- Данные клиента передаются надежно

Они очень заинтересованы в том, чтобы мы сделали это для них, поскольку наш первоначальный подход был очень тем, чего они хотели. Они по-прежнему хотят, чтобы мы это делали, хотя такие размещенные веб-приложения не являются нашей особой задачей. Поэтому я сейчас подхожу к экспертам;
- У кого-нибудь есть советы, как к этому подойти?
- Есть ли у кого-нибудь предупреждение о возможных ловушках, которых следует избегать?

Answer 1

В основном они говорят о федеративном доступе. Вы должны разместить точку аутентификации внутри их сети, которая, в свою очередь, перенаправляет токен в ваше приложение, которое анализирует его и разрешает (или останавливает доступ). Это довольно стандартно, и MS обеспечивает хорошую основу для этого в Geneva Framework . Это также будет работать для вызовов веб-служб, при условии, что они могут изменить свое приложение для использования WSFed в качестве протокола и общаться со службой токенов безопасности, которая автоматически выдает токен аутентификации. В большинстве случаев вы будете использовать SAML для этого. Он также имеет дополнительный бонус деталей аутентификации, никогда не выходящих за пределы их корпоративной сети.

Предложение аутентификации на основе сертификатов является интересным, но требует дополнительной работы по развертыванию инфраструктуры PKI. Это может быть дорого.

CardSpace не будет работать - он не молчит, как им кажется. OpenID также не является стартовым, он также не тихий.

Дополнительные очки, если вы смотрите на Azure - биты аутентификации Azure также используют SAML / WSFed под капотом, и в нем есть биты Женевы. Поэтому, если вы перешли в облако, то каждый из ваших клиентов должен был бы просто настроить страницу входа в свою сеть - все, что вам нужно сделать, это доверить эту страницу выдаче токенов аутентификации и проанализировать их в соответствии с вашими правилами.

Answer 2

В зависимости от того, как построено ваше приложение, вы можете использовать machineKey в вашем web.config, чтобы разрешить вызовы AJAX с единой регистрацией (SSO). Это может потребовать небольшого приложения asp.net в корпоративной сети просто для раздачи токенов аутентификации и перенаправления на ваше размещенное приложение.

Если два приложения используют один и тот же ключ machineKey, тогда система аутентификации asp.net с удовольствием разрешит пользователям входить в ваше размещенное приложение.

Есть проблемы с этим подходом:

• Вы вводите в свою систему еще одну зависимость (приложение для аутентификации в корпоративной сети). Это будет простое приложение, но при попытке диагностики проблем у вас возникнут проблемы, если у вас нет доступа.
• Вам требуется, чтобы ваша размещенная служба находилась в том же домене, что и приложение аутентификации (поэтому билет аутентификации в файле cookie HTTP будет разослан).
• Вам также понадобится SSL-сертификат для вашей размещенной службы для защиты информации. (На самом деле не является недостатком, вы, вероятно, все равно захотите это сделать.)
• Поскольку у вас и вашего клиента будет общий ключ machineKey, вы будете привязывать экземпляр вашего приложения к этому конкретному клиенту.

Answer 3

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

Answer 4

Вы уже смотрели SAML ?

Answer 5

Может быть, WCF-коммуникация с аутентификацией на основе сертификатов, т. Е. С внешними пользователями, которые используют сервис, компания предоставляет им действующий сертификат. Тогда для этого не потребуется пароль для имени пользователя, но пользователь получит прямой доступ.

Answer 6

Я бы использовал для этого частного провайдера / сервера OpenID.