краткая форма: следует ли использовать какой-нибудь известный uid для аутентификации клиента ldap, а затем другие средства внутри этого клиента для проверки введенных пользователем uid и pw?
полная форма: у нас есть коммерческий веб-продукт на основе .net, который реализован на многих сайтах клиентов и в настоящее время использует внутреннюю аутентификацию пользователя.
Я исследую использование LDAP для аутентификации в каталоге. Поскольку наш продукт реализован в различных средах, я хочу, чтобы он был совместим с максимально широким спектром LDAP-совместимых служб каталогов и конфигураций, включая, помимо прочего, Active Directory.
Помимо аутентификации, я хочу использовать свойство каталога пользователя, чтобы определить, авторизованы ли они для использования приложения. Я ожидаю, что об этом будет свидетельствовать членство пользователя в определенной группе. Имя группы будет точкой конфигурации приложения.
Служба каталогов используется только для подтверждения ИД пользователя, пароля и членства в группе. Приложение НЕ будет использовать личность пользователя при обработке последующих запросов от пользователя. Итак, нет FormsAuthenticationTicket.
Один из моих первых вопросов связан с рассмотренными мною примерами аутентификации, такими как http://tldp.org/HOWTO/LDAP-HOWTO/authentication.html и http://msdn.microsoft.com/en-us/library/ff649227.aspx. Они используют введенные пользователем идентификатор и пароль для аутентификации клиента LDAP. Полагаю, это разумно, но в моем случае клиент продолжит поиск по LDAP, чтобы подтвердить членство в группе. Нужно ли мне беспокоиться о том, что конечный пользователь может не иметь достаточных привилегий каталога для проверки членства? Мне кажется, что было бы лучше использовать зарезервированные учетные данные для аутентификации клиента ldap, а затем с помощью других средств подтвердить введенный пользователем uid / pw. Или, возможно, выполнить привязку дважды, один раз с учетными данными пользователя для их аутентификации, а во-вторых, со встроенными учетными данными для выполнения поиска. Должен ли я сделать это, или я просто усложняю дела, чем они должны быть?
Здесь действует принцип наименьших привилегий. Учетная запись, которую вы используете для привязки к LDAP и перечисления пользователей, групп и любой другой соответствующей информации, обязательно должна быть «служебной учетной записью» и не реальный человеческий аккаунт.
Для этой учетной записи требуются другие разрешения по сравнению с большинством пользователей-людей. Помощнику вице-президента необязательно иметь возможность перечислять все группы и видеть, существует ли данная учетная запись, но для учетной записи, которую вы используете для привязки к LDAP, это необходимо.
Если вы используете системную учетную запись для предоставления привилегий, которых нет у ваших обычных учетных записей, у вас есть повышение привилегий. (В вашем примере пользователи вашего приложения могут видеть членство в группах, которое они не могут видеть самостоятельно.) Это нормально, но имейте в виду, что любое повышение привилегий чревато злоупотреблениями.
Лично я бы предпочел написать свои ACL так, чтобы учетные записи пользователей обладали всеми необходимыми привилегиями, и использовать мой сервер LDAP (а не мое подчиненное приложение) для управления доступом. Почему ваши учетные записи пользователей не должны видеть, к каким группам они принадлежат?
Что касается «минимальных привилегий», здесь это означает использование учетных данных пользователя, потому что он уже имеет к ним доступ. Если вы используете общую системную учетную запись, это - по замыслу -дополнительный привилегии, которых нет у обычных пользователей.