Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
ContentIndex
  
[+] Expand All
[-] Collapse All

No index entries found.

Understanding How ClearPass Initiates a Session and Communicates User Authentication Information to the SRX Series Device Using the Web API

The integrated ClearPass authentication and enforcement feature enables the SRX 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 SRX Series device, which, in turn, uses it to authenticate users requesting access to your protected resources and to the internet. The SRX 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.

Web API

The SRX 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 SRX Series device. The SRX 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.

Warning: 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 master Routing Engine in a chassis cluster environment. After an HA switchover, the daemon will start automatically on the new master Routing Engine. It has no effect on the Packet Forwarding Engine.

ClearPass Authentication Table

After the SRX Series device receives information posted to it from the CPPM, the SRX Series device extracts the user authentication and identity information, analyzes it, and distributes it to the appropriate processes for handling. The SRX Series device creates a ClearPass authentication table on the Packet Forwarding Engine side to hold this user information. When the SRX Series device receives the information sent to it from ClearPass, the SRX Series device generates entries in the ClearPass authentication table for the authenticated users. When the SRX Series 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 SRX Series Device

When you configure the SRX 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 SRX 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:

user@host# set security zones security-zone trust host-inbound-traffic system-services any-service

Ensuring the Integrity of Data Sent from ClearPass to the SRX 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:
    /api/userfw/v1/post-entry
  • The HTTP/HTTPS content that the CPPM posts to the SRX 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 SRX Series device can process a maximum of 209 roles.
    • The SRX 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.

      Note: The CPPM checks the health and posture of a device and it can send that information to the SRX Series device as part of the user information that it posts. You cannot define posture on the SRX Series device. Also, the SRX 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 SRX 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)

Related Documentation

Modified: 2016-05-01