A bank's ISE deployment already maps users to identity groups, and the team wants Secure Firewall Management Center access rules to match on that identity instead of IP addresses. ISE already runs pxGrid with its controller enabled. Which pxGrid role assignment delivers the identity context to the Management Center?
Select an answer to reveal the explanation.
Short Explanation
pxGrid always runs through a controller, and here ISE publishes identity while the Management Center joins as a subscriber. Identity originates in ISE, so context flows outward to your firewall management. It's a newsroom pushing stories to subscribers instead of every reader editing the same paper.
Full Explanation
pxGrid is a publish-and-subscribe fabric in which every message is brokered by a controller, and on this network that controller is a service running on ISE. Because identity, group membership and posture all originate there, the Management Center registers with the controller as a client, subscribes to the session directory topic, and receives context updates as they happen for use in access control rules. Reversing the roles fails because the Management Center has no identity source of its own to publish for this purpose, and ISE would be consuming data it already owns. Hosting the controller on the Management Center fails because the controller service belongs to ISE, leaving no broker for either node to join. A direct peer-to-peer exchange without the controller fails because pxGrid nodes only talk to the controller, which handles discovery, certificate authentication and topic routing rather than letting two nodes negotiate on their own. Exam caveat: both systems must trust each other's certificates before a subscription completes, so a node that stays pending usually points at trust rather than policy. Practical check: confirm the Management Center appears as a connected pxGrid node in ISE, then find the user identity attribute on a connection event in the Management Center.