Как работает SSO с Active Directory, когда пользователи прозрачно входят в веб-приложение интрасети?

Мне сказали, что можно создать веб-приложение, которое не требует входа в систему. Пользователь входит в Windows, которая аутентифицируется через поиск в Active Directory (LDAP). Затем они должны иметь возможность зайти в мое веб-приложение и никогда не видеть приглашение для входа в систему. Эти клиенты называют это единой регистрацией (возможно, это неправильно и является частью моей путаницы).

Но из того, что я прочитал, единый вход в документы Tomcat:

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

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

Итак, чтобы это работало, я представляю:

• Пользователь делает запрос на какую-то страницу
• Сервер не видит токен сеанса, а затем запрашивает у клиента учетные данные.
• Клиентский браузер без какого-либо вмешательства со стороны пользователя предоставляет некоторые учетные данные серверу.
• Затем, используя эти учетные данные, предоставленные клиентским браузером, он выполняет поиск в LDAP.

Я видел несколько примеров, в которых используются сертификаты на стороне клиента ... в частности, система DoD PKI, которая имеет какой-то смысл для меня, потому что в этих случаях вы настраиваете Tomcat для запроса сертификатов на стороне клиента , но просто заходите в окна. Я не вижу, как это будет работать и какую информацию браузер будет передавать на сервер и т. д. Для этого используется NTLM?

Прежде всего - и в случае, если другие пользователи посещают эту страницу - есть только определенные методы аутентификации, которые позволяют вам выполнять быстрый SSO. Это NTLM и Kerberos . LDAP - с другой стороны - никогда не даст вам SSO.

NTLM - это на самом деле NTLMv1 и NTLMv2. Они очень разные и NTLMv1 устарел из-за серьезных проблем безопасности. Вам следует избегать решений для аутентификации Java, которые не могут правильно определить, поддерживают ли они NTLMv1 или NTLMv2, поскольку в своей документации они используют только слово «NTLM». Скорее всего, разработчик упомянутого решения безопасности не знает себя, что является еще одной причиной искать пожарную лестницу.

Вопреки традиционному мнению, как NTLMv1, так и NTLMv2 полностью документированы Microsoft, но вы все равно найдете решения, которые утверждают, что протокол был "реверс-инжиниринг". Это правда, что это было необходимо до того, как Microsoft документировала протоколы, которые я считаю примерно в 2006 или 2007 году. В любом случае NTLMv1 - нет-нет. Нет ничего плохого в NTLMv2 per se, но Microsoft постепенно отказывается от NTLM (в любой форме) во всех своих продуктах в пользу аутентификации Kerberos. NTLMv1 давно мертв, а NTLMv2 теперь используется только Microsoft в тех случаях, когда недоступен контроллер домена. Итог: NTLM (в любой форме) на самом деле не путь вперед. На самом деле, мы должны отдать должное Microsoft за использование подхода, основанного на стандартах.

Это оставляет вас с Kerberos. Microsoft создала протокол для согласования и передачи аутентификационной информации по HTTP. Это известно в продуктах Microsoft как « Интегрированная проверка подлинности Windows », но было объявлено официальным стандартом под названием SPNEGO . Это то, что вы должны искать. SPNEGO поддерживает как NTLMv2, так и Kerberos в качестве основного механизма аутентификации, но по указанным выше причинам вам следует ориентироваться на Kerberos, а не на NTLMv2.

Я успешно интегрировал несколько приложений Tomcat (работающих в Linux / Solaris) с Active Directory, используя проект SPNEGO в SourceForge . Я обнаружил, что это самый простой подход. Это дает вам быстрый SSO, аналогичный тому, что делает, например, сервер Sharepoint. Это наиболее вероятно, что ваши пользователи ожидают, когда говорят о «SSO». Правильная настройка конфигурации Kerberos, генерация ключей и настройка «фиктивных» учетных записей в Active Directory могут быть хлопотами, но как только вы все сделаете правильно, это будет работать как шарм.

Единственное, что мне не нравится в проекте SPNEGO на SourceForge, - это то, что я не понимаю, как часто он выполняет аутентификацию. Мое неприятное подозрение, что он делает это для каждого просмотра страницы, а не один раз для каждой сессии. Возможно, я ошибаюсь в этом. В любом случае: это подчеркивает еще одну вещь, которую необходимо учитывать в решениях SSO: вы не хотите реализовывать решение, которое «спамит» вашего провайдера идентификации (скажем, Active Directory) ненужными запросами.

В среде Windows Active Directory единый вход в систему означает, что посещение внутренней веб-страницы несет ваши права входа в Windows, и веб-сервер может на них воздействовать. Это то, для чего используется NTLM, но в новых реализациях вместо этого используется Kerberos.

Если вы открываете веб-сайт сервера Sharepoint Server, он знает, кто вы, не требуя имени пользователя и пароля для входа, но это работает только для внутренних веб-сайтов в той же сети, я не думаю, что для него имеет смысл работать на общедоступном веб-сайте. (Я не могу сказать, имеете ли вы в виду «виртуальный хост», как в Apache vhost или как на стороннем размещенном сервере).

Вот документ Microsoft, описывающий, как аутентификация Kerberos работает на веб-сервере под управлением IIS / ASP.Net: http://msdn.microsoft.com/en-us/library/ff647076.aspx

Это выглядит возможно сделать с Apache / Tomcat / Java. Вот PDF-файл, описывающий реализацию этого в британском университете: http://gfivo.ncl.ac.uk/documents/UsingKerberosticketsfortrueSingleSignOn.pdf и проект Codeplex для него: http://tomcatspnego.codeplex.com/ и Openfire имеют некоторые документация, касающаяся общей работы с Java / Kerberos, здесь ( http://community.igniterealtime.org/docs/DOC-1060 ).

Похоже, вы описываете то, что Microsoft называет интегрированной аутентификацией Windows.

Похоже, что Tomcat поддерживает аутентификацию Windows, основанную на этой статье .

Для начала, вы не можете избежать входа в систему. Если вы хотите идентифицировать пользователей, вы должны иметь их логин. Забудьте о NTLM, на помощь придет Kerberos - он может делать все абсолютно прозрачным образом.

SingleSignOnValve - это не то, что вы ищете. Если вы используете Tomcat 7, вы можете использовать SpnegoAuthenticator сразу, но на 6 вы должны использовать это .