Jakarta EE 8 Security API

1. Ikhtisar

Jakarta EE 8 Security API adalah standar baru dan cara portabel menangani masalah keamanan di container Java.

Di artikel ini, kita akan melihat tiga fitur inti dari API:

  1. Mekanisme Otentikasi HTTP
  2. Penyimpanan Identitas
  3. Konteks Keamanan

Pertama-tama kita akan memahami cara mengonfigurasi penerapan yang disediakan, lalu cara menerapkan penerapan kustom.

2. Ketergantungan Maven

Untuk menyiapkan Jakarta EE 8 Security API, kita memerlukan implementasi yang disediakan server atau yang eksplisit.

2.1. Menggunakan Implementasi Server

Server yang sesuai dengan Jakarta EE 8 sudah menyediakan implementasi untuk Jakarta EE 8 Security API, dan oleh karena itu kami hanya memerlukan artefak Maven API Profil Web Jakarta EE:

  javax javaee-web-api 8.0 provided  

2.2. Menggunakan Implementasi Eksplisit

Pertama, kami menentukan artefak Maven untuk Jakarta EE 8 Security API:

  javax.security.enterprise javax.security.enterprise-api 1.0  

Dan kemudian, kami akan menambahkan implementasi, misalnya, Soteria - implementasi referensi:

  org.glassfish.soteria javax.security.enterprise 1.0  

3. Mekanisme Otentikasi HTTP

Sebelum Jakarta EE 8, kami telah mengkonfigurasi mekanisme Otentikasi secara deklaratif melalui file web.xml .

Dalam versi ini, Jakarta EE 8 Security API telah mendesain antarmuka HttpAuthenticationMechanism baru sebagai pengganti. Oleh karena itu, aplikasi web sekarang dapat mengonfigurasi mekanisme Autentikasi dengan menyediakan implementasi antarmuka ini.

Untungnya, penampung sudah menyediakan implementasi untuk masing-masing dari tiga metode otentikasi yang ditentukan oleh spesifikasi Servlet: otentikasi HTTP dasar, otentikasi berbasis formulir, dan otentikasi berbasis formulir kustom.

Ini juga menyediakan anotasi untuk memicu setiap implementasi:

  1. @DasarPermanaDefinisi
  2. @Distroartonline
  3. @CustomizedCustomeration

3.1. Otentikasi HTTP Dasar

Seperti disebutkan di atas, aplikasi web dapat mengkonfigurasi Otentikasi HTTP Dasar hanya dengan menggunakan anotasi @BasicAuthenticationMechanismDefinition pada kacang CDI :

@BasicAuthenticationMechanismDefinition( realmName = "userRealm") @ApplicationScoped public class AppConfig{}

Pada titik ini, kontainer Servlet mencari dan membuat contoh implementasi yang disediakan dari antarmuka HttpAuthenticationMechanism .

Setelah menerima permintaan yang tidak sah, kontainer menantang klien untuk memberikan informasi otentikasi yang sesuai melalui header respon WWW-Authenticate .

WWW-Authenticate: Basic realm="userRealm"

Klien kemudian mengirimkan nama pengguna dan sandi, dipisahkan dengan titik dua ":" dan dikodekan dalam Base64, melalui header permintaan Otorisasi :

//user=baeldung, password=baeldung Authorization: Basic YmFlbGR1bmc6YmFlbGR1bmc= 

Perhatikan bahwa dialog yang ditampilkan untuk memberikan kredensial berasal dari browser dan bukan dari server.

3.2. Otentikasi HTTP berbasis formulir

The @FormAuthenticationMechanismDefinition penjelasan memicu otentikasi berbasis form seperti yang didefinisikan oleh spesifikasi Servlet.

Kemudian kami memiliki opsi untuk menentukan halaman login dan error atau menggunakan halaman default yang wajar / login dan / login-error :

@FormAuthenticationMechanismDefinition( loginToContinue = @LoginToContinue( loginPage = "/login.html", errorPage = "/login-error.html")) @ApplicationScoped public class AppConfig{}

Sebagai hasil dari memanggil loginPage, server harus mengirimkan formulir ke klien:

Klien kemudian harus mengirim formulir ke proses otentikasi dukungan yang telah ditentukan sebelumnya yang disediakan oleh penampung.

3.3. Autentikasi HTTP berbasis Formulir Kustom

Aplikasi web bisa memicu implementasi autentikasi berbasis formulir kustom dengan menggunakan anotasi @CustomFormAuthenticationMechanismDefinition:

@CustomFormAuthenticationMechanismDefinition( loginToContinue = @LoginToContinue(loginPage = "/login.xhtml")) @ApplicationScoped public class AppConfig { }

Tetapi tidak seperti otentikasi berbasis formulir default, kami mengonfigurasi halaman login khusus dan menjalankan metode SecurityContext.authenticate () sebagai proses otentikasi dukungan.

Mari kita lihat dukungan LoginBean juga, yang berisi logika login:

@Named @RequestScoped public class LoginBean { @Inject private SecurityContext securityContext; @NotNull private String username; @NotNull private String password; public void login() { Credential credential = new UsernamePasswordCredential( username, new Password(password)); AuthenticationStatus status = securityContext .authenticate( getHttpRequestFromFacesContext(), getHttpResponseFromFacesContext(), withParams().credential(credential)); // ... } // ... }

Sebagai hasil dari menyerukan kustom login.xhtml halaman, klien menyerahkan formulir diterima ke LoginBean' s login () metode:

//... 

3.4. Mekanisme Otentikasi Kustom

The HttpAuthenticationMechanism antarmuka mendefinisikan tiga metode. Yang paling penting adalah validateRequest () yang harus kita berikan implementasi.

Perilaku default untuk dua metode lainnya, secureResponse () dan cleanSubject () , cukup dalam banyak kasus.

Mari kita lihat contoh penerapannya:

@ApplicationScoped public class CustomAuthentication implements HttpAuthenticationMechanism { @Override public AuthenticationStatus validateRequest( HttpServletRequest request, HttpServletResponse response, HttpMessageContext httpMsgContext) throws AuthenticationException { String username = request.getParameter("username"); String password = response.getParameter("password"); // mocking UserDetail, but in real life, we can obtain it from a database UserDetail userDetail = findByUserNameAndPassword(username, password); if (userDetail != null) { return httpMsgContext.notifyContainerAboutLogin( new CustomPrincipal(userDetail), new HashSet(userDetail.getRoles())); } return httpMsgContext.responseUnauthorized(); } //... }

Here, the implementation provides the business logic of the validation process, but in practice, it's recommended to delegate to the IdentityStore through the IdentityStoreHandler by invoking validate.

We've also annotated the implementation with @ApplicationScoped annotation as we need to make it CDI-enabled.

After a valid verification of the credential, and an eventual retrieving of user roles, the implementation should notify the container then:

HttpMessageContext.notifyContainerAboutLogin(Principal principal, Set groups)

3.5. Enforcing Servlet Security

A web application can enforce security constraints by using the @ServletSecurity annotation on a Servlet implementation:

@WebServlet("/secured") @ServletSecurity( value = @HttpConstraint(rolesAllowed = {"admin_role"}), httpMethodConstraints = { @HttpMethodConstraint( value = "GET", rolesAllowed = {"user_role"}), @HttpMethodConstraint( value = "POST", rolesAllowed = {"admin_role"}) }) public class SecuredServlet extends HttpServlet { }

This annotation has two attributes – httpMethodConstraints and value; httpMethodConstraints is used to specify one or more constraints, each one representing an access control to an HTTP method by a list of allowed roles.

The container will then check, for every url-pattern and HTTP method, if the connected user has the suitable role for accessing the resource.

4. Identity Store

This feature is abstracted by the IdentityStore interface, and it's used to validate credentials and eventually retrieve group membership. In other words, it can provide capabilities for authentication, authorization or both.

IdentityStore is intended and encouraged to be used by the HttpAuthenticationMecanism through a called IdentityStoreHandler interface. A default implementation of the IdentityStoreHandler is provided by the Servletcontainer.

An application can provide its implementation of the IdentityStore or uses one of the two built-in implementations provided by the container for Database and LDAP.

4.1. Built-in Identity Stores

The Jakarta EE compliant server should provide implementations for the two Identity Stores: Database and LDAP.

The database IdentityStore implementation is initialized by passing a configuration data to the @DataBaseIdentityStoreDefinition annotation:

@DatabaseIdentityStoreDefinition( dataSourceLookup = "java:comp/env/jdbc/securityDS", callerQuery = "select password from users where username = ?", groupsQuery = "select GROUPNAME from groups where username = ?", priority=30) @ApplicationScoped public class AppConfig { }

As a configuration data, we need a JNDI data source to an external database, two JDBC statements for checking caller and his groups and finally a priority parameter which is used in case of multiples store are configured.

IdentityStore with high priority is processed later by the IdentityStoreHandler.

Like the database, LDAP IdentityStore implementation is initialized through the @LdapIdentityStoreDefinition by passing configuration data:

@LdapIdentityStoreDefinition( url = "ldap://localhost:10389", callerBaseDn = "ou=caller,dc=baeldung,dc=com", groupSearchBase = "ou=group,dc=baeldung,dc=com", groupSearchFilter = "(&(member=%s)(objectClass=groupOfNames))") @ApplicationScoped public class AppConfig { }

Here we need the URL of an external LDAP server, how to search the caller in the LDAP directory, and how to retrieve his groups.

4.2. Implementing a Custom IdentityStore

The IdentityStore interface defines four default methods:

default CredentialValidationResult validate( Credential credential) default Set getCallerGroups( CredentialValidationResult validationResult) default int priority() default Set validationTypes()

The priority() method returns a value for the order of iteration this implementation is processed by IdentityStoreHandler. An IdentityStore with lower priority is treated first.

By default, an IdentityStore processes both credentials validation (ValidationType.VALIDATE) and group retrieval(ValidationType.PROVIDE_GROUPS). We can override this behavior so that it can provide only one capability.

Thus, we can configure the IdentityStore to be used only for credentials validation:

@Override public Set validationTypes() { return EnumSet.of(ValidationType.VALIDATE); }

In this case, we should provide an implementation for the validate() method:

@ApplicationScoped public class InMemoryIdentityStore implements IdentityStore { // init from a file or harcoded private Map users = new HashMap(); @Override public int priority() { return 70; } @Override public Set validationTypes() { return EnumSet.of(ValidationType.VALIDATE); } public CredentialValidationResult validate( UsernamePasswordCredential credential) { UserDetails user = users.get(credential.getCaller()); if (credential.compareTo(user.getLogin(), user.getPassword())) { return new CredentialValidationResult(user.getLogin()); } return INVALID_RESULT; } }

Or we can choose to configure the IdentityStore so that it can be used only for group retrieval:

@Override public Set validationTypes() { return EnumSet.of(ValidationType.PROVIDE_GROUPS); }

We should then provide an implementation for the getCallerGroups() methods:

@ApplicationScoped public class InMemoryIdentityStore implements IdentityStore { // init from a file or harcoded private Map users = new HashMap(); @Override public int priority() { return 90; } @Override public Set validationTypes() { return EnumSet.of(ValidationType.PROVIDE_GROUPS); } @Override public Set getCallerGroups(CredentialValidationResult validationResult) { UserDetails user = users.get( validationResult.getCallerPrincipal().getName()); return new HashSet(user.getRoles()); } }

Because IdentityStoreHandler expects the implementation to be a CDI bean, we decorate it with ApplicationScoped annotation.

5. Security Context API

The Jakarta EE 8 Security API provides an access point to programmatic security through the SecurityContext interface. It's an alternative when the declarative security model enforced by the container isn't sufficient.

A default implementation of the SecurityContext interface should be provided at runtime as a CDI bean, and therefore we need to inject it:

@Inject SecurityContext securityContext;

At this point, we can authenticate the user, retrieve an authenticated one, check his role membership and grant or deny access to web resource through the five available methods.

5.1. Retrieving Caller Data

In previous versions of Jakarta EE, we'd retrieve the Principal or check the role membership differently in each container.

While we use the getUserPrincipal() and isUserInRole() methods of the HttpServletRequest in a servlet container, a similar methods getCallerPrincipal() and isCallerInRole() methods of the EJBContext are used in EJB Container.

The new Jakarta EE 8 Security API has standardized this by providing a similar method through the SecurityContext interface:

Principal getCallerPrincipal(); boolean isCallerInRole(String role);  Set getPrincipalsByType(Class type);

The getCallerPrincipal() method returns a container specific representation of the authenticated caller while the getPrincipalsByType() method retrieves all principals of a given type.

It can be useful in case the application specific caller is different from the container one.

5.2. Testing for Web Resource Access

First, we need to configure a protected resource:

@WebServlet("/protectedServlet") @ServletSecurity(@HttpConstraint(rolesAllowed = "USER_ROLE")) public class ProtectedServlet extends HttpServlet { //... }

And then, to check access to this protected resource we should invoke the hasAccessToWebResource() method:

securityContext.hasAccessToWebResource("/protectedServlet", "GET");

In this case, the method returns true if the user is in role USER_ROLE.

5.3. Authenticating the Caller Programmatically

An application can programmatically trigger the authentication process by invoking authenticate():

AuthenticationStatus authenticate( HttpServletRequest request, HttpServletResponse response, AuthenticationParameters parameters);

The container is then notified and will, in turn, invoke the authentication mechanism configured for the application. AuthenticationParameters parameter provides a credential to HttpAuthenticationMechanism:

withParams().credential(credential)

The SUCCESS and SEND_FAILURE values of the AuthenticationStatus design a successful and failed authentication while SEND_CONTINUE signals an in progress status of the authentication process.

6. Running the Examples

For highlighting these examples, we've used the latest development build of the Open Liberty Server which supports Jakarta EE 8. This is downloaded and installed thanks to the liberty-maven-plugin which can also deploy the application and start the server.

To run the examples, just access to the corresponding module and invoke this command:

mvn clean package liberty:run

As a result, Maven will download the server, build, deploy, and run the application.

7. Conclusion

Pada artikel ini, kami membahas konfigurasi dan implementasi fitur utama API Keamanan Jakarta EE 8 yang baru.

Pertama, kami mulai dengan menunjukkan cara mengonfigurasi mekanisme autentikasi bawaan default dan cara menerapkan mekanisme khusus. Kemudian, kami melihat cara mengonfigurasi Penyimpanan Identitas bawaan dan cara menerapkan penyimpanan khusus. Dan akhirnya, kami melihat cara memanggil metode SecurityContext.

Seperti biasa, contoh kode untuk artikel ini tersedia di GitHub.