Backend API Authentication
Backend APIs (especially when not running within the organization) may request authorization for access.In this case, the required authorization must be made for the API Proxy defined on Apinizer to access the Backend API. One method for this is the Backend API Authentication policy. With this policy, the credentials requested by the Backend API are placed in accordance with the message content.
The information requested in the policy content varies according to the selection in the "Authorization Method".
Therefore, when this policy is added, the Authorization Method should be selected first, as seen in the image below.
There are 4 Authentication Methods to choose from here:
- Basic Method: In this method, the username and password are placed in the message without encryption.
- Base64 Method: In this method, the username and password are distinguished by ":", encoded with Base64, and the resulting value is placed in the message.
- Digest Method: Although this method is mostly used in SOAP Services that require SOAP Security, it can rarely be used in REST APIs. Username, password, timestamp (created) and unique value (nonce) are created according to the Digest creation algorithm and placed in the message.
- API Call Method: With this method, API Key is obtained from an identity provider and this value is placed in the message.
The required configuration fields are the same in Simple, Base64 and Digest methods.
In these 3 methods, the username and password must be entered, "Credential Sending Method" must be selected.
Sometimes it may be desired to access the Backend API with different users.
In this case, together with more than one username and password, a condition expressing the relevant situation is entered in which case this pair is desired to work.
If there is more than one user name and password pair at runtime, their conditions are executed and the user name and password information that meets the condition is used.
If there is more than one username and password that meets the condition, the first one to match is preferred.
To add a username and password, click the "New" button indicated in the image below.
In the image that appears on the screen, the username and password with or without the rule is entered, the save button is pressed, and the operations are continued for other settings.
The required configuration fields in Simple, Base64 and Digest Authorization Methods vary depending on the "Send Authentication Info in" selection.
There are 4 values that the Send Authentication Info in field can take:
- Header
- Parameter
- Message Body
- Message Body Injection
The Authentication Method determines the behavior of the Username and Password pair to be sent in these 4 methods, and the fields to be sent are determined according to this type.
The fields used for the configuration of the policy are shown in the table below.
| Authentication Method | Description | How the Credential is Submitted | Desired Values |
|---|---|---|---|
| Basic | Username and password are sent in clear text. | Header | The Key Names to which the username and password will be sent are entered. At runtime, the username and password that meet the condition are added to the message header as the value of these fields. |
| Parameter | The Key Names to which the username and password will be sent are entered. At runtime, the username and password that meet the condition are added to the message parameters, separated by "&" in the form of "field name=field value" pairs. | ||
Message Body | A "template message" to be added to the message body and a "path" to specify where to insert this template message into the body are requested. The fields specified with ## expressions in the template message are sent to the Backend API by changing the user name and password. For username: #USERNAME# for password: #PASSWORD#. The path value is XPath if the message type is XML, and JSONPath if it's JSON. At runtime, the username and password that meet the condition are changed in the template and the resulting text is added to the specified path in the message body. | ||
Message Body Injection | Username and password "element name" to be added to the message body and paths specifying where this element will be added to the body are requested. Path values are XPath if message type is XML, and JSONPath if JSON. At runtime, the matching username and password are added to the message body along with the new element names according to the specified paths. | ||
Base64 | Username and password are concatenated with ":", the resulting value is encoded with Base64 and sent. E.g; Username "admin", password "Ws6txj98!" if so, the resulting value is "YWRtaW46V3M2dHhqOTgh". If it is sent in the "Title" field, this value is preceded by the phrase "Basic" and is used as in the other options. | Header | The key name to which the encoded data will be sent is entered. The value created with the username and password matching the condition at runtime is added to the message header. |
| Parameter | The key name to which the encoded data will be sent is entered. At runtime, the value created with the user name and password that meets the condition is added to the message parameter as "field name=created value". | ||
| Message Body | A "template message" to be added to the message body and a "path" to specify where to insert this template message into the body are requested. The field specified with the ## expression in the template message is replaced with the encoded value and sent to the Backend API. #PASSWORD# is used for this key name. The path value is XPath if the message type is XML, and JSONPath if it's JSON. At runtime, the value created with the username and password that meet the condition is changed in the template and the resulting text is added to the specified path in the message body. | ||
| Message Body Injection | The "element name" is requested for the encoded value to be added to the message body, and the "path" specifying where this element will be inserted in the body. The path value is XPath if the message type is XML, and JSONPath if it's JSON. At runtime, the value created with the user name and password matching the condition is added to the message body with the new element name according to the specified path. | ||
| Digest | Kullanıcı adı açık metin olarak, parolası ise şifrelenmiş olarak gönderilir. Bu yöntemde "created" ve "nonce" ifadeleri de oluşur. Parolanın şifrelenme formülü şu şekildedir:Base64 ( SHA1 ( nonce + created + password ) ) | Header | The field names to which username, password, created and nonce values will be sent are entered. At runtime, the user name, password, and created and nonce values that meet the condition are added to the message header as the value of these fields. |
| Parameter | The field names to which username, password, created and nonce values will be sent are entered. At runtime, the user name, password and created and nonce values that meet the condition are added to the message parameters as the value of these fields, separated by "&" in the form of "field name=field value" pairs. | ||
Message Body | A "template message" to be added to the message body and a "path" to specify where to insert this template message into the body are requested. The fields specified with ## expressions in the template message are sent to the Backend API by changing the username, password, created and nonce values. For username: #USERNAME# for password: #PASSWORD#, for created: #CREATED#, for nonce: #NONCE#. Path values are XPath if message type is XML, and JSONPath if it is JSON. At runtime, the username, password and created and nonce values that meet the condition are changed in the template and the resulting text is added to the specified path in the message body. | ||
Message Body Injection | At runtime, the user name, password and created and nonce values that meet the condition are changed in the template and the resulting text is added to the specified path in the message body. Path values are XPath if message type is XML, and JSONPath if it is JSON. At runtime, the username and password that meet the condition and the created and nonce values are added to the message body with the new element name according to the specified path. | ||
| API | - | - | - |
In the API Call Method, an "API Identity Provider" defined unlike the other 3 methods is selected and the rules in the selected "API Identity Provider" are executed. It is expected that the selected API identity provider will receive a Key/Token over the API specified in its settings and place it in the message. Depending on the situation, it can place not only an API Key/Token, but also different information of the user (such as the roles it has) in the message that will go to the Backend API.
You can visit the Policies page for the details of the Conditions and Error Message Customization panels.