Secure URLs 
Secure URLs
To prevent unauthorized access to stored content on the SAP Content Server, the SAP system carries out an authorization check. However, access to the SAP Content Server is gained via the open SAP Content Server interface. Therefore, URLs must be secure so that they allow only authorized access to stored content and, correspondingly, so that forged requests are rejected. To make a URL secure, it is given a characteristic (like a watermark on a banknote) which allows the receiver to detect whether or not the URL has been tampered with (like if the watermark is missing from a banknote).
In the case of a Content Server URL, the characteristic in question is the signature. The signature is an encoded copy of the URL itself and is transferred to the content server as part of the URL. Most notably, the signed URL contains the additional parameters expiration time and digital signature. A signed URL is only valid if the expiration time has not been exceeded and if it contains a valid signature.
The content server decodes the signature and compares it with the URL it received. The content server only executes the request if the URL and the signature match. If an intruder changes the plaintext in the URL, the signature will not match the URL. The content server will accordingly reject the request.
The signature is based on the RSA procedure and MD5 hashing.
The RSA procedure is also known as the
public key procedure. This procedure is based on a private key and a public key. You need the private key to create the signature, while you need the public key to check the validity of the signature. For a description of the technical details of this procedure, see the documentation Secure Store & Forward / Digital Signatures (BC-SEC-SSF).
As the main partner in the three-way relationship of client –> SAP system –> content server, the SAP system is the only partner that may send request URLs to the client. Because of this, the SAP system has to create the URL signature using a private key.
The public key (
Certificate) of the SAP system must be stored on the content server, and the relevant repository must have access to it (see also Content Repositories). Transactions OAHT, OAC0 (from release 4.6C) and CSADMIN (from release 4.6C for SAP Content Server, see also Content Server and Cache Server Administration) are used to transfer the certificate. The certificate has to be activated on the content server for the repository in question. This is done using transaction CSADMIN (for SAP Content Server).
Relationship Between Certificate, Certificate List, and PSE
Certificate
A certificate is an ASCII-encoded exchange format for public keys, in accordance with ISO standard X.509.
Besides the public key, a certificate also contains other information such as the issuer and the validity period.
The terms "certificate" and "private key" are often used synonymously in everyday use. In particular, the term "certificate generation" is used incorrectly in the SAP system, because in reality a pair, consisting of a private key and a public key, is generated.
Certificate List
A Content Server and the repositories it contains can be used by multiple SAP systems. Therefore, the Content Server has to be able to store certificates of varying origins for every repository. To facilitate this, the Content Server creates a certificate list for every repository.
Public Key Security Environment (PSE)
A PSE is a binary representation of a certificate list. Before a public key can be used by the Content Server security module, it has to be converted from the ASCII format of the certificate to a binary format. This conversion is known as "certificate activation" (see also transaction CSADMIN). The signatures of activated certificates only are checked.
If a public key belonging to the same issuer was available before the certificate was activated, the old public key is overwritten.
When the certificate is deactivated, the public key is deleted from the PSE, but the certificate is not deleted from the certificate list.
Switching On and Off Signature Checking
Signature checking has to be switched on and off for every repository. To do this, use the parameter "Security" in the
ContentServer.ini file.
Once signature checking has been switched on, active certificates have to be available for every SAP System that sends URLs!
The Customizing transaction OAC0 is used to activate URL signatures. If signature checking is not switched on on the Content Server, any signatures sent with the URL may be ignored.
Every SAP system must have its own unique certificate, so that the SAP system’s digital signature can be used properly.
In particular, when copying an SAP system, you have to make sure that the copy also has its own certificate.
Signed URLs can slow down performance, as it takes increased processing power to create the signature.
See the section
Creating a System-Specific Certificate for Content Server Access.