新的安全性API
可能，添加到Java EE 8中最重要的一项新功能就是新的安全性API。
此新API的主要动机是简化，标准化和现代化跨容器和实现处理安全性问题的方式。 他们做得很好。
- 由于三个新的注释使web.xml文件声明变得多余，Web身份验证的配置已经实现了现代化。
- 新的Security Context API标准化了Servlet和EJB容器执行身份验证以及
- 新的Identity S 撕裂抽象以简化身份存储的使用。
现在，让我们看看这些新功能中的第一个。
注释驱动的认证机制
此功能全部与配置Web安全有关。 web.xml文件中需要哪种传统的XML声明。
有了HttpAuthenticationMechanism接口，该接口代表HTTP身份验证，并带有三个内置的启用CDI的实现，每个实现都可以表示可配置Web安全的三种方式之一，因此不再需要此操作。
使用这些注释之一触发它们。
@BasicAuthenticationMechanismDefinition
@FormAuthenticationMechanismDefinition
@CustomFormAuthenticationMechanismDefinition它们复制了servlet容器中已经可用的经典HTTP基本身份验证，表单和基于自定义表单的身份验证的功能。
例如，要启用基本身份验证， 仅需向您的servlet添加BasicAuthenticationMechanismDefinition批注即可。
@BasicAuthenticationMechanismDefinition(realmName="${'user-realm'}")
@WebServlet("/user")
@DeclareRoles({ "admin", "user", "demo" })
@ServletSecurity(@HttpConstraint(rolesAllowed = "user"))
public class UserServlet extends HttpServlet { … }现在，您可以放弃XML配置，并使用这些新注释之一来提高Web安全性。
安全API的下一个重要功能是身份存储抽象。
身份存储抽象
身份存储是一个数据库，用于存储用户标识数据，例如用户名，组成员身份以及用于验证凭据的信息。
新的Java EE安全API提供了一个称为IdentityStore的身份存储抽象，该身份存储抽象用于与身份存储交互以认证用户并检索组成员身份，类似于JAAS LoginModule接口。
HttpAuthenticationMechanism实现旨在使用IdentityStore ，但这不是必需的 。 IdentityStore可以独立存在，并且可以由应用程序开发人员希望的任何其他身份验证机制使用。
尽管如此， IdentityStore和HttpAuthenticationMechanism的共同使用使应用程序能够以可移植的标准方式控制用于身份验证的身份存储，这是大多数用例场景的推荐方式。
现在，您可以通过实现IdentityStore接口来实现自己的身份存储，或者可以将内置的IdentityStore实现之一用于LDAP和关系数据库。 通过将配置详细信息传递给适当的注释@LdapIdentityStoreDefinition或@DataBaseIdentityStoreDefinition来初始化它们。
让我们看一下内置身份存储的用法。
最简单的身份存储是数据库存储。 它通过@DataBaseIdentityStoreDefinition批注进行配置，如下所示。
@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 { ... }配置选项非常容易解释，如果您已经配置了数据库定义，则应该熟悉它们。
但是，请注意将优先级设置为10，在运行时找到多个标识存储库并确定相对于其他存储库的迭代顺序时使用。 数字越小优先级越高。
现在，让我们看一下安全性API的最终新功能。
安全上下文
安全上下文的目标是在Servlet和EJB容器之间提供对安全上下文的一致访问。
当前，这些容器不一致地实现了安全上下文对象。 例如，servlet容器提供一个HttpServletRequest实例，在该实例上调用getUserPrincipal（）方法以获得用户Principal ，而EJB容器提供一个不同名称的EJBContext实例，在该实例上调用相同的命名方法。 同样地，以测试用户是否属于某个角色的方法isUserRole（）调用HttpServletRequest的实例和isCallerInRole（）被调用上EJBContext的实例。
SecurityContext在Servlet和EJB容器之间提供一致性，以获取此类信息。 它有五个方法，没有一个具有默认实现。
委托人getCallerPrincipal（）; 返回表示当前经过身份验证的用户名的特定于平台的主体，如果当前调用方未经过身份验证，则返回null。
<T扩展Principal> Set <T> getPrincipalsByType（Class <T> pType）; 从经过身份验证的调用者的Subject返回给定类型的所有Principal ，否则，如果未找到pType类型或当前用户未经过身份验证，则返回一个空Set 。
boolean isCallerInRole（String role）; 确定呼叫者是否包含在指定角色中，否则，如果用户未被授权，则返回false。
boolean hasAccessToWebResource（String resource，String…方法）; 确定调用者是否可以通过提供的方法访问给定的Web资源。
AuthenticationStatus authenticate（HttpServletRequest req，HttpServletResponse res，AuthenticationParameters param）; 通知容器它应该开始或继续与调用方进行基于HTTP的身份验证对话。 由于此方法依赖于HttpServletRequest和HttpServletResponse实例，因此只能在servlet容器中使用。
安全上下文是一个CDI bean，因此可以注入到servlet和EJB容器中的任何类中。
@Inject
private SecurityContext securityContext;有了SecurityContext实例，您可以调用任何方法来访问对上下文敏感的安全信息。
boolean hasAccess = securityContext .hasAccessToWebResource("/secretServlet", "GET");现在，结束了对安全性API的概述，对安全性API有更多的了解。
翻译自: https://www.javacodegeeks.com/2018/04/java-ee-8-security-api-overview.html
