Jakarta EE 8 Security API

1. Panoramica

L'API di sicurezza Jakarta EE 8 è il nuovo standard e un modo portatile per gestire i problemi di sicurezza nei container Java.

In questo articolo, esamineremo le tre funzionalità principali dell'API:

  1. Meccanismo di autenticazione HTTP
  2. Negozio di identità
  3. Contesto di sicurezza

Capiremo prima come configurare le implementazioni fornite e poi come implementarne una personalizzata.

2. Dipendenze di Maven

Per configurare l'API di sicurezza Jakarta EE 8, abbiamo bisogno di un'implementazione fornita dal server o di una esplicita.

2.1. Utilizzo dell'implementazione del server

I server compatibili con Jakarta EE 8 forniscono già un'implementazione per l'API di sicurezza Jakarta EE 8, quindi è necessario solo l'artefatto Maven dell'API del profilo Web di Jakarta EE:

  javax javaee-web-api 8.0 provided  

2.2. Utilizzo di un'implementazione esplicita

Innanzitutto, specifichiamo l'artefatto Maven per l'API di sicurezza Jakarta EE 8:

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

Quindi, aggiungeremo un'implementazione, ad esempio Soteria, l'implementazione di riferimento:

  org.glassfish.soteria javax.security.enterprise 1.0  

3. Meccanismo di autenticazione HTTP

Prima di Jakarta EE 8, abbiamo configurato i meccanismi di autenticazione in modo dichiarativo tramite il file web.xml .

In questa versione, l'API di sicurezza Jakarta EE 8 ha progettato la nuova interfaccia HttpAuthenticationMechanism in sostituzione. Pertanto, le applicazioni Web possono ora configurare i meccanismi di autenticazione fornendo implementazioni di questa interfaccia.

Fortunatamente, il contenitore fornisce già un'implementazione per ciascuno dei tre metodi di autenticazione definiti dalla specifica Servlet: autenticazione HTTP di base, autenticazione basata su modulo e autenticazione basata su modulo personalizzata.

Fornisce inoltre un'annotazione per attivare ogni implementazione:

  1. @BasicAuthenticationMechanismDefinition
  2. @FormAuthenticationMechanismDefinition
  3. @CustomFormAuthenrticationMechanismDefinition

3.1. Autenticazione HTTP di base

Come accennato in precedenza, un'applicazione Web può configurare l'autenticazione HTTP di base semplicemente utilizzando l' annotazione @BasicAuthenticationMechanismDefinition su un bean CDI :

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

A questo punto, il contenitore Servlet cerca e istanzia l'implementazione fornita dell'interfaccia HttpAuthenticationMechanism .

Alla ricezione di una richiesta non autorizzata, il contenitore chiede al client di fornire adeguate informazioni di autenticazione tramite l' intestazione di risposta WWW-Authenticate .

WWW-Authenticate: Basic realm="userRealm"

Il client invia quindi il nome utente e la password, separati da due punti ":" e codificati in Base64, tramite l' intestazione della richiesta di autorizzazione :

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

Notare che la finestra di dialogo presentata per fornire le credenziali proviene dal browser e non dal server.

3.2. Autenticazione HTTP basata su modulo

L' annotazione @FormAuthenticationMechanismDefinition attiva un'autenticazione basata su form come definito dalla specifica Servlet.

Quindi abbiamo la possibilità di specificare le pagine di accesso e di errore o utilizzare quelle ragionevoli predefinite / login e / login-error :

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

Come risultato della chiamata di loginPage, il server dovrebbe inviare il modulo al client:

Il client deve quindi inviare il modulo a un processo di autenticazione di supporto predefinito fornito dal contenitore.

3.3. Autenticazione HTTP basata su form personalizzata

Un'applicazione Web può attivare l'implementazione dell'autenticazione basata su modulo personalizzato utilizzando l'annotazione @CustomFormAuthenticationMechanismDefinition:

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

Ma a differenza dell'autenticazione basata su modulo predefinita, stiamo configurando una pagina di accesso personalizzata e invocando il metodo SecurityContext.authenticate () come processo di autenticazione di supporto.

Diamo un'occhiata anche al LoginBean di supporto , che contiene la logica di accesso:

@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)); // ... } // ... }

Come risultato di invocare l'usanza login.xhtml pagina, il client invia il modulo ricevuto al 'LoginBean s login () Metodo:

//... 

3.4. Meccanismo di autenticazione personalizzato

L' interfaccia HttpAuthenticationMechanism definisce tre metodi. Il più importante è validateRequest () di cui dobbiamo fornire un'implementazione.

Il comportamento predefinito per gli altri due metodi, secureResponse () e cleanSubject () , è sufficiente nella maggior parte dei casi.

Diamo un'occhiata a un'implementazione di esempio:

@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

In questo articolo, abbiamo trattato la configurazione e l'implementazione delle funzionalità principali della nuova Jakarta EE 8 Security API.

Innanzitutto, abbiamo iniziato mostrando come configurare i meccanismi di autenticazione incorporati predefiniti e come implementarne uno personalizzato. Successivamente, abbiamo visto come configurare Identity Store integrato e come implementarne uno personalizzato. Infine, abbiamo visto come chiamare i metodi di SecurityContext.

Come sempre, gli esempi di codice per questo articolo sono disponibili su GitHub.