Начало работы с Java EE 8 Security API — часть 1

Java EE Безопасность API Программа перевода самородков
Начало работы с Java EE 8 Security API — часть 1

Начало работы с Java EE 8 Security API — часть 1

Java Enterprise-Ground Security для платформ облачных и микросервисов

Обзор новых интерфейсов HttpAuthenticationMechanism, IdentityStore и SecurityContext.

Об этой серии:

долгожданныйJava EE Security API (JSR 375)Обеспечение безопасности Java корпоративного уровня в новую эру облачных вычислений и микросервисов. В статьях этой серии показано, как упростить новые механизмы безопасности и стандартизировать обработку безопасности Java EE в контейнерах, а затем использовать их в облачных проектах.

Опытные разработчики Java™ должны понимать, что на Java не влияет отсутствие механизмов безопасности Java. Доступные варианты:Описание протокола лицензирования контейнеров Java(JACC),Поставщик службы аутентификации личности Java(JASPIC), а также множество сторонних API-интерфейсов безопасности для конкретных контейнеров и решений для управления конфигурацией.

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

В этой серии статей представлен новый Java EE Security API, начиная с обзора API и его трех основных интерфейсов:HttpAuthenticationMechanism,IdentityStoreиSecurityContext.

получить код

Новый стандарт безопасности Java EE

Разработка спецификации безопасности Java EE стала возможной в 2014 году.Обзор Java EE 8, Обратная связь община приводит к темпам развития спецификации безопасности Java EE. Упрощение и стандартизация безопасности Java Enterprise - была приоритетом для многих респондентов. После установления панель JSR 375 определит следующие вопросы:

  • Все виды контейнеров сервлетов EJB и Java EE представляют собой определение аналогичного API, связанного с безопасностью, но есть тонкие различия в синтаксисе. Например, когда сервлет проверяет роль пользователя, вызовитеHttpServletRequest.isUserInRole(String role), А затем вызвать EJBEJBContext.isCallerInRole(String roleName).
  • Внедрить существующие механизмы безопасности, такие как JACC, сложно, а JASPIC сложно правильно использовать.
  • Не воспользоваться существующими механизмами современных функций программирования Java EE, таких как контекст и инъекция зависимости (CDI).
  • Не существует метода переносимости для управления тем, как серверная часть аутентифицируется между контейнерами.
  • Стандартной поддержки управления хранилищем удостоверений или настройки ролей и разрешений нет.
  • Стандартной поддержки развертывания настраиваемых правил проверки подлинности нет.

Это основные вопросы, на решение которых направлен JSR 375. В то же время спецификация позволяет разработчикам самостоятельно управлять безопасностью и контролировать ее, определяя API-интерфейсы переносимости для аутентификации, хранения удостоверений, ролей и разрешений, а также авторизации между контейнерами.

Прелесть Java EE Security API заключается в том, что он предоставляет альтернативный способ настройки хранилищ идентификационных данных и механизмов аутентификации, но не заменяет существующие механизмы безопасности. API-интерфейс безопасности Java EE позволяет разработчикам обеспечивать безопасность веб-приложений Java EE — с помощью или без использования специализированных или проприетарных решений — согласованным и переносимым образом.

Что входит в API безопасности Java EE?

Java EE Security API версии 1.0 содержит подмножество исходного проекта и фокусируется на технологиях, связанных с собственными облачными приложениями. Эти особенности:

  • API для аутентификации
  • Идентифицирует API хранилища
  • Контекстно-безопасный API

Эти функции объединены с новой стандартизированной терминологией для всех реализаций безопасности Java EE. Остальные функции (которые планируется включить в следующую версию):

  • API псевдонимов паролей
  • API назначения ролей/разрешений
  • API авторизованного перехватчика

Аутентификация веб-безопасности

Платформа Java EE определила два механизма для аутентификации пользователей веб-приложений:Servlet 4.0(JSR 369) обеспечивает конфигурацию декларативного механизма общих приложений. К надежности сцены предъявляют более высокие требования,JASPICопределяетServerAuthModuleИнтерфейс поставщика услуг, который поддерживает разработку модулей проверки подлинности для обработки учетных данных любого типа. также,Файл конфигурации контейнера сервлетаУказывает, как интегрировать JASPIC с контейнером сервлетов.

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

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

相反，JASPIC 非常优秀，而且有很好的延展性，但它的使用也相当复杂。 кодированиеAuthModule, и согласование его с веб-контейнером для использования с проверкой подлинности может быть довольно громоздким. Помимо этого, JASPIC не имеет декларативной конфигурации и явного способа переопределить регистрацию.AuthModuleметод кодирования.

Java EE Security API через новый интерфейсHttpAuthenticationMechanismНекоторые из этих проблем решены. Новый интерфейс по сути JASPICServerAuthModuleУпрощенный вариант интерфейса контейнера сервлетов, который использует существующие механизмы, смягчая их ограничения.

HttpAuthenticationMechanismПримеры контейнера, отвечающего за предоставление внедренного компонента CDI.HttpAuthenticationMechanismДругие реализации интерфейса могут быть предоставлены приложением или контейнером сервлета. Уведомление,HttpAuthenticationMechanismУказывается только для контейнеров сервлетов.

Поддержка аутентификации Servlet 4.0

Контейнер Java EE должен обеспечивать три механизма аутентификации, определенные в спецификации Servlet 4.0.HttpAuthenticationMechanismвыполнить. Три реализации:

  • Базовая аутентификация HTTP (раздел 13.6.1)
  • Аутентификация на основе форм (раздел 13.6.3)
  • Аутентификация пользовательских форм (раздел 13.6.3.1)

Каждая реализация запускается наличием соответствующего внимания:

  • @BasicAuthenticationMechanismDefinition
  • @FormAuthenticationMechanismDefinition
  • @CustomFormAuthenticationMechanismDefinition

Когда встречается одна из этих аннотаций, контейнер создает экземпляр связанного механизма и делает его немедленно доступным.

В новой спецификации больше нет необходимости, как того требует Servlet 4.0,web.xmlсередина<login-config>Задает механизм проверки подлинности между элементами. На самом деле, еслиweb.xmlИ существуют механизмы аннотации httpauthenticentication, процесс развертывания может потерпеть неудачу - по крайней мере, игнорироватьweb.xmlКонфигурация.

Давайте посмотрим на примере того, как работает каждый механизм.

Базовая HTTP-аутентификация

@BasicAuthenticationMechanismDefinitionАннотация запускает базовую HTTP-аутентификацию, определенную Servlet 4.0. В листинге 1 показан пример. Единственный параметр конфигурации является необязательным и позволяет указать область.

Листинг 1. Базовая HTTP-аутентификация
@BasicAuthenticationMechanismDefinition(realmName="${'user-realm'}")
@WebServlet("/user")
@DeclareRoles({ "admin", "user", "demo" })
@ServletSecurity(@HttpConstraint(rolesAllowed = "user"))
public class UserServlet extends HttpServlet { … }

Что такое царство?

Ресурсы сервера можно разделить на отдельные защищенные элементы управления. В этом случае каждый пользователь будет иметь свою собственную схему аутентификации и базу данных авторизации с пользователями и группами, контролируемыми политикой одного и того же происхождения. Эта база данных пользователей и групп называетсяrealm.

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

@FormAuthenticationMechanismDefinitionАннотации используются для проверки подлинности на основе форм. у него есть обязательный параметрloginToContinue, который используется для настройки страницы входа в веб-приложение, страницы ошибок и функций перенаправления или переадресации. В листинге 2 видно, что страница входа определяется URL-адресом.useForwardToLoginExpressionнастраивается с использованием языка выражений (EL). не нужно@LoginToContinueАннотация передает любые параметры, так как реализация предоставит значения по умолчанию.

Листинг 2. Аутентификация на основе формы
@FormAuthenticationMechanismDefinition(
   loginToContinue = @LoginToContinue(
       loginPage="/login-servlet",
       errorPage="/error",
       useForwardToLoginExpression="${appConfig.forward}"
   )
)
@ApplicationScoped
public class ApplicationConfig { ... }

Аутентификация пользовательской формы

@CustomFormAuthenticationMechanismDefinitionАннотация запускает встроенную проверку подлинности пользовательских форм. В листинге 3 показан пример.

Листинг 3. Аутентификация пользовательской формы
@CustomFormAuthenticationMechanismDefinition(
   loginToContinue = @LoginToContinue(
       loginPage="/login.do"
   )
)
@WebServlet("/admin")
@DeclareRoles({ "admin", "user", "demo" })
@ServletSecurity(@HttpConstraint(rolesAllowed = "admin"))
public class AdminServlet extends HttpServlet { ... }

Пользовательские формы аутентификации предназначены для лучшего выравнивания с страницами JavaServer (JSF) и связанными с технологиями Java EE.login.doПосле отображения страницы имя пользователя и пароль вводятся и обрабатываются компонентом поддержки страницы входа.

IdentityStore API

Хранение личных данныхЭто база данных, которая хранит данные пользователя идентификации, такие как имя пользователя, член группы и информация об учетной записи для проверки. Java EE Security API предоставляет имяIdentityStore的抽象标识存储。 похожий наJAAS LoginModuleинтерфейс,IdentityStoreИспользуется для взаимодействия с хранилищем удостоверений для аутентификации пользователей и получения сведений о членстве в группах.

Как описано в спецификации,IdentityStoreодеялоHttpAuthenticationMechanismреализация , но это не обязательно,IdentityStoreМожет стоять в одиночестве и использоваться любым другим механизмом аутентификации. Тем не менее, используйтеIdentityStoreиHttpAuthenticationMechanismПозволяет приложениям управлять хранилищем удостоверений, используемым для проверки подлинности, переносимым и стандартизированным способом. Рекомендуется в большинстве сценариев использования.

IdentityStoreAPI включает в себяIdentityStoreHandlerинтерфейс,HttpAuthenticationMechanismОн должен быть делегирован для проверки учетных данных пользователя. после,IdentityStoreHandlerперечислитьIdentityStoreпример.IdentityРеализации хранения не используются напрямую, но взаимодействуют с помощью специализированных обработчиков.

IdentityStoreHandlerМожет для краткогоIdentityStoresВыполнить аутентификацию иCredentialValidationResultПримеры полимеризации приводит к форме возврата. Действите ли величины, объект может иметь роль в передаче только учетных данных, или это может быть любой из информационных объектов включает в себя богатые следующие:

  • CallerPrincipal
  • Набор коллекций, принадлежащих теме
  • Имя вызывающего абонента или отличительное имя LDAP
  • Уникальный идентификатор, который идентифицирует звонящего в магазине

Идентифицирует хранилище по порядку, в зависимости от каждогоIdentityStoreПриоритет реализации. Список хранилища обрабатывается дважды: сначала для аутентификации, затем для авторизации.

Как разработчик, вы можете реализоватьIdentityStoreинтерфейс для реализации собственного облегченного хранилища удостоверений, или вы можете использовать встроенные для LDAP и RDBMSIdentityStoresодин из них. Они инициализируются путем передачи сведений о конфигурации в соответствующие аннотации —@LdapIdentityStoreDefinitionили@DataBaseIdentityStoreDefinition.

Встроенная конфигурация IdentityStore

Самое простое хранилище идентификаторовхранилище базы данных. это через@DataBaseIdentityStoreDefinitionАннотация настроена. Как показано в листинге 4, две встроенные аннотации хранилища данных основаны на существующей версии Java EE 7.@DataStoreDefinitionаннотация.

В листинге 4 показано, как настроить хранилище идентификаторов базы данных. Эти параметры конфигурации говорят сами за себя и должны быть знакомы, если вы когда-либо настраивали определения базы данных.

Листинг 4. Настройка хранилища идентификационных данных в базе данных
@DatabaseIdentityStoreDefinition(
   dataSourceLookup = "${'java:global/permissions_db'}",
   callerQuery = "#{'select password from caller where name = ?'}",
   groupsQuery = "select group_name from caller_groups where caller_name = ?",
   hashAlgorithm = PasswordHash.class,
   priority = 10
)
@ApplicationScoped
@Named
public class ApplicationConfig { ... }

Обратите внимание, что в листинге 4 приоритеты должны быть установлены на 10. Найдено в памяти множество идентифицирующих и определяющих порядок итерации по отношению к другому хранилищу. Чем меньше число, тем выше приоритет.

Конфигурация LDAP, как описано в листинге 5, очень проста. Если у вас есть опыт семантической настройки LDAP, вы найдете эти параметры очень знакомыми.

Листинг 5. Настройка хранилища удостоверений LDAP
@LdapIdentityStoreDefinition(
   url = "ldap://localhost:33389/",
   callerBaseDn = "ou=caller,dc=jsr375,dc=net",
   groupSearchBase = "ou=group,dc=jsr375,dc=net"
)
@DeclareRoles({ "admin", "user", "demo" })
@WebServlet("/admin")
public class AdminServlet extends HttpServlet { ... }

Пользовательское хранилище удостоверений

Проектирование собственного легкого магазина идентичности легко. вам нужно реализоватьIdentityStoreИнтерфейс, по крайней мереvalidate()метод. В интерфейсе есть четыре способа, и все они имеют реализации по умолчанию.validate()Этот метод является минимумом, необходимым для запуска хранилища удостоверений. он принимаетCredentialэкземпляр, затем возвратCredentialValidationResultsпример.

В листинге 6validate()способ получить сообщение, содержащее учетные данные для входа для проверкиUsernamePasswordCredentialэкземпляр, затем возвращаетCredentialValidationResultsпример.如果简单的配置逻辑促使身份验证成功，则使用用户名和用户所属组配置该对象。如果身份验证失败，那么CredentialValidationResultsЭкземпляр содержит только флаги состоянияINVALID.

Листинг 6. Настроенное облегченное хранилище удостоверений
@ApplicationScoped
public class LiteWeightIdentityStore implements IdentityStore {
   public CredentialValidationResult validate(UsernamePasswordCredential userCredential) {
       if (userCredential.compareTo("admin", "pwd1")) {
           return new CredentialValidationResult("admin", 
		       new HashSet<>(asList("admin", "user", "demo")));
       }
       return INVALID_RESULT;
   }
}

Обратите внимание, что реализация основана на@ApplicationScopeАннотированный. Это необходимо, потому чтоIdentityStoreHandlerСохранить все управление контейнерами CDIIdentityStoreСсылка на экземпляр компонента.@ApplicationScopeАннотация гарантирует, что экземпляр является компонентом, управляемым CDI, и экземпляр компонента доступен для всего приложения.

Чтобы использовать собственное упрощенное хранилище удостоверений, вы можетеHttpAuthenticationMechanismинъекцияIdentityStoreHandler, как показано в листинге 7.

Листинг 7. Внедрение LiteWeightIdentityStore в пользовательский механизм HttpAuthenticationMechanism
@ApplicationScoped
public class LiteAuthenticationMechanism implements HttpAuthenticationMechanism {
   @Inject
   private IdentityStoreHandler idStoreHandler;
   @Override
   public AuthenticationStatus validateRequest(HttpServletRequest req, 
											   HttpServletResponse res, 
											   HttpMessageContext context) {
       CredentialValidationResult result = idStoreHandler.validate(
               new UsernamePasswordCredential(
                       req.getParameter("name"), req.getParameter("password")));
       if (result.getStatus() == VALID) {
           return context.notifyContainerAboutLogin(result);
       } else {
           return context.responseUnauthorized();
       }
   }
}

SecurityContext API

IdentityStoreиHttpAuthenticationMechanismАутентификация пользователя и авторизация — идеальное сочетание, но их декларативная модель еще не родилась.защитное кодирование программыразрешить веб-приложениям выполнять проверки, необходимые для авторизации или отказа в доступе к ресурсам приложения,SecurityContextAPI обеспечивает это функциональное требование.

В настоящее время контейнеры Java EE несовместимы в том, как они реализуют объекты контекста безопасности. Например, контейнер сервлетов предоставляетHttpServletRequestэкземпляр для вызоваgetUserPrincipal()метод для получения представления о личности пользователяUserPrincipal. Контейнер EJB предоставляет другое имяEJBContextэкземпляр, для которого вызывается одноименный метод. Точно так же, если вам нужно проверить, принадлежит ли пользователь роли, вы должныHttpServletRequestвызов по инстанцииisUserRole()метод, который затем вызывается в экземпляре EJBContextisCallerInRole().

Что такое контекстная безопасность

В корпоративном Java-приложенииКонтекст безопасностиПредоставляет доступ к информации, связанной с безопасностью, связанной с текущим аутентифицированным пользователем. Целью API SecurityContext является обеспечение согласованного доступа к соответствующему контексту безопасности приложения во всех контейнерах сервлетов и EJB.

новыйSecurityContextПредоставляет согласованный механизм для контейнеров Java EE для получения информации об аутентификации и авторизации. Новая спецификация Java EE Security требует использования как минимум контейнеров сервлетов и EJB.SecurityContext. Поставщики серверов также могут сделать его доступным в других контейнерах.

Метод интерфейса SecurityContext

SecurityContextИнтерфейсы предоставляют точки входа для обеспечения безопасности программы и являются инъекционными типами. Он имеет пять методов (все по умолчанию не реализованы), вот список и назначение методов:

  • Principal getCallerPrincipal();Если текущий звонящий не аутентифицирован, он возвращает NULL, в противном случае он возвращает к основной платформе, указывающий, что имя текущего пользователя было проверено.
  • Set getPrincipalsByType(Class pType);От субъекта вызывающего абонента, прошедшего проверку подлинности, возвращаются все принципалы данного типа; если они не найденыpTypetype или текущий пользователь не аутентифицирован, возвращается пустая коллекция.
  • boolean isCallerInRole(String role);Определяет, включен ли вызывающий абонент в указанную роль; возвращает false, если он не авторизован.
  • boolean hasAccessToWebResource(String resource, String... methods);Определяет, может ли вызывающий объект получить доступ к данному веб-ресурсу с помощью предоставленного метода.
  • AuthenticationStatus authenticate(HttpServletRequest req, HttpServletResponse res, AuthenticationParameters param);: уведомляет контейнер о том, что он должен начать или продолжить сеанс с вызывающей стороной на основе HTTP-аутентификации. потому что это зависит отHttpServletRequestиHttpServletResponseinstance, поэтому этот метод работает только в контейнере сервлета.

Кратко остановимся на использовании одного из этих методов для проверки доступа пользователей к веб-ресурсам.

Использование SecutiytContext: пример

В листинге 8 показано, как использоватьhasAccessToWebResource()Метод проверяет доступ вызывающей стороны к заданному веб-ресурсу для указанного метода HTTP. В этом случаеSecurityContextэкземпляр вводится в сервлет иdoGet()Метод, используемый для проверки URI вызывающего абонента./secretServletсервлетGETдоступ к методу.

Листинг 8. Проверка доступа вызывающего абонента к веб-ресурсу
@DeclareRoles({"admin", "user", "demo"})
@WebServlet("/hasAccessServlet")
public class HasAccessServlet extends HttpServlet {
  
   @Inject
   private SecurityContext securityContext;
   @Override
   public void doGet(HttpServletRequest req, HttpServletResponse res) 
			throws ServletException, IOException {
       boolean hasAccess = securityContext.hasAccessToWebResource("/secretServlet", "GET");
       if (hasAccess) {
           req.getRequestDispatcher("/secretServlet").forward(req, res);
       } else {
           req.getRequestDispatcher("/logout").forward(req, res);
       }
   }
}

Краткое содержание первой части

Новый Java EE Security API успешно сочетает в себе существующие механизмы аутентификации и авторизации с простотой использования, ожидаемой разработчиками от современных функций и технологий Java EE.

Хотя первоначальной целью этого API было стремление решить проблемы безопасности согласованным и переносимым способом, он все еще нуждается в дальнейшем совершенствовании. В будущих выпусках группа экспертов JSR 375 намерена интегрировать API-интерфейсы для псевдонимов паролей, назначения ролей и разрешений, а также авторизации перехватчиков — функции, которые еще не включены в спецификацию v1.0.

В то же время комиссия также хотела интегрировать такие функции, как управление паролями и шифрование, которые имеют решающее значение для общего использования в локальных облачных и микросервисных приложениях. Кроме того, 2016 г.Опрос сообщества Java EEТакже было показано, что OAuth2 и OpenID были выбраны в качестве третьей важной функции для включения в Java EE 8. Хотя из-за ограничений по времени эти функции были исключены из версии 1.0, действительно есть причины и мотивы для включения их в предстоящий выпуск.

Теперь, когда у вас есть приблизительное представление об основных функциях и компонентах нового Java EE Security API, я рекомендую вам проверить полученные знания с помощью приведенного ниже быстрого теста. В следующей статье будет подробноHttpAuthenticationMechanismИнтерфейс и три механизма аутентификации, которые он поддерживает для Servlet 4.0.

Проверьте свое понимание

  1. три по умолчаниюHttpAuthenticationMechanismЧто такое реализация?
    1. @BasicFormAuthenticationMechanismDefinition
    2. @FormAuthenticationMechanismDefinition
    3. @LoginFormAuthenticationMechanismDefinition
    4. @CustomFormAuthenticationMechanismDefinition
    5. @BasicAuthenticationMechanismDefinition
  2. Какие две из следующих аннотаций активируют встроенное хранилище идентификаторов LDAP и RDBMS?
    1. @LdapIdentityStore
    2. @DataBaseIdentityStore
    3. @DataBaseIdentityStoreDefinition
    4. @LdapIdentityStoreDefinition
    5. @RdbmsBaseIdentityStoreDefinition
  3. Какое из следующих утверждений является правильным?
    1. IdentityStoreТолько дляHttpAuthenticationMechanismреализация.
    2. IdentityStoreМожет использоваться с любым встроенным или пользовательским решением политики безопасности.
    3. IdentityStoreтолько путем инъекцииIdentityStoreHandlerдоступна только реализация.
    4. IdentityStoreНе могу пройтиHttpAuthenticationMechanismреализация для использования.
  4. SecurityContextКакова цель?
    1. Обеспечивает согласованность безопасного доступа через контекстные контейнеры сервлета и EJB.
    2. Согласованность обеспечивается только для безопасного доступа к контексту контейнера EJB.
    3. Обеспечивает последовательный безопасный доступ ко всем контекстам контейнера.
    4. Обеспечивает постоянный доступ к контекстно-безопасному доступу к контейнеру сервлетов.
    5. Обеспечивает согласованность контекстно-безопасного доступа между контейнерами EJB.
  5. ПочемуHttpAuthenticationMechanismРеализация должна быть@ApplicationScoped?
    1. Чтобы убедиться, что это управляемый компонент CDI и доступен для всего приложения.
    2. чтобыHttpAuthenticationMechanismДоступно на всех уровнях приложения.
    3. Для того, чтобы каждый пользователь имелHttpAuthenticationMechanismпример.
    4. JsonAdapter.
    5. Это не правильное утверждение.

Проверьте свой ответ.

Если вы обнаружите ошибки в переводе или в других областях, требующих доработки, добро пожаловать наПрограмма перевода самородковВы также можете получить соответствующие бонусные баллы за доработку перевода и PR. начало статьиПостоянная ссылка на эту статьюЭто ссылка MarkDown этой статьи на GitHub.

Программа перевода самородковэто сообщество, которое переводит высококачественные технические статьи из Интернета сНаггетсДелитесь статьями на английском языке на . Охват контентаAndroid,iOS,внешний интерфейс,задняя часть,блокчейн,продукт,дизайн,искусственный интеллектЕсли вы хотите видеть более качественные переводы, пожалуйста, продолжайте обращать вниманиеПрограмма перевода самородков,официальный Вейбо,Знай колонку.

Категории