Cloud Identity Engine Topology
Learn about the structure or topology of the Cloud Identity Engine.
| Where Can I Use This? | What Do I Need? |
|---|
|
| The Cloud Identity Engine service is free; however, the enforcement
points utilizing directory data may require specific licenses. Click
here for more
information. |
The "topology" of the Cloud Identity Engine refers to how it connects the different parts
of your network. In traditional setups, connecting security devices to user directories
often looks like a messy spiderweb, where every firewall has to talk to every server
that holds user passwords. The Cloud Identity Engine simplifies this by using a
"hub-and-spoke" design. In this model, the Cloud Identity Engine sits in the center (the
hub), and all your user directories and security devices connect only to it.
On one side of the hub, you have your
Sources—the places where user accounts
live:
Cloud Directories: If your user accounts are in the cloud (like Okta,
Google, or Microsoft Entra ID), the Cloud Identity Engine connects to them
directly over the internet using secure digital keys.
On-Premises Directories: If your user accounts are stored on physical
servers in your office (like Active Directory), you install a small piece of
software called the Cloud Identity Agent on a server. This agent
safely reads the user list and sends it securely to the cloud hub.
Context Collector: If you have endpoints in air-gapped or restricted
environments that the cloud cannot reach directly, you can deploy a context
collector. Unlike the Cloud Identity Agent, which runs on a server inside
your network, a context collector is a VM that collects user context
locally—including IP tags, user mappings, and quarantine lists—and publishes
it to the Cloud Identity Engine. Context collectors are automatically
onboarded to a dedicated Context Collector folder and pre-configured as
publishers, so context from restricted environments flows into the same hub
as your other sources.
On the other side of the hub are your Consumers—the security devices that need to
know who users are to enforce rules. These include your NGFWs and remote access services
(like Prisma Access). Instead of storing their own copies of user lists, these devices
simply "subscribe" to the Cloud Identity Engine. When they need to know if a user is
allowed to access a website or file, they check with the central hub. This structure
means you only have to configure your connections once, rather than setting them up
separately on every single device in your network.
Once you have reviewed the architectural requirements and planned your deployment,
proceed to Set Up Cloud Identity Engine to prepare your network and activate the
service.
