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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

Вы уже ознакомились с SAML?

Answer 4

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

Answer 5

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

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

С таким подходом связаны проблемы:

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

Answer 6

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