Подтвердить что ты не робот

Аутентификация Active Directory для продукта SaaS

После некоторой теоретической помощи по наилучшему подходу к разрешению SaaS-продукту аутентифицировать пользователей на внутреннем сервере Active Directory (или другом LDAP-сервере).

Приложение размещено, но существует требование о том, что арендаторы могут делегировать аутентификацию своим существующим провайдерам управления пользователями, таким как AD или OpenLDAP и т.д. Такие инструменты, как Microsoft Exchange, поддерживают обмен корпоративной синхронизацией AD.

Предполагая, что клиент не хочет перенаправлять порт 389 на свой контроллер домена, какой лучший подход для этого?

4b9b3361

Ответ 1

Проведя некоторое исследование и поговорив с несколькими администраторами системы, которые будут управлять этим, мы остановились на двух вариантах, которые должны удовлетворять большинство людей. Я опишу их здесь для тех, кто также заинтересован в результате.

Служба проверки подлинности, установленная в DMZ origanisation

Если пользователи хотят использовать аутентификацию с локальным сервером активных каталогов, им потребуется установить агент в DMZ и открыть порт 443. Наш сервис будет настроен на использование этой службы для выполнения проверки подлинности.

Эта служба будет размещаться в DMZ и получать запросы на аутентификацию из приложения SaaS. Служба попытается привязать к активному каталогу эти учетные данные и вернуть статус, указывающий на успех или неудачу.

В этом случае аутентификация на основе форм приложения не изменится, и пользователь не будет знать об аутентификации за кулисами.

OpenId

Подобно первому подходу, сервис будет установлен в DMZ клиента, а порт 443 будет открыт. Это будет поставщик OpenId.

Приложение SaaS будет пользователем OpenId (уже для входа в Facebook, Twitter, Google и т.д.).

Когда пользователь хочет войти в систему, будет представлен поставщик OpenId, попросив ввести их имя пользователя и пароль. Этот экран входа будет обслуживаться из DMZ клиента. Пользователь никогда не вводит свое имя пользователя или пароль в приложение SaaS.

В этом случае существующая проверка подлинности на основе форм заменяется аутентификацией OpenId из службы в DNZ клиента.

Третий вариант, который мы изучаем, - это федеративные службы Active Directory, но это является собственностью Active Directory. Другие два решения поддерживают любую аутентификацию на основе LDAP через Интернет.

Ответ 2

Возможно, это может помочь...

Этот поставщик Stormpath предлагает услугу, предоставляющую: аутентификацию пользователя, управление учетными записями пользователей, подключение к вашим клиентам локальных каталогов.

Ответ 3

Как насчет подключения LDAPS к каталогу пользователей? Они могут использовать брандмауэр, чтобы только ваши серверы имели доступ, если они были обеспокоены тем, что они были публичными. Поскольку это SSL, он защищен от сквозного конца. Все, что вам нужно от них, - это сертификат от их выдающего ЦС (если он не является общедоступным). Я изо всех сил пытался заставить эту работу работать над внутренним веб-проектом в DMZ, и там действительно отсутствовали какие-либо руководства в Интернете. Поэтому я написал один, когда я получил его работу:

http://pcloadletter.co.uk/2011/06/27/active-directory-authentication-using-ldaps/

Ответ 4

Лучше всего реализовать SAML-аутентификацию для своего приложения SaaS, а затем зарегистрироваться с поставщиками удостоверений, такими как Okta или OneLogin. После этого вы также можете подключить его к ADFS для обеспечения единого входа для вашего веб-приложения через Active Directory.

Я просто делаю это исследование самостоятельно, и это то, с чем я столкнулся, будет иметь больше обновлений после реализации. Надеюсь, это даст вам достаточно ключевых слов, чтобы сделать еще один поиск в Google

Ответ 5

Я понимаю, что существует три возможных решения:

  • Установка чего-либо на контроллере домена для захвата всех пользовательских изменений (дополнений, удалений, изменений пароля) и отправки обновлений на удаленный сервер. К сожалению, для веб-сайта нет возможности узнать начальные пароли пользователей - только новые, если они будут изменены.

  • Обеспечьте доступ для веб-сервера для подключения к контроллеру домена через LDAP/WIF/ADFS. Это, вероятно, означало бы открытие входящих портов в брандмауэре компании, чтобы разрешить определенный IP-адрес.

  • В противном случае обходите имена пользователей/пароли и используйте аутентификацию по электронной почте. Пользователям просто нужно аутентифицироваться по электронной почте каждые 3-6 месяцев для каждого устройства.

Я должен начать реализовывать это для предстоящего проекта, и я серьезно склоняюсь к опции № 3 для простоты.