As one of the most important aspects of modern business applications and services, the security of the Java enterprise-grade applications didn't wait for the Jakarta EE 10 outbreak.
It evolved little by little with the gradual development of specifications, but the JSR-375 as we know it today appeared a couple of years ago with Jakarta EE 8, under the name of Java EE Security API 1.0.
The current release of the Jakarta EE 10 comes with a major update of Java EE Security API under its new name: Jakarta Security 3.0.
The concept of authorization mechanism, as defined by the Jakarta Security specifications, designates controllers that interact with a caller and a container environment to obtain credentials, validate them, and pass an authenticated identity to the container.
In order to validate the credentials, the authorization mechanisms use identity stores.
The specifications define built-in identity stores for files, RDBMS and LDAP servers, in addition to fully customized ones.
In this blog, we'll look at how to secure Java web applications using Jakarta Security built-in RDBMS and LDAP-based identity stores.
We chose Payara as the Jakarta EE platform to illustrate this, but the process should be the same, whatever the Jakarta EE-compliant implementation might be.
An aggregator POM called jsr-375 A WAR artifact called servlet-with-ldap-identity-store, demonstrating the LDAP built-in identity store.
A WAR artifact called servlet-with-jdbc-identity-store, demonstrating the LDAP built-in identity store.
Sql, which will be run in order to create and initialize the H2 schema required for the use of our identity store.
This class defines the configuration of our RDBMS identity store.
The idea behind the RDBMS identity store is that the principal-related information is stored in a relational database.
This information will be further transmitted to the database identity store mechanism which will compare them with the ones stored in the database.
This way we're composing two JSR-375 security features, the HTTP basic authentication associated with the database Identity Store.
This class is responsible for the creation and initialization of the data model required by the database identity store mechanism.
Using relational databases to store security principal-related information is a quite common practice; however, these databases aren't exactly the right tool for such use cases.
More often than not, organizations use Microsoft ActiveDirectory to store users, groups, and roles-related information together with their associated credentials and other information.
This class defines the configuration of our LDAP-based identity store.
These credentials will be used in order to authenticate against the ones stored in our LDAP service, listening for connections on the container's 33389 TCP port.
This Cyber News was published on feeds.dzone.com. Publication date: Thu, 11 Jan 2024 17:43:04 +0000