JavaEE Standards and Terminologies

Standards

Standards are good. They allow us to create an application that is not tied to a certain environment, runtime, or vendor.

Consider JVM, which is standardized. We can write and compile it on one OS (e.g. Windows) and run it on any other supported OS (e.g. Linux). Furthermore, consider SQL and how we can retrieve data from the database, regardless of the vendor.

There is always a struggle between the slow process of defining a standard and implementing it and the fast-responding framework. Standards are also created when a technology or way of working has proven itself over time, or after enough expertise is gathered around a topic to develop best practices.

Although there are elements of security available in older versions of Java EE, Java EE 8, released in September 2018, launched an overall security specification, the Security API specification.

The best way to illustrate this is through the example given below. This example shows the different ways of retrieving the current user. Each Jakarta EE part has its methods.

There are two low-level JSRs (Java Specification Requests) around Security available.

• JASPIC (Java Authentication Service Provider Interface for Containers), introduced in Java EE 6, for authentication.

• JACC (Java Authorization Service Provider Contract for Containers), introduced in J2EE 1.4, for authorization.

However, these JSRs are old (JACC), not developer-friendly (because a JACC provider is server-wide and not application-specific), and difficult to use. Using JASPIC, for example, requires the creation of five additional classes to have the functionality available in the ServerAuthModule.

Another issue is that a considerable amount of application server-specific configuration is sometimes required, as not all details are standardized. This makes it much more difficult to transfer an application from one application server or runtime to another.

The creation of the Security API, a higher-level framework, makes it easier for the developer to use. The provided functionality makes it server independent by bringing the configuration into the application itself (except for some configuration keys that need to be independently defined for best practices) and extending it to our needs.

Security API terminology and concepts

One of the goals of the Security API was to standardize the names related to security in the Java Enterprise frameworks.

A good example of terminology confusion are the names currently in use to refer to the thing where identities are stored and validated. Each runtime or library has a component responsible for validating user credentials and providing the groups or roles for that user. Some of the components are as follows:

• Security provider (WebLogic)

• Realm (Tomcat, some hints in Servlet spec)

• Auth repository

• Auth store

• Login module (JAAS)

• Identity manager (Undertow)

• Authenticator (Resin, OmniSecurity, Seam Security)

• Authentication provider (Spring Security)

• Identity provider

We have used the term realm until now because it is used in servlet specification. The term used by the Security API is IdentityStore.