Как построить интеграцию LDAP для моего веб-приложения?

Question

Моя компания разрабатывает и продает SaaS-приложение, которое имеет сотни клиентов. Некоторые из наших клиентов попросили нас поддержать интеграцию LDAP для аутентификации учетных записей пользователей в их существующих системах вместо того, чтобы создавать новую учетную запись для каждого из своих сотрудников. Похоже, во многих местах это называется единой регистрацией (SSO)? Естественно, в нашей системе уже есть механизм для поддержания профилей учетных записей пользователей и аутентификации этих учетных записей пользователей на странице входа в систему.

Мы немного не осведомлены о LDAP и запутались в нескольких вещах. Пожалуйста, извините за возможное использование неправильной терминологии (помните, мы немного неосведомлены об этом).

Мы думаем, что понимаем основы того, как это может работать:

• Наш клиент настраивает свою учетную запись для «включения» функции «удаленной аутентификации» для своей учетной записи. Они предоставляют удаленный URL, который будет аутентифицировать их пользователей.
• Пользователи заходят на нашу страницу входа и пытаются выполнить вход, используя свое имя пользователя и пароль, предоставленные системой LDAP своей компании.
• Наша страница входа будет безопасно пересылать учетные данные для входа (предположительно зашифрованные и хэшированные в некотором согласованном формате) на URL-адрес «удаленной аутентификации», предоставленный нашим клиентом.
• Сценарий клиента аутентифицирует пользователя и затем перенаправляет его обратно на наш сайт с «статусом аутентификации».
• Наша страница проанализирует «статус аутентификации» и либо примет пользователя, вошедшего в систему, либо нет.

Предполагая, что приведенная выше информация является даже полукорректной, нам все равно нужно, чтобы у каждого пользователя была учетная запись в нашей системе. Разве нам не понадобится способ синхронизировать наши профили учетных записей с профилями пользователей в каталоге LDAP? Это просто «внешний идентификатор», который ссылается на идентификатор пользователя в системе LDAP? Тогда потребуется ли, чтобы клиентский сценарий «удаленной аутентификации» предоставил этот идентификатор нашей системе, чтобы мы знали, с какой учетной записью в нашей системе нужно связать имя входа?

Чего нам не хватает?

Кстати, наша платформа - IIS, ASP.Net 2.0 и SQL Server 2005.

Answer 1

Есть несколько вариантов. Если вы действительно имеете в виду LDAP, а не просто Active Directory, я бы, вероятно, посмотрел на использование System.DirectoryServices.Protocols для выполнения привязки LDAP с использованием предоставленных учетных данных через защищенный канал.

Строго говоря, это не единый вход. Единый вход в систему означает, что вам нужно будет предоставить свои кредиты только один раз при первом входе в систему. Это просто снижает сложность для пользователей, имея только один идентификатор. Обычно для клиентов Windows в корпоративной среде со смесью платформ и технологий SSO достигается путем добавления клиента к рабочему столу, который управляет аутентификацией в различных системах. В среде только с MS вы можете достичь единого входа, если все ваши веб-приложения работают на IIS, вы используете IE и используете встроенную аутентификацию Windows, олицетворение и все такое.

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

Вы можете предоставить API, чтобы решения для управления идентификацией и доступом (с учетом вашего взгляда на Microsoft, см. ILM2 007 в качестве примера) могли интегрироваться с вашей системой и выполнять все управление учетными записями пользователей.

Answer 2

Как всегда, не забудьте проверить проверку подлинности, чтобы убедиться, что отправленный пароль не пуст.

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

Это проблема для приложения, так как сервер LDAP просто следует стандарту, раздражающему стандарту, но, тем не менее, стандарту.

Answer 3

Возможно рассмотрите Аутентификацию против Авторизации

Аутентификация - это какой пользователь? Авторизация - кто должен иметь возможность использовать приложение, указанные пользователи, группы?

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

Если вместо пользовательского хранилища данных вы используете каталог,

• использовать метод подключения к каталогу для аутентификации пользователя
• вы (можете) получить аутентификацию бесплатно - пользователь известен windows, windows может идентифицировать iis и sqlserver, возможно, нет необходимости спрашивать пользователя, кто они.
• вы будете знать о большем количестве пользователей, чем у вас есть полномочия, и вам необходимо будет применить ограничения - ограничить количество подключений к определенной группе.
• может хранить пользовательские данные в каталоге, а не вместе с данными вашего приложения на сервере sql.

Если ваши пользователи действительно хотят универсальный LDAP, то вам нужно посмотреть на (C) ldap_connect, ldap_bind_s (C #) LDAPConnection System.DirectoryServices.Protocols

Или снова вернитесь в AD, это Демистифицированный .Net App единый вход может помочь

Answer 4

Вот один полезный фрагмент программного обеспечения, позволяющий обращаться к каталогам LDAP через Интернет с помощью JSON-RPC: Json2Ldap

Answer 5

Как это работает в нашей системе:

• Когда пользователь переходит к веб-приложению, серверная переменная REMOTE_USER считается токеном пользователя
• Код для входа подключается к каталогу ldap с учетной записью для поиска
• Код входа ищет учетную запись ldap, которая «соответствует» REMOTE_USER
• Затем логин пытается сопоставить эту учетную запись с учетной записью в нашей системе
• Если сопоставление возможно на всем протяжении, предположим, что пользователь вошел в качестве соответствующей учетной записи, продолжайте в обычном режиме

Таким образом, пользователь может повторно использовать свою аутентификацию домена Windows в нашем приложении.

Answer 6

Вам необходимо решить, как вы планируете связать пользователя LDAP с учетной записью в вашем приложении.

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

После того, как вы получили эту ссылку, вы можете просто выполнить привязку LDAP для проверки учетных данных пользователя.