REST APIs for Access Control Policies
Cisco Secure Firewall Management Center APIs can be used to create and manage access policies, access rules, and other access policy objects. This document provides the procedure to manage a basic access control policy. Information about access rules and other policy objects are outside the scope of this document.
The Policy APIs allow you to:
-
Create an access control policy for the managed firewall devices to protect your network from unauthorized access, malware infections, data breaches, and other security threats.
-
(Optional) Lock a policy to ensure that your rules are not overwritten by another user.
-
(Optional) Create a custom policy using the inheritance functionality.
-
(Optional) Delete an access control policy that is obsolete and is no longer needed.
-
Deploy the new or modified policy configurations on the devices whenever you modify the policies.
Endpoints and Methods Used
Important Terms in Management Center REST APIs
-
DomainUUID—The Global domain UUID. This ID is always going to be the same in all the management centers, irrespective of their version. If you create a new domain in your management center and a specific user for the newly created domain, a new domain UUID is displayed on the API console of the management center.
-
ContainerUUID—The parent object's UUID that connects the object to the overall schema. For example, to get the physical interfaces, use the device ID as the container UUID in the following URL:
GET /api/fmc_config/v1/domain/{domain_UUID}/devices/devicerecords/{container_UUID}/fpphysicalinterfaces
-
ObjectID—The ID of the target object. For example, to get details about a physical interface, use the interface id as the Object ID in the following URL:
GET /api/fmc_config/v1/domain/{domain_UUID}/devices/devicerecords/ {container_UUID}/fpphysicalinterfaces/{objectId}
Create a Basic Access Control Policy
-
Traffic matching criteria—Security Zone, IP Address or Geo Location, Port Number, Protocol, Application Type, URL Pattern, URL Category, URL Reputation, and Users.
-
Action on matching traffic—Allow, Block, Trust, Monitor.
-
An intrusion prevention policy, a file policy, or both for the Allow action categories.
Note |
You can assign only one policy to a threat defense device. However, you can assign the same policy to several devices. |
Before you begin
Procedure
Create an access control policy using the following URL:
Example:
A policy is created with the specified name and a unique ID. |
What to do next
-
Assign policy to target devices. See Set Target Devices for an Access Control Policy.
-
Deploy configuration changes. See Deploy a Configuration.
Edit an Access Control Policy
Before you begin
Ensure that you have created an access policy that you want to modify or edit. For information about how to create a policy, see Create a Basic Access Control Policy.
Procedure
Step 1 |
To edit an access policy, you require the ID of the policy. To get the ID, use the following URL: GET /api/fmc_config/v1/domain/{domainUUID} /policy/accesspolicies Example:
|
||
Step 2 |
Edit the access control policy using the following URL:
In this example, to edit the Policy 1 parameters, use the policy ID (00505691-AED0-0ed3-0000-004294990861) as the Object ID in the Request body.
|
What to do next
-
Deploy configuration changes. See Deploy a Configuration.
Lock an Access Control Policy
By default, access policies are not locked. You can lock them if you do not want any other user to modify the rules or settings.
Before you begin
Ensure that you have created an access policy that you want to lock. For information about how to create a policy, see Create a Basic Access Control Policy.
Procedure
Step 1 |
To lock an access policy, you need the ID of the policy. To get the ID, use the following URL:
|
Step 2 |
To lock an access policy, use the following URL:
Specify the policy ID in the Request body. Example:
To unlock the policy, use the POST method and specify "lock": "false" in the Request body. The policy is locked and other users cannot modify the policy. |
Manage Access Control Policy Inheritance
The inheritance feature allows you to apply some baseline characteristics from one policy to multiple policies. You can use a policy as a base policy for another access control policy.
Procedure
Step 1 |
To view an existing inheritance setting for a policy, use the following URL: GET api/fmc_config/v1/domain/{domainUUID}/policy/accesspolicies/ {containerUUID}/inheritancesettings/{objectId} Use the policy ID for the containerUUID and object ID fields in the Request URL Example:
Notice that the basePolicy—CorePolicy is inherited by the Policy1 access policy. |
Step 2 |
To modify the inheritance, use the following URL. Use the policy ID, whose base policy you want to change, for the containerUUID and object ID in the Request URL.
Specify the policy ID that you want to use as the new base policy in the Request body. Example:
The new base policy is applied to Policy1.
|
Step 3 |
To test the new inheritance settings for Policy 1, use the following URL:
Use the policy ID for the object ID field in the Request URL. Example:
|
What to do next
-
Re-assign policy to target devices. See Set Target Devices for an Access Control Policy.
-
Deploy configuration changes. See Deploy a Configuration.
Set Target Devices for an Access Control Policy
You can assign only one policy to a device. However, you can assign the same policy to several devices.
Before you begin
-
Ensure that you have created the access policy to be assigned to devices. For information about how to create a policy, see Create a Basic Access Control Policy.
-
Ensure that you have configured the target devices and enabled them.
Procedure
Step 1 |
To assign a policy to devices, you require the devices IDs and policy ID. Get the IDs of the devices to which the policy must be assigned using the following URL:
Example:
Use the following URL to get the specific policy ID. The URL returns all policy IDs from which you can identify the ID of the specific policy.
Example:
|
||
Step 2 |
Create policy assignment using the following URL:
Example:
|
What to do next
-
Deploy configuration changes. See Deploy a Configuration.
Delete an Access Control Policy
Before you begin
Ensure that the access policy that you want to delete is unassigned from the target devices. If you proceed to delete the policy, the following error will appear in the Response body:
ERROR 400: "Policy In Use Policy Policy 1 or its children is assigned to a device in current domain or sub-domain. Please remove the
assignments before attempting to delete."
To sucessfully delete the policy that is assigned to devices, you must reassign the devices with an alternative access policy. For information about how to set the target devices for a policy, see Set Target Devices for an Access Control Policy.
Procedure
Step 1 |
To delete an access policy, you require the ID of the policy. To get the ID, use the following URL:
Example:
|
Step 2 |
Verify if the access policy is assigned to any device using the following URL:
Specify the policy ID in the Request URL. Example:
Here, you can see that a device is assigned to the policy that you want to delete. If no devices are mapped to the policy, go to Step 4. |
Step 3 |
Reassign another policy, for example, Policy 1 to the target device using the following URL:
Use the ID of the alternative policy as the Object ID in the Request URL. Example:
|
Step 4 |
Delete the policy using the following URL:
Use the ID of the policy that you want to delete as the Object ID in the Request URL. Example:
|
Deploy a Configuration
To deploy a new or modified configuration, you require the device ID and version.
Procedure
Step 1 |
Procure the deployable device version using the following URL:
Example:
|
Step 2 |
Deploy the configuration changes:
Use the version ID and device ID to deploy the configuration in the Request body. Example:
|