The need to put security elements in place is determined based on:
- the importance, type and sensitivity of the information to display,
- the categories of public accessing the information,
- the different available interactions with the information (read, create, change, delete).
If only certain users or groups of users must be allowed to access certain information or only certain users or groups of users must be allowed to create, change or delete certain information, a resource security strategy must be implemented.
Security via the standard mechanisms provided by the Java EE container
The Java EE container hosting the Adelia Studio REST Web services natively offers solutions to secure the resources, aided by authentication management and authorization management.
However, resource security management by mechanisms specific to the Java EE container do not fully meet the requirements imposed by the stateless communication REST paradigm. In fact, Java EE authentication is based on a mechanism that stocks information on the resource server (management of a context by an authenticated client). This mechanism also has the disadvantage of setting up a strong link between authentication and access to resources. It therefore prohibits the delegation of the authentication phase to a third party.
Security via the Java EE container is still possible though and can be combined with authorization management via annotations in Adelia services programs.
Security via a token (JWT)
To compensate for the disadvantages caused by the native security mechanisms of Java EE containers, Adelia Studio offers resource security management using JWTs (Json Web Tokens).
The security mechanism is implemented in two steps:
- The first step consists in authenticating the client requesting the resources.
This accesses an authentication service which delivers a JWT in exchange for valid credentials.
The token contains various information through claims such as name of authenticated user, list of roles and token validity time limit. To ensure its confidentiality, the token is digitally signed using an encryption key. - The second step involves accessing the required resource by providing the resource server with the previously obtained token via the Authorization HTTP header.
Access to the resource therefore relies on the token validity and the checking of authenticated client roles against the required authorizations.