Book book = JsonbBuilder.create().fromJson(bookJson, Book.class);
The static create() factory method returns an instance of Jsonb. You may call a number of overloadedtoJson() and fromJson() methods on that instance. Note, also, that the specification does not mandate round-trip equivalences: in the above example, feeding the bookJson string into the fromJson() method might not deserialize to an equivalent object.
JSON-B also supports binding collection classes and arrays of primitives and/or instances—including multi-dimensional arrays—in much the same way as objects.
Java EE Security API
The new Java EE Security API was introduced to correct inconsistencies in how security concerns are implemented across servlet containers. This issue has been especially noticeable in the Java web profile, primarily because Java EE only mandates how the full Java EE profile must implement standard APIs. The new specification also introduces modern capabilities such as CDI, which existing APIs don't leverage.
The beauty of this API is that it provides an alternative way to configure identity stores and authentication mechanisms, but does not replace existing security mechanisms. Developers should welcome the opportunity to enable security in Java EE web applications, with or without vendor-specific or proprietary solutions.
What’s in the specification?
The Java EE Security API specification addresses three key concerns:
HttpAuthenticationMechanism supports authentication for the servlet container.
IdentityStore standardizes the JAAS LoginModule.
SecurityContext provides an access point for programmatic security.
I'll touch on each of these components below.
Java EE already specifies two mechanisms for authenticating web application users: The Java Servlet specification 3.1 (JSR-340) specifies a declarative mechanism for application configuration, while JASPIC (Java Authentication Service Provider Interface for Containers) defines an SPI called ServerAuthModule, which supports the development of authentication modules to handle any credential type.
Both of these mechanisms are meaningful and effective, but each is limited from the point of view of a web application developer. The servlet container mechanism is restricted to supporting only a small range of credential types. And while JASPIC is very powerful and flexible, it is also rather complicated to use.
The Java EE Security API seeks to resolve these issues with a new interface: HttpAuthenticationMechanism. Essentially a simplified, servlet-container variant of the JASPICServerAuthModule interface, it leverages existing mechanisms while alleviating their limitations.
An instance of the HttpAuthenticationMechanism type is a CDI bean, which is available to the container for injection and is specified for the servlet container only. The specification explicitly excludes other containers such as EJB and JMS.
The HttpAuthenticationMechanism interface defines three methods: validateRequest(), secureResponse(), and cleanSubject(). These closely resemble the methods declared on the JASPIC ServerAuth interface, so they should be familiar to developers. The only method required to be overridden is validateRequest(); all of the other methods have default implementations.
An identity store is a database that stores user identity data such as user name, group membership, and information used to verify credentials. In the new Java EE Security API, an identity store abstraction called IdentityStore is used to interact with identity stores. Its purpose is to authenticate users and retrieve group memberships.
As the specification is written, it is intended that IdentityStore be used byHttpAuthenticationMechanism implementations, although that isn’t a requirement. Using IdentityStore and HttpAuthenticationMechanism together enables an application to control its identity store in a portable and standard way.
Together, IdentityStore and HttpAuthenticationMechanism make a powerful new tool for user authentication. Nevertheless, system-level security requirements could make the declarative model insufficient. This is where SecurityContext comes in: programmatic security allows a web application to perform the tests required to grant or deny access to application resources.