Аутентификация на основе сертификатов и IP - PullRequest
Новая
       20

Аутентификация на основе сертификатов и IP

0 голосов
/ 22 декабря 2009

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

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

(Это могут быть портативные компьютеры с определенными сертификатами, установленными на их компьютере, или с определенным набором статических ips.)

Ответы [ 2 ]

2 голосов
/ 22 декабря 2009

Да, это возможно при использовании клиентских сертификатов HTTPS. Точная настройка и конфигурация зависят от вашего сервера приложений и конкретных требований, но распространенным сценарием будет создание внутреннего ЦС компании (центра сертификации) для выдачи клиентских сертификатов, которые могут быть ограничены конкретными IP-адресами клиентов, и настройки вашего сервера приложений. Коннектор HTTPS для запроса сертификата клиента и доверия сертификатам, выданным вашим собственным центром сертификации.

После правильной настройки клиентские сертификаты становятся доступными для веб-приложения через атрибут запроса сервлета: 

X509Certificate[] certificates = (X509Certificate[])
    request.getAttribute("javax.servlet.request.X509Certificate");
0 голосов
/ 24 декабря 2009

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

Пара других мыслей:

  • Практически любой сервер приложений позволит вам установить доверенное хранилище сертификатов - список сертификатов CA, которые ваше приложение примет для аутентификации клиента HTTPS. Ограничьте это центром сертификации, который предоставляет клиентские сертификаты - внутренним центром сертификации или поставщиком сертификатов.
  • Выбор внутреннего ЦС или ЦС провайдера является корпоративным. Внутренний CA потребует рабочей силы для настройки и обслуживания, а поставщик CA будет стоить вам денег за сертификат. Достигается точка компромисса, когда дешевле делать сертификаты самостоятельно, но до тех пор, пока вы не достигнете этого уровня, поставщик ЦС может быть дешевле.
  • Если у вас есть внутренний ЦС, и ваше правило гласит, что «любой компьютер компании (с сертификатом) может получить доступ к этому приложению», то ваша работа выполняется в списке доверенных ЦС на сервере приложений, поскольку вы знаете ЦС компании. не будет использоваться ни для кого, кроме людей в компании.
  • Если у вас есть провайдер CA, вам может потребоваться еще больше ограничить контроль доступа и использовать предоставленный jambjo код для получения сертификата и просмотра информации в нем. Как правило, в пределах DN субъекта (различающееся имя) есть компонент организации (O) и организационной единицы (OU), который сообщит вам, какая организация выпустила этот сертификат. Вы должны быть в состоянии проверить это, чтобы убедиться, что у вас есть компьютер компании.
  • Целесообразно проверить O и OU, если вы знаете, что ваш провайдер CA никогда не выдаст имена O и OU вашей компании кому-либо, кроме члена вашей компании. Если это не так, вам может потребоваться проверить внутреннее хранилище данных (например, каталог LDAP), чтобы убедиться, что пользователь или компьютер пользователя вам известен.
  • Также возможно связать IP-адрес машины с сертификатом - часто SubjectAltName (Subject Alternative Name) используется для этого при создании сертификата. Я не рекомендовал бы это, потому что вам понадобится новый сертификат, если вы когда-либо измените IP-адрес машины. Это кажется излишне сложным для ваших целей.
...