Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Create a new article
3648
Views
15
Helpful
0
Comments

ISE pxGrid & API Vendor Integration notes

Jason Kunst
Cisco Employee
Cisco Employee

on ‎09-01-2021 10:11 AM - edited on ‎02-12-2023 12:47 PM by Cisco Employee

This document goes over all the requirements and needs for integrating with Cisco ISE pxGrid.  Anyone integrating with Cisco ISE is required to reach out to us to get onboarded, find out more from the CSTA program.

Table of Contents

 

 

What's NEW?

pxGrid Cloud information

Resources

 

Partner Setup Requirements

Licensing Requirements

 

Deployment Setup (HA environment strongly recommended)

  • 4 nodes are required to properly code
    • Primary & Secondary Admin/Monitoring (MNT) 600GB storage 16GB RAM and 4 CPU (2 HT)
    • 2 PSN pxGrid nodes - 12GB RAM, 300 GB storage
  • ISE 3.2 with latest patch (download the 600GB and 300GB version of OVA and deploy with 16GB/12GB RAM in that order)
  • ISE 3.2 Setup Guide (run through the setup on all 4 nodes before our call) 

 

Client Requirements

  • May use username/password but must provide option to use use certificates 
  • Looking for streamlined approach for importing certificates via GUI (no CLI, decryption outside of product, simple to use). Create PEM certificate package on ISE and then import zip on your console. Don't use PKCS12 unless a technical constraint
  • Setup for at least 2 node, 3 recommended
  • System should have an automatic connection mechanism to reconnect when the connection is lost
  • How do you handle certificate expiration? They would need to upload a new cert and new client connection for pxGrid

 

How to Handle Loss Detection

An ISE deployment can provide multiple nodes that you, as a client, can subscribe to voluntarily. When subscribing to the sessionTopic, if you only subscribe to one node, then it is possible to miss events. And, if you lose connectivity, then after you restart an event subscription you really need to use a query against the session directory to ensure you didn’t miss any events. That query may be optimised using the time of the last event you received successfully, but it still represents a certain level of complexity. In ISE 3.0 there is session data that can be re-used to recover. 
Its HIGHLY RECOMMENDED that you subscribe to multiple nodes and de-duplicate data to protect against loss of information. This would replicate events to your client, and you would need to de-duplicate in your client. That gives some extra complexity, with the benefit being that on the failure of a pxGrid node you will still get events while also being able to attach to another node (if one is available) and not need to query the session directory.

Both methods complement each other.  In ISE 3.x you can use both mechanisms for a robust system. The point in registering with two nodes is to make it less likely that you need to do bulk downloads because of pxGrid node failures. However, if the producer of information fails or the network between a pxGrid node and a client fails, this is detected using the connection loss detection mechanism.

 

Client Sessions - Simulator vs Real Switch

In the pxGrid DevNet information there is a RADIUS simulator, it will help get information into ISE.  This doesn't substitute for a real client connect to a network device such as a compatible Cisco switch, VPN concentrator (ASA) or wireless controller (WLC).

 

Collateral Requirements

  • Within the UI ensure correct mention of Cisco Platform Exchange Grid or Cisco pxGrid and Cisco ISE where appropriate. Also note correct capitalization of pxGrid
  • Provide slides on how your solution works and how pxGrid helps with this solution
  • Provide slides on detailed integration between your solution and pxGrid including a common use-case
  • Include detailed logging and troubleshooting logs and procedures for integration issues between your security solution and pxGrid
  • Step-through the ISE pxGrid node configuration including certification generation and importing certificates using ISE internal CA   (Note: must also support using and external CA server)

    Generating Certificates Using ISE Internal CA

    Generating Certificates Using External CA

  • Create an end customer facing integration How-to Guide documenting the steps required on integrating your product with pxGrid:
    • include certificate operation and common use case
    • Include the version of ISE and your product that was tested (use the current ISE Recommended Release)
    • State that you’re integrated with pxGrid 2.0
    • Indicate what pxGrid topics and APIs etc you are using
  • Post all collateral to your Cisco Market Place portal (Example: IBM Security QRadar SIEM)
  • Create a VOD illustrating a customer use case with your solution and pxGrid (Example: Qradar VOD)

What certificates should be installed on my client?

Client server communication requires that  ISE trusts the services client (your service). This is easily solved by generating a cert from pxGRid services on ISE using its internal CA. This certificate needs to have the following: CN as the FQDN (your-svc-client.domain.com), SAN needs same FQDN and also the client IP address. This zip package would be uploaded to your services client and the RootCA, client cert, and client key would be used. The RootCA allows communication from ISE to be trusted without the need to install each pxGRid node  client cert in the clients trusted store.

If customer has an external PKI then the client and server (ISE) must have the PKI cert chain trusted instead. That PKI would generate a cert for ISE nodes and for the client server. See more information in the above links about generating certs

cert.png

General steps for pxGrid access REST API

Using this guide Testing and Configuration Guide for Cisco Platform Exchange Grid (pxGrid) 2.0

 

  1. Register a client for password based authentication.
  2. Activate the client (Steps 1 and 2 were completed in the last call)
  3. Perform service lookup for ANC service (body of REST call should be - {  "name":"com.cisco.ise.config.anc" })
  4. The response to Service Lookup will contain a nodeName and a restBaseUrl.
  5. Obtain a AccessSecret to access the nodeName. This is done by using “/pxgrid/control/AccessSecret”. The body should contain the nodeName received in Step 4. ({“peerNodeName”: <nodeName received in Step 4>})
  6. Now append the API end point (eg – getPolicies) to restBaseUrl obtained in Step 4. For authentication, use the username created in Step 1 and secret received in Step 5.

 

 

 

API Gateway and pxGrid discovery options 

image003.png

The API gateway is intended to provide options so that integrations don’t have to be so aware of the topology of ISE and of special port numbers when it comes to interacting with ISE via API. Underneath the covers the API gateway is ALWAYS used in front of port 443, but when it is "enabled" it also routes requests that should go to the PAN to the PAN, so a integration can use, for example, ERS or MNT/Admin APIs against any node with the API gateway "enabled".

 

Next, a customer may wish to consider having a VIP through a load balancer that maps to any of the API gateway-enabled nodes, or have a virtual hostname that maps in DNS to any one of the API gateway-enabled nodes. This will allow the customer to perhaps have more flexible deployments, especially when nodes are being replaced/upgraded or have failed. If a customer goes this way the hosts with the API gateway enabled should all be "close" to each other in latency terms as there will be internal routing of requests. For example, write requests through the ERS will always terminate on the current PAN.

 

ERS APIs must be invoked against primary admin node prior to 3.0

MNT APIs against primary MNT

 

Therefore the short pre-3.0 answer is:

  • Any node for ERS read requests but beware of replication delays under load if you're doing write/read against different nodes.
  • Write requests must go to the node currently the P-PAN. All other nodes will reject writes with a 401 error.

 

Without API Gateway

  • P-PAN, S-PAN and PSNs will all respond to ERS GET requests when using port 9060.
  • Only the P-PAN can be used for create/update requests. If you try on the S-PAN you will get a 401 error; for example:

HTTP/1.1 401 

Unauthorized: The requested operation is allowed on PAP Node only.: 401

Content-Length: 0

Date: Fri, 04 Feb 2022 14:47:43 GMT

Connection: close

Server:   

 

  • Read requests against the S-PAN or any PSN will have a minor latency to give the same answer as the P-PAN if the P-PAN is under heavy load in terms of updates. This is because config replication from primary to standby takes a finite time.

 

With API Gateway

 

First, all port 9060 behavior above stays the same. In addition:

  • Port 443 on ANY node with Api gateway enabled will be able to do reads and writes through ERS.
  • If the API Gateway isn't enabled on, for example, a PSN, any ERS call via port 443 will return a 302 error; for example:

HTTP/1.1 302 

Content-Length: 0

Connection: close

Strict-Transport-Security: max-age=31536000; includeSubDomains

Location: https://tl-enn-ise-7.cisco.com:443/admin/

Date: Fri, 04 Feb 2022 14:59:10 GMT

Server: 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents