| Excerpt |
|---|
Describes how messages requesting operation on a collection is are checked against the permission model. |
...
| Child pages (Children Display) | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...
Authorisation
The permissions are defined on a pr. certificate based for each operation or set of operations. See RepositorySettings for detailes model.
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:
| Code Block |
|---|
openssl smime -sign -md sha512 -binary -nocerts -noattr -in message -out new.sig -outform der -inkey pkey.pem -signer cert.pem |
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:
| Code Block |
|---|
openssl smime -verify -in new.sig -inform der -noverify -content message -certfile cert.pem |
Where:
...
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).