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

Question

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

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

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

Answer 1

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

Служба проверки подлинности установлена ​​в origanisation в ДМЗ

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

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

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

OpenId

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

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

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

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

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

Answer 2

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

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

Answer 3

Возможно, это могло бы помочь ...

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

Answer 4

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

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

Answer 5

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

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

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

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

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