Инфраструктура безопасности Java высокого уровня - PullRequest
18 голосов
/ 04 июня 2011

Какую инфраструктуру безопасности вы используете в своих проектах Java?

Я использовал Spring Security и Apache Shiro, и они оба выглядят незрелыми.

Недостатки Spring Security:

  1. нет встроенной поддержки разрешений;
  2. нет возможности явно использовать в коде Java (иногда это необходимо);
  3. слишком много внимания уделяется классическим (не AJAX) веб-приложениям.

Недостатки Apache Shiro:

  1. ошибки в окончательном выпуске (например, проблема с интеграцией Spring);
  2. нет поддержки OpenID и некоторых других широко используемых технологий;
  3. сообщается о проблемах производительности.

Также не хватает документации для них обоих.

Может быть, большинство реальных проектов разрабатывают свои собственные структуры безопасности?

Ответы [ 4 ]

16 голосов
/ 05 июня 2011

Что касается Apache Shiro:

Я не уверен, почему вы перечислили вещи, которые вы сделали:

  1. Каждый проект в мире имеет ошибки выпуска, без вопросов. Однако главный ключ в том, что команда Широ отзывчива и исправляет их как можно скорее. Это не то, что нужно для оценки структуры, иначе вы бы исключили каждую структуру, включая любую, которую вы пишете сами.
  2. Поддержка OpenID будет выпущена в ближайшее время в Shiro 1.2 - может быть, через месяц?
  3. Какие проблемы с производительностью? Ни у кого когда-либо не сообщалось о проблемах с производительностью в список разработчиков, тем более что поддержка кэширования в Shiro широкая и первоклассная. Без разъяснений или ссылок это выглядит как FUD.
  4. Документация сейчас действительно хороша - одни из лучших в Open Source, которые я видел за последнее время (она была переработана 2 недели назад). У вас есть конкретные примеры того, как вам это не подходит?

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

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

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

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

НТН!

3 голосов
/ 05 июня 2011

Мои текущие проекты используют SpringSecurity и включают в себя выполнение всех трех вещей, которые, по вашему мнению, являются недостатками в SpringSecurity:

  • В проектах реализованы детальные правила доступа, которые выходят за рамки простых ролей, и по-разномузадействовать состояние объектов домена, дополнительные параметры запроса и т. д.Они реализованы с использованием пользовательских «объектов политики доступа», которые вызываются в моих контроллерах MVC.Однако ошибки проверки доступа возвращаются в SpringSecurity путем создания соответствующего исключения.(Они могли бы быть реализованы как стандартные перехватчики уровня метода SpringSecurity, но проверки обычно включают проверку объектов домена.)

  • Проекты поддерживают как веб-доступ, так и доступ AJAX, и имеют дело с ошибками доступапо-разному для двух случаев.Это делается путем написания некоторых пользовательских компонентов точки входа аутентификации для SpringSecurity, которые выбирают между различными режимами аутентификации в зависимости от URL-адреса запроса и т. Д.

Другими словами, это можно сделать ...

Сказав это, я согласен с вами по нескольким пунктам:

  • Нелегко подобрать такую ​​вещь.Я продолжал сталкиваться с препятствиями, когда использовал элемент <http> и связанный с ним конфигуратор.Например ... вы хотите, чтобы он использовал другую версию компонента X. Но для этого вам также необходимо заменить Y, Z, P и Q.

  • Документация действительноразреженный и бесполезный, если вы пытаетесь сделать что-то необычное.

1 голос
/ 01 апреля 2015

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

Моя компания недавно выпустила с открытым исходным кодом OACC , усовершенствованную платформу безопасности приложений Java. OACC предназначен для систем, требующих степени детализации безопасности на уровне объекта.

OACC предоставляет высокопроизводительный API, который предоставляет основанные на разрешениях сервисы авторизации. Вкратце, OACC позволяет вашему приложению обеспечивать безопасность, отвечая на вопрос: Разрешено ли субъекту "A" выполнять действие "p" над объектом "B"?

Одной из ключевых абстракций в OACC является ресурс . Ресурс служит в качестве заполнителя в OACC для объекта в домене приложения, который необходимо защитить. Как действующие лица (например, пользователи, процессы), так и защищаемые объекты (например, документы, серверы) представлены как ресурсы в OACC. Объекты домена приложения, которые являются субъектами или защищены, просто сохраняют идентификатор ресурса в связанном ресурсе.

Абстракция ресурса позволяет OACC, в отличие от других основных структур безопасности, предоставлять богатый API, который управляет разрешениями между ресурсами. OACC сохраняет отношения безопасности в таблицах RDBMS (в настоящее время поддерживаются DB2, Oracle, MS-SQLServer и PostgreSQL).

Для получения дополнительной информации посетите веб-сайт проекта: http://oaccframework.org

0 голосов
/ 05 июня 2011

Мы используем многоуровневую безопасность в одном из наших проектов.Уровни следующие:

  1. HTTPS как протокол (Apache-AJCConnectors-TomcatServlets)
  2. Только двоичные объекты, передаваемые между клиентом и сервлетом
  3. Отдельные элементы в переданномобъекты (в любом случае) зашифрованы
  4. Ключ шифрования является динамическим, устанавливается при первоначальном подтверждении связи, действителен для 1 сеанса

Концептуально, защита состоит из ключа шифрования, алгоритма шифрования иданные, на которые он распространяется.Мы гарантируем, что больше чем 1 из 3 никогда не передается одновременно во время связи.Надеюсь, это поможет.С уважением, - MS

...