Please Register for the May 5th Share IT Solutions Huddle
where I will be presenting
“Vanilla ISE: A simplified Cisco ISE UI for endpoint technicians.”
Welcome to part 4 of the journey to Vanilla ISE, a simplified ISE GUI for endpoint technicians. In part 1, we covered the background and requirements for the UI. In part 2, we explored the relevant documentation to find the relevant API calls we will use. And in part 3, interacting with network devices and CLI parsing using pyATS.
Please find all three previous blogs in this series here.
The new “voucher” capability
So far, we’ve been working with existing ISE APIs, using them instead of the GUI. Yet, it’s an existing capability – only a different method of consumption. The “voucher” capability, on the other hand, is a new capability that did not exist and required figuring out the logic. Cisco ISE had no concept of time-limited endpoint group assignment. Cisco ISE “understands” endpoints, endpoint groups, policy based on these groups, and time based-rules too. However, we need a different expiration time for each “vouchered” endpoint.
I needed an alternate database to store the expiration time for each endpoint. This database must be stored outside of the running code as an external resource, so that in case of an exception, and code re-run, we don’t want to lose it.
For the scale I was looking at for a proof-of-concept, I chose to use a simple JSON file as my “database.”
Here’s an example of the database. It consists of the base minimum details that owe to “live” outside of Cisco ISE – pairs of MAC Addresses and their expiration time.
You are probably familiar with the format of a MAC address. If the time/date format of 1617470851 looks strange, that’s because it’s in epoch time / Unix time – the number of seconds that passes since the first Unix machine started on January 1st 1970. It’s easier for computers to handle this format, as opposed to days/weeks/months/years.
There are four functions we want to perform on the voucher file:
1. Read the content of the file (if it does not exist – create a new one):
2. Add a new voucher (and update ISE about it):
3. Remove a voucher (and update ISE about it):
4. Run a periodically clean-up, to remove expired vouchers:
While most of the functions are user-triggered (adding/removing a voucher), the clean-up function needs to run every few minutes without user intervention. That is achieved by a separate thread on the front-end (which we’ll get to later):
To summarize, we explored the new functionality we wanted to achieve, and the code of each function. In the next parts, we will discuss the creation of the front-end, and the collaboration between different people making it happen.
Don’t forget to register for the May 5th Share IT Solutions Huddle
- Learn more about Cisco Identity Services Engine (ISE)
- Visit the DevNet Security Dev Center – to learn how Cisco Security supports third-party integration across its portfolio with 18+ open APIs and integration points.
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
Visit the new Developer Video Channel