Excerpt
| Excerpt |
|---|
Describes how messages requesting operation on a collection are checked against the permission model. |
| Child pages (Children Display) | ||||||||
|---|---|---|---|---|---|---|---|---|
|
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
...
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).