Security Level / Access Permissions
Security Level / Access Permissions
The security level of a document is specified when the document is created and stored. When a document is accessed, the server establishes what functions a user may execute on this document. Similar functions are grouped together. The groups are called access modes. They are listed in the following table:
|
Access Mode |
Abbreviation |
|
Read |
r |
|
Create |
c |
|
Change |
u |
|
Delete |
d |
The security level applies to all components of a document.
If the access mode is "change", any component of a document may be deleted.
The access mode must be specified in the HTTP request as a parameter (accessMode). A combination of access modes can be specified, for example, ud. A secKey confirms the right of access. In the descriptions of individual functions, the corresponding access mode is specified. When a document is accessed, the content server checks whether the secKey should be checked, that is, whether a function of the document is protected, and if so, what security level it has. It therefore makes sense that any user may read documents, while only certain users may change them. In this case, read protection is deactivated (no secKey is required). For write and delete access, however, a secKey must be transferred. The fact that the secKey can only be generated by the SAP system ensures that an access protection check based on the SAP authorization concept is carried out.
The security level of a document is defined when the document is created. To do this, use the parameter docProt.
|
security level |
Description |
|
docProt= |
No access restrictions |
|
docProt=du |
Only signed (that is, authenticated) URLs may delete or update documents. The accessMode must have at least a d for delete operations, and at least a u for update operations.Read operations do not require any signature. |
You may transfer a number of access types, for example,
accessMode=rd in a read operation. This can be useful in certain situations. For example, if a get URL with accessMode=rd and a corresponding signature is transferred to a client program, the client has not only read permission but also delete permission for the document. To use the URL for deleting, simply replace the get command with the delete command, and do not transfer the compId. The same parameters are signed for both get and delete, so the signature remains valid. Because the accessMode contains a d, then, in this example it is possible to read and delete the document using the same signature.Based on the access type of an operation and the security level a document has, the Content Server decides whether it has to check the secKey. If the Content Server decides that no check is necessary, all s-mandatory parameters become obsolete. Therefore, it is not necessary to check these parameters.
However, these parameters can be checked, if they are transferred accidentally, for example. However, this does not provide any extra security and is therefore superfluous, especially in the case of operations with no security level, as the absence of an authorization check enhances system performance.
The parameter docProt is optional, but is usually transferred if the URL is not signed. If neither the Content Server nor the SAP system uses a signature, this has no effect on the security level, which is set for documents when they are created.
If the parameter docProt is not transferred, the default setting on the server is used. The content server default is set when the system is being implemented, and its value is entirely at the discretion of the system administrator.
If the SAP system does transfer the docProt parameter, the system assumes that the maximum security level applies for all access attempts on the relevant documents, and uses corresponding signed URLs.
The signature can be deactivated in the SAP system only if it is also deactivated on the Content Server.
In live systems, however, you should use signatures.
For all access modes, the Content Server must allow the system administrator to set as default whether a secKey must be specified or not. This server default can, however, be overwritten in the URL for the functions create and mCreate. If no security level is specified, the server default is used.
Old data and documents that were stored in the Content Server without the use of the HTTP interface have the highest security level; that is, all access attempts must be authenticated.