Является ли использование Kerberos для аутентификации на веб-сайтах и ​​веб-сервисах хорошей идеей?

Question

Благодаря приобретению у нас есть ряд продуктов, которые требуют аутентификации и авторизации. Продукты включают веб-сайты и клиентские приложения, клиентские приложения используют некоторые веб-сервисы. Мы являемся магазином .Net, и на серверах будет работать Server 2008, клиенты будут работать под управлением XP SP ?? и позже.

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

В настоящее время нет общего хранилища аутентификации или идентификационных данных, и мы надеемся исправить это. Наши цели:

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

Как и у большинства компаний, у нас ограниченные ресурсы и плотный график.

Один из предложенных путей для аутентификации - это Kerberos, который, вероятно, является идеальным путем для аутентификации клиентского приложения в веб-службе, но я менее рад использовать его на веб-сайте, где пользователь может ввести имя пользователя и пароль, а также в Интернете. Сервер будет отвечать за оформление билетов (затем хранить билет в cookie-файле?). Я чувствую, что нам может быть лучше с одним хранилищем идентификаторов и нашей собственной службой аутентификации, которая берет имя пользователя и пароль, сравнивает их с отсортированным хешем, а затем выдает пользовательский токен безопасности, основанный на времени. Может быть, использовать SqlMembershipProvider?

Спасибо всем, кто прочитал это далеко. Kerberos лучше всего подходит для этого сценария или я должен искать в другом месте? Если это не подходит, почему бы и нет?

Мы также смотрим на AD LDS для авторизации, но я думаю, что этот пост уже достаточно длинный ...

Answer 1

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

Плюс, если вы имеете в виду MS Kerberos, и вы, очевидно, понимаете, то открытие Kerberos идет с целым гнездом протоколов MS для других крыс, которое вы должны открыть рано или поздно, потому что вещи более высокого уровня запутаны в AD и т.д. вместе с Kerberos.

Это говорит:

Я чувствую, что нам может быть лучше с [...] собственной службой аутентификации

Почти наверняка нет. Как правило, вы не хотите изобретать колесо, и если вам не нужно, то это колесо . Протоколы аутентификации, как правило, сложно сделать, и еще сложнее для веб-доступа. Придерживайтесь того, что уже существует - базовая аутентификация + SSL или клиентские сертификаты и SSL, а также отслеживание сеанса (снова через SSL, если этот материал действительно имеет значение) или служба LDAP, отличная от вашей AD. У всех этих подходов есть свои проблемы, но не так много, как у вас, когда вы делаете что-то свое.

Answer 2

Рассматривали ли вы OpenID ?

Answer 3

Для веб-сайтов вы можете использовать SPNego / GSS-API / Kerberos. Все основные браузеры и веб-серверы поддерживают SP Nego. Поскольку LDAP, NFS и HAdoop поддерживают Kerberos, вам следует взглянуть на это решение. Проверьте команду curl с опцией согласования.

Answer 4

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

Настройка защищенного OpenID-провайдера на самом деле является большой обязанностью и не должна быть чем-то, что вы просто разыгрываете, хлопая библиотеку вместе с веб-сервером. Вы можете позволить своим пользователям использовать свои собственные OpenID, а затем иметь базу данных, в которой ваши пользователи регистрируют свои OpenID, чтобы они распознавались как сотрудники / участники в системе. Различные части системы могут проверять OpenID на членство либо непосредственно по базе данных, либо вы можете использовать OAuth, чтобы помочь также проверить членство.

Очень интересные возможности, позволяющие объединить эти две технологии.