Excerpt |
---|
Authorization management is necessary because all clients/systems operating within a given SLA may not be allowed to have equal access to data |
Excerpt |
---|
To ensure messages are transmitted, untampered signature based authentication is used. |
Authentication
The process of authentication have two purposes:
- To ensure that the message was sent by someone allowed to do so, and
- To establish that the message was not tampered with
To authenticate a message a signature is required and a set of trusted certificates. The former is described in the following section, the latter is obtained from RepositorySettings as certificates having either an OperationPermission or the InfrastructurePermission MessageSigner. Further restrictions on which component IDs are allowed to use a certificate may be imposed. If a certificate has a non-empty AllowedCertificateUsers list, the components ID must be present in that list for the message to be authenticated.
Components participating in a Bit Repository where RequireMessageAuthentication in RepositorySettings have been set to true is required to:
- Sign any message that they send
- Authenticate any message that they receive. If a message cannot be authenticated either due to missing signature or because it has been tampered with, the message should be disregarded and an Alarm sent
Signing messages
All messages in the system must be signed to ensure that the senders of the messages are who they claim they are and that the messages have not been tampered with.
Because messages are exchanged encapsulated in XML, there are two well defined ways to handle signing of the messages. One is XML Signatures, the other - and somewhat simpler - is Cryptographic Message Syntax - also known as PKCS#7. As one of the objectives is to prevent message tampering, there is no need for the granularity of XML Signatures. Therefore Cryptographic Message Syntax - or CMS for short - is chosen for signing and optionally encrypting messages. The identity of the signer is embedded in the public certificate.
The hash algorithm for the generation of the message hash is SHA512. The signing certificate is excluded from the signature to reduce the size.
The message signature is calculated on the message xml interpreted as a utf-8-encoded byte stream and transmitted, base 64-encoded, in the message header org.bitrepository.messages.signature.
Signature generation and verification
To generate a signature openssl can be used:
|
Where:
- message is a file with the message to create a signature for
- new.sig is a file containing the signature
- pkey.pem is a file containing the signers private key
- cert.pem is a file containing the signers certificate
To verify a signature with openssl the following can be used:
|
Where:
- message is a file with the message to create a signature for
- new.sig is a file containing the signature (binary data, not base64 encoded)
- cert.pem is a file containing the signers certificate (ID of the certificate used for signing can be extracted from the signature it self. This can be used to obtain the signing certificate from the components trust).
Child pages (Children Display) | ||||||||
---|---|---|---|---|---|---|---|---|
|