> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apinizer.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Application of Plain-Text Authentication Policy to REST API via Database Provider
> Explains how to apply Plain-Text Authentication policy to Swagger Petstore REST API via database provider. Includes all steps from establishing database connection to authentication settings, adding policy to testing.
The numbering in the diagram below corresponds to the **order of operations**.
* **Security Manager** in **Apinizer** expects **Plain-Text type** security information from **API Client**.
* **Authentication** information is sent to the database to be checked.
* **From the database**, a response regarding authentication information is returned to Apinizer. If this authentication cannot be verified, Apinizer stops the request and returns an error message. If verification can be performed, the flow continues.
* **Apinizer makes a request to Backend API**.
* **Backend API responds to Apinizer**.
* **Apinizer transmits the response to API Client**.
## Creating API Proxy
Access to the REST API named Swagger Petstore can be provided from [https://petstore.swagger.io/](https://petstore.swagger.io/).
Click the **API Proxies** option under the **Development** menu.
Since no **proxy** definition has been made before on the opened page, the text **No records found!** may appear.
Click the **Create** button in the top right corner and start creating a new **proxy**.
In this section, it is necessary to select what type the **API Proxy** to be created is.
Since the type of API to be used in this scenario will be **Swagger 2.X**, this type is selected.
Click on the **Enter URL** expression to switch to the screen where the address of the API to be used will be entered.
Enter the **address to be accessed** in the URL section and click the **Parse** button.
After the Parse operation is performed, settings for the API Proxy can be made.
* The **Usage** field specifies who will use the created API Proxy. Options such as **publisher, consumer, publisher and consumer** are available here.
* The **Sharing Type** field specifies the sharing type of the created API Proxy. Options such as **external, internal, external and internal** are available here.
* One or both of the two API addresses under the **Addresses** tab can be selected. If both addresses are selected, Apinizer will perform the **Load Balance** operation itself.
* **Relative Path** is the address where the created API Proxy will be opened for access.
* The **Category List** field also allows categorization of the created API Proxy.
After these settings are made, the API Proxy is saved.
After the save operation, click the **Develop** tab on the opened page.
Policies to be added with the **All** expression above these endpoints can be applied to **all endpoints**.
The created API proxy is deployed. For this, click the **Deploy** button in the middle section above.
## Establishing Database Connection
Click the **Database** menu under the **Connection Management** menu.
If no database definition has been made before, the text **No records found!** may be seen on this page.
Click the **Create** button in the top right corner to create the database connection.
The fields on this screen:
* The **Name** field expresses the name of the connection to be created.
* A description can be added to the created connection with the **Description** expression.
* Write the JDBC address required to connect to the database to be connected to with the **JDBC URL** field. This information can be obtained from the database team.
* Enter the username information to be used during connection with the **Username** field, and enter the password to be used during connection with the **Password** field.
This section is arranged by obtaining information from the database administrator or team about what the most appropriate values will be for the connection information on the right.
Click the **Test Connection** button to perform the test, and click the **Save and Deploy** button to save the operations.
After the registration operation is completed, the created connection is displayed as in the image below.
## Adding Database Authentication Connections
Go to **Identity Management > Identity Providers > Database** section to add the database authentication definition created earlier.
### Database Authentication Connection
Press the **Create** button and enter connection settings:
* Enter name and description for the connection.
* If the **password** information in the table to be used in the database connection is kept encrypted, the encryption type of the password stored in the table must be selected with **Encryption Type**.
* Select the database prepared in previous steps with the **Database Connection Pool Definition** field.
* A query is used to retrieve username/password pairs or role lists from the database. The username parameter in the query must be defined as `:username` and the password parameter as `:password`. Apinizer recognizes the colon character and processes accordingly, knowing that the relevant parameter will be sent from outside.
The **Test Username** and **Test Password** fields can be filled with information in the **database** to test whether the query works. **It is recommended to clear these fields before saving the definition.**
### Database Authorization Connection
The only difference from the authentication connection is the query entered. Since identity authorization will be performed in this field, only the name of the relevant role is retrieved in the query section.
## Creating Authentication Policy
Go to the page where API proxies are listed and select the proxy named **Swagger Petstore** from here.
Go to the **Develop** tab and click the **Add Policy** button.
On the opened page, the **Plain-Text Authentication** policy is selected.
The fields on this screen:
* Select the **database** from the **Identity/Role/Group Service** field that will provide the control.
* The **Variable for username** and **variable for password** expressions also select which variable the username and password information will be retrieved with. In this scenario, these values will be expected and retrieved from the **username** and **password** values in the **header**.
If the **Clear Authentication Information** option is selected, authentication information in the incoming message is deleted when going to the backend api. **Activating this setting is always recommended unless there is a special situation.**
* The **Add Client Info To Header** option enables the username to be transmitted in a separate header value in the Header going to the backend API.
* The **Authorization Configuration** field is the field where rules related to the roles of users whose authentication has been performed can be entered.
* If the **Add Roles To Header** option is selected, if authorization is successful, it adds the client's roles to the "X-Authenticated-UserRoles" header.
* Select the **database** from the **Identity/Role/Group Service** field where role information is located. This is usually done with the same definition as the database that provides identity control.
* Enter the roles to be authorized in the **Roles/Group** field.
* Set whether the client needs to have **all** or **any** of the roles/groups defined here to access the API.
* When the **Enable Role/Group Based Method Access** option is selected, first the roles granted access to the API are checked. Then, other roles are looked at to control access to methods.
The relevant icon is seen when the policy is registered.
For the operation to be valid, the proxy must be **Redeployed**. After the Redeploy operation, the API proxy can be tested.
## Testing the API Proxy
After selecting an endpoint such as **"/pet/{petId}"**, click the **Test Endpoint** button.
Enter the desired pet id value in the URL or parameter tab, and when the **Send** button is pressed, the returned response will be an error message.
It will be seen that this error is related to the applied **Plain-Text Authentication**. Because no **authentication** information has been placed in the **headers** in any way.
Enter the information of a user in the database in the **username** and **password** headers in the **headers** to be sent to the **Backend API**, repeat the test, and expect to receive a successful response.
