Securing inputs
Input value validity check
By default, an input value which is invalid in terms of the underlying Java type is systematically rejected.
However, a value can be valid in terms of the underlying Java type but invalid in terms of its Adelia definition. To systematically reject these inputs, the following keys must be declared in the CfgConfiguration.properties file of the web application:
REST_CHECK_INPUT_STRING_ADELIA_LENGTH_VIOLATION=true
This key, with the true value, is used to reject a string which is longer than its Adelia definition.
Note: By default, the string is automatically truncated to comply with the Adelia length.
REST_CHECK_INPUT_NUMBER_ADELIA_LENGTH_VIOLATION=true
This key, with the true value, is used to systematically reject a string which is longer than its Adelia definition (NUM_E and NUM_P types).
REST_CHECK_INPUT_DATE_TIME_VIOLATION=true
This key, with the true value, is used to systematically reject an invalid formatted numeric value or string for DATE, TIME and TIMESTAMP types.
In addition, specific keys are used to track, at ERROR level, the detection of the violations listed above (independently of the mode chosen to process these violations):
REST_CHECK_INPUT_STRING_ADELIA_LENGTH_VIOLATION_LOG_MESSAGE= true
This key, with the true value, is used to track a string which is longer than its Adelia definition.
REST_CHECK_INPUT_NUMBER_ADELIA_LENGTH_VIOLATION_LOG_MESSAGE=true
This key, with the true value, is used to track a numeric value which is longer than its Adelia definition (NUM_E and NUM_P types).
REST_CHECK_INPUT_DATE_TIME_VIOLATION_LOG_MESSAGE=true
This key, with the true value, is used to track a numeric value or invalid formatted string for the DATE, TIME and TIMESTAMP types.
Note: By default, all these keys have the false value.
Securing access
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.