Page Comparison

ExcerptAll 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.

Signing messages

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 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

...

Authorisation

The process of authorising operations is to ensure that the client requesting an operation is allowed to do so. To authorise an operation it is a prerequisite that the message has been authenticated as described in Authentication.

Components participating in a Bit Repository where RequireOperationAuthorization in RepositorySettings have been set to true is required to authorise any operation prior to performing them. 

To authorise an operation a component must use the certificate used to sign the request and lookup its permissions in RepositorySettings.

• The operation can be authorised if the signing certificate have a suitable OperationPermission, see the Operation Permission model section for details.
• If no suitable OperationPermission can be found the component should reject the operation. 
  • In the event that the request is not an IdentifyRequest, i.e. an OperationRequest, the component should also send an Alarm to notify of the unauthorised request. 

Operation Permission model

The OperationPermissions consists of:

• An Operation type. There is one Operation type for each operation type (see Protocol messages), and a catch-all named "All"
• An optional list of allowed component IDs where the permission applies i.e. a certificate is allowed to delete a file on PillarA but not on PillarB. If the list is not present it implies that there is no restriction
• An optional list of collection IDs where the OperationPermission applies. If the list is not present it implies that there is no restriction

To be a "suitable" OperationPermission, a request should match all of the available constraints (Operation type, component ID and collection ID).