Security Options
The component offers different solutions about security, ensuring the validation and encryption of messages, certificates storage, clients authentication and so on. Regarding validation and encryption of messages and the user authentication, when a new component is created all the security policies will be disabled by default, stopping the initialization of the server: indeed, in order to correctly start a new one, at least one message security policy (from now on security meethod) and one user authentication method (from now on user token) must be enabled.
Security methods
In the component settings, three different security methods can be enabled/disabled depending on the levels of message validation that the user wants to be implemented by the server. The three options are:
- None: communication through unencrypted and unsigned messages
- Sign: messages are signed but unencrypted
- Sing and Encrypt: messages are validated as in Sign mode, but also encrypted to increase security
The three options are independent from each other, so the users can decide to implement just one option, or all of them; but at least one of them, in addition to one user token, must be enabled to start the server.
The cryptography algorithms supported by the server are:
| ALGORITHM | DESCRIPTION |
|---|---|
| AES128 | 128-bit Advanced Encryption Standard |
| AES256 | 256-bit Advanced Encryption Standard |
| Basic128RSA15 | 128-bit message encryption and RSA15 key wrap algorithm |
| Basic256 | 256-bit message encryption |
| Basic256SHA256 | 256-bit message encryption and SHA256 for signature digest |
All these version are supported in both Sign and SignAndEncrypt modes. For example, a client could access the server with the AES128_SIGN or AES128_SIGN_ENCRYPT security mode.
User Token
Regarding the clients authentication, three different policies are offered by the component options. If multiple modes are enabled, the client will select which one to use.
- Anonymus: clients are not required to provide an user identity
- Username and Password: clients are required to be authenticated through an username and password
- Certificates: clients provide a valid certificate as their user identity
Username and Password
An user must always set an username and password, even if the token is disabled, and it is highly reccomended to set a strong password to ensure the maximum security level. If the token is disabled, these field will be simply ignored. When a client tries to access the server with this token policy, the user and password must match the ones set in this section of the options.
Certificates
Finally, a client can connect to the server through its certificate, that will be stored inside the certificates folder after trusting process, described in the dedicated certificates' section.