Question about identity broker

[RemoteUser]

Hi Mates,

I have a question regarding an Identity Broker setup.

We have multiple CMAs managed by the same MDS, and we currently have a cluster acting as the Identity Broker for sharing identities between the different CMAs.

Would it be possible to move the Identity Broker cluster from CMA X to another CMA (CMA Y)?

If so, could you please advise on the expected behavior and whether there are any specific considerations, limitations, or precautions we should take into account before performing the move?

Thanks in advance

[Vincent_Bacher]

Hi,

Moving the broker cluster to another CMA is possible, no rocket science.

The good news: the actual publisher/subscriber relationships live in the identity_broker.C on the gateway itself, so they survive the move untouched. A few things don't, though:

• The subscriber certificate is configured in the gateway object, so that setting lives in the CMA X database and needs to be set up again in CMA Y. If you re-use the same certificate, the publishers won't notice anything. If a new cert gets issued (e.g. because the old one came from CMA X's ICA), the publisher side may need updating too. If not, you may have to issue BrokerCertFetcher <subscriber ip> to retrieve the cert and to be able to update the identity_broker.C in case cert is verified.
• Think about where the broker gets its own sessions from. Identity Collector and agents reconnect by IP, so if the IP stays the same you mainly need to redo the settings in the new gateway object. VPN clients are the tricky part I never used this identity source.

One more thing to keep in mind: before R82.10, classic PDP-to-PEP sharing only works within the same CMA, so any PEPs served by this PDP need to stay in CMA Y with it. If you're on R82.10 already, direct cross-domain PDP-to-PEP sharing might even let you simplify the whole setup.

Cheers

[RemoteUser]

Hi vincnet,
Thank you for the reply,
Could you explain that last sentence in more detail? We actullay running on R82.10 but on S1C not the GW's itself

[Vincent_Bacher]

Sure,
what i was talking about is the new feature called "scaled identity sharing" allowing to share identities e.g from your broker gateway to a maximum of 300 PEP (enforcing firewalls) in same or different CMA.
This works well, I already tested this in lab environment.

This is documented here:

https://sc1.checkpoint.com/documents/R82.10/WebAdminGuides/EN/CP_R82.10_IdentityAwareness_AdminGuide...

[RemoteUser]

Thank you, but the standard GW (PEP) also needs to be updated to version R82.10... If this configuration only required the PDP to be updated to version R82.10, I could simply ask the customer to update the PDP broker, but since we have to update many GWs, that takes a lot of time, too!

[Vincent_Bacher]

Fair point — upgrading many PEPs is indeed the price for scaled sharing, and we haven't migrated to R82.10 ourselves yet either, because it takes time to upgrade more than 300 devices.
I just mentioned it as it might be useful down the road.

Everything I wrote about moving the Identity Broker is independent of this anyway — that works on your current version as-is.

[RemoteUser]

What do you think about the infinity idenitty? This, too, could be an alternative?

[Vincent_Bacher]

Phew. Infinity Identity could be an option, but honestly that's a design question rather than a quick swap.
To have an idea if it's an option, more details would be useful i guess and i am not experienced with infinity identity.
Anyway, I'd say it depends on where your identities come from (IDC/AD, ISE, cloud IdPs like Entra ID), how you use them in policy, and where your users and enforcement points sit.

Two things to keep in mind though: gateway integration with Infinity Identity is a recent addition (R82/R82.10), so you'd likely face the same upgrade effort you wanted to avoid with scaled sharing. If I am not wrong.

For your original question — just moving the broker to another CMA — you don't need any of this.

Would evaluate Infinity Identity separately as a longer-term design topic in case it fit's your setup.

[Royi_Priov]

Hi @RemoteUser 

Identity and Trust (the new name for Infinity Identity) presents a different approach to identity flow in Quantum.

You can think of Identity and Trust as a PDP-as-a-server, but more capable.

However, as Vincent mentioned, it is a design question you should consider.

If for one of the following questions, the answer is "yes", Identity and Trust is definitely your solution:

• You have an identity integration that works only with Identity and Trust - Entra ID & Intune or Defender, CrowdStrike Falcon, Check Point services such as SASE, Endpoint, Browse and Workforce AI.
• You want to use trust information (device or user posture) in the policy, alongside user, device, and group membership.
• You would like to reduce IDA deployment complexity.
• Have a centralized single source of truth for identity.

If you have questions, I'm here to answer 🙂

[Vincent_Bacher]

@Royi_Priov  Sorry to contradict you, but it’s not quite that universal. We also want to
reduce the complexity of IDA deployment.
But that’s not always possible. For example, in future we’ll only be using IDA for Cisco’s SGT, as there’s simply no identity and trust involved there (why do I always have to get used to new names? 😀 )

[Royi_Priov]

@Vincent_Bacher 

Identity and Trust does support Cisco SGT via Identity Collector.

I was referring to reducing IDA sharing & Broker topology.

Identity and Trust can scale up if needed, so customers don't need to deploy PDPs and change the environment configuration just to support more identities / different requirements.

In addition, I&T is a single place for configuration - configure your directories, integrations, and filters once, and that's it 🙂

As for the naming - I can't control it 🙂 It was done as part of bigger CP branding, but I'm satisfied with the new name 😍

[Vincent_Bacher]

OK, makes sense, thanks for your explanation.
In our use case we already have a (we call it) identity backbone and it works so I will not change it. 
But in other environments it seem to be really feasible to have this as an option.
thanks, 
best,
Vince

[RemoteUser]

Hi Vincent, sorry to bother you again, but I just thought of another question.

If I move those PDP clusters (Identity Broker) to another CMA, what happens to the Identity Sharing relationship with the PEP Gateways that remain in the original CMA?

More specifically, would moving the PDP to a different CMA cause the PEPs to lose access to the shared identities, or does Identity Sharing continue to work across different CMAs?

[Vincent_Bacher]

No bother at all.

That's exactly the catch I hinted at earlier: classic PDP-to-PEP sharing does not cross CMA borders. So yes — the moment the broker PDP lives in CMA Y, the PEPs left behind in CMA X lose their identities. Nothing crashes, they just stop receiving sessions.

The classic way out: keep (or build) at least one PDP in CMA X and let your broker push the sessions to it as a subscriber. That local PDP then feeds the PEPs in CMA X the traditional way. Works fine, it's just one more box in the identity chain.

And this is where the R82.10 scaled identity sharing I mentioned becomes interesting after all — with that, a PDP can share directly to PEPs in a different CMA, so the extra PDP in the old CMA wouldn't be needed anymore. But as discussed, that requires the PEPs on R82.10 too, so for your current situation the subscriber PDP in CMA X is the way to go.

Cheers