Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Understanding How ClearPass Communicates with the NFX Series Device Using the Web API


The integrated ClearPass authentication and enforcement feature enables the NFX Series device and Aruba ClearPass to collaborate in protecting your company’s resources by enforcing security at the user identity level in environments in which they are deployed together. The ClearPass Policy Manager (CPPM) can authenticate users across wired, wireless, and VPN infrastructures and post that information to the NFX Series device, which, in turn, uses it to authenticate users requesting access to your protected resources and to the internet. The NFX Series device can provide the CPPM with threat and attack logs associated users’ devices so that you can better harden your security at the ClearPass end.


The NFX Series device exposes to the CPPM its Web API daemon (webapi) interface that enables the CPPM to integrate with it and efficiently send authenticated user identity information to the NFX Series device. The NFX Series Web API daemon acts as an HTTP server in that it implements part of the RESTful Web services that supports concurrent HTTP and HTTPS requests. In this relationship, the CPPM is the client. The Web API daemon is restricted to processing only HTTP/HTTPS requests. Any other type of request it receives generates an error message.


If you are deploying the integrated ClearPass Web API function and Web management at the same time, you must ensure that they use different HTTP or HTTPS service ports.

However, for security considerations, we recommend that you use HTTPS instead of HTTP. HTTP is supported primarily for debugging purposes.

The Web API daemon runs on the primary Routing Engine in a chassis cluster environment. After a Chassis Cluster switchover, the daemon will start automatically on the new primary Routing Engine. It has no effect on the Packet Forwarding Engine.

ClearPass Authentication Table

After the NFX Series device receives information posted to it from the CPPM, the device extracts the user authentication and identity information, analyzes it, and distributes it to the appropriate processes for handling. The device creates a ClearPass authentication table on the Packet Forwarding Engine side to hold this user information. When the device receives the information sent to it from ClearPass, it generates entries in the ClearPass authentication table for the authenticated users. When the device receives an access request from a user, it can check its ClearPass authentication table to verify that the user is authenticated, and then apply the security policy that matches the traffic from the user.

Using HTTPS or HTTP for the Connection Protocol Between ClearPass and the NFX Series Device

When you configure the NFX Series Web API, you specify a certificate key if you are using HTTPS as the connection protocol. To ensure security, the HTTPS default certificate key size is 2048 bytes. If you do not specify a certificate size, the default size is assumed. There are three methods that you can use to specify a certificate:

  • Default certificate

  • Certificate generated by PKI

  • Custom certificate and certificate key

    The NFX Series Web API supports only the Privacy-Enhanced Mail (PEM) format for the certificate and certificate key configuration.

If you enable the Web API on the default ports—HTTP (8080) or HTTPS (8443)—you must enable host inbound traffic on the ports. If you enable it on any other TCP port, you must enable host inbound traffic specifying the parameter any-service. For example:

Ensuring the Integrity of Data Sent from ClearPass to the NFX Series Device

The following requirements ensure that the data sent from the CPPM is not compromised:

  • The Web API implementation is restricted to processing only HTTP/HTTPS POST requests. Any other type of request that it receives generates an error message.

  • The Web API daemon analyzes and processes HTTP/HTTPS requests from only the following dedicated URL:

  • The HTTP/HTTPS content that the CPPM posts to the NFX Series device must be consistently formatted correctly. The correct XML format indicates a lack of compromise, and it ensures that user identity information is not lost.

Data Size Restrictions and Other Constraints

The following data size restrictions and limitations apply to the CPPM:

  • The CPPM must control the size of the data that it posts. Otherwise the Web API daemon is unable to process it. Presently the Web API can process a maximum of 2 megabytes of data.

  • The following limitations apply to XML data for role and device posture information. The Web API daemon discards XML data sent to it that exceeds these amounts (that is, the overflow data):

    • The NFX Series device can process a maximum of 209 roles.

    • The NFX Series device supports only one type of posture with six possible posture tokens, or values. Identity information for an individual user can have only one posture token.


      The CPPM checks the health and posture of a device and it can send that information to the NFX Series device as part of the user information that it posts. You cannot define posture on the NFX Series device. Also, the NFX Series device does not check posture information that it receives.

Posture States and the Posture Group

User, role, and posture token fields are distinct in the context of the CPPM. Each set of user identity information contains user and role (group) identity and a posture token. Because the NFX Series device supports only user and role (group) fields, the posture token value is mapped to a role by adding the prefix posture–. You can then use that role in a security policy as a group and that policy will be applied to all traffic that matches the policy.

The predefined posture identity states are:

  • posture-healthy (HEALTHY)

  • posture-checkup (CHECKUP)

  • posture-transition (TRANSITION)

  • posture-quarantine (QUARANTINE)

  • posture-infected (INFECTED)

  • posture-unknown (UNKNOWN)