Access Control List (ACL) Scenarios

YAML

Why it fails: The Cisco ASA REST API accepts and returns JSON payloads for access control entries; YAML is not parsed by the ASA REST interface. YAML is tempting because it is human-readable and widely used in configuration management tools such as Ansible, but those tools translate to JSON before transmission.

XML

Why it fails: The Cisco ASA REST API expects JSON in request bodies; XML is not an accepted content type for access control entry creation. XML is tempting because many legacy network management protocols and SOAP-based APIs use it, but the ASA REST interface does not.

CSV

Why it fails: CSV is a flat tabular format with no native nesting, so it cannot represent the hierarchical JSON structure the ASA REST API expects for an access control entry. CSV suits bulk import utilities and spreadsheet exports, not REST request bodies.

/api/fmc_config/v1/policy/access

Why it fails: The FMC configuration API requires the domain UUID segment, so the correct path is /api/fmc_config/v1/domain/{domainUUID}/policy/accesspolicies; omitting it returns an error. It is tempting because it mirrors the visible resource hierarchy, but the mandatory domain scoping segment is missing.

/api/v1/fmc/acp

Why it fails: The FMC REST API is versioned under /api/fmc_config/v1/, not /api/v1/, and access control policies are addressed as domain-scoped objects rather than an fmc/acp path. It tempts because a short, readable v1-style route resembles other Cisco controller APIs, yet FMC exposes no such endpoint.

/api/fmc_config/v1/domain/policy/accesspolicies

Why it fails: Access control policies are retrieved through the policy/accesspolicies collection, but the domain segment must carry the actual domain UUID; the literal placeholder 'domain' is not a resolvable path element. It tempts because the surrounding structure matches the genuine FMC REST hierarchy, so only the substituted domain identifier is wrong.

PATCH

Why it fails: PATCH performs a partial modification of an existing resource, altering only supplied fields rather than retrieving data. It is tempting because PATCH targets a specific resource URI, mirroring the addressing a read would use, but its semantics are write-only. A read-only request requires GET, which returns the resource representation without side effects.

POST

Why it fails: POST submits data to create a subordinate resource or trigger an operation, so it changes state rather than returning a representation. It is tempting because POST can target a collection URI and its response may echo data, but no retrieval semantics apply. A read-only request requires GET, which is safe and idempotent.

PUT

Why it fails: PUT replaces an entire resource with the supplied representation, making it a write operation, not a read. It is tempting because PUT addresses a specific resource URI exactly as a retrieval would, but it overwrites rather than returns content. A read-only request requires GET, which performs no modification.

The deployment request must include a valid 'version' parameter that matches the policy's current version.

Why it fails: While versioning is important for concurrency, the error message specifically mentions device association, not version mismatch. The FMC API does use versioning to prevent conflicts, but a missing or incorrect version would typically return a different error, such as 409 Conflict or a version-related message.

The API user account lacks the 'Deploy' permission for the FMC domain.

Why it fails: Insufficient permissions would typically result in a 403 Forbidden error, not a 400 Bad Request with a specific message about device association. The error indicates a logical configuration issue, not an authorization problem. The user likely has deploy rights but missed the device assignment step.

The access control policy must be in 'Intrusion Prevention' mode before deployment.

Why it fails: The policy mode (e.g., Intrusion Prevention, Access Control) affects inspection behavior but does not prevent deployment if no devices are assigned. The error is about device association, not policy mode. Changing the mode would not resolve the 'not associated with any device' issue.

POST to /api/fmc_config/v1/domain/{domainUUID}/policy/accesspolicies

Why it fails: POST to the collection endpoint is used to create a new access control policy, not to modify an existing one. Submitting the updated policy here would either create a duplicate policy or fail because the policy name already exists. To modify an existing policy, the objectId must be included in the URL and the PUT method used.

PUT to /api/fmc_config/v1/domain/{domainUUID}/policy/accesspolicies

Why it fails: This endpoint without the objectId targets the collection of access control policies, not a specific policy. A PUT request to a collection endpoint is not supported by the FMC API for updates. The objectId must be appended to the URL to identify the policy to be modified, otherwise the request will not update the intended policy.

PATCH to /api/fmc_config/v1/domain/{domainUUID}/policy/accesspolicies/{objectId}

Why it fails: The FMC REST API does not support the PATCH method for access control policies. Although PATCH is used in some REST APIs for partial updates, FMC requires a full object representation via PUT. Using PATCH would result in an HTTP 405 Method Not Allowed error, so the script would fail to update the policy.

r.ok

Why it fails: The r.ok attribute is a boolean that is True when the status code is below 400, so it tells you success or failure but not the specific code. A 401 versus a 500 both yield False, which is insufficient when the script must distinguish authentication problems from server errors.

r.reason

Why it fails: The reason phrase is the human-readable text such as 'OK' or 'Unauthorized' that accompanies the status line. It is a string, not a number, so comparing it to 200 fails. It is useful for logging, but it cannot reliably drive programmatic branching when interacting with the FMC API.

r.headers['Status']

Why it fails: HTTP status is carried on the status line, not in a response header named Status. While some frameworks add custom headers, the FMC API does not return a 'Status' header you can rely on for the code, so this attribute lookup would raise a KeyError rather than give you the numeric result you need to branch on.