R82.10 - New feature called "Scaled Identity Sharing"

[Vincent_Bacher]

Hi mates,

just build a lab for R82.10 to test the new feature called Scaled Identity Sharing.
Documented in Scaled Identity Sharing

As we know, Identity Sharing was not possible between different CMA / Management Domains. Here we had to use Identity Brokers.

Beside the new enhancements of "A single Policy Decision Point (PDP) gateway can now distribute identities to up to 300 Policy Enforcement Point (PEP) gateways" and "Policy Decision Point (PDP) gateways can now handle up to 1 million identities each" (R82.10) release notes., there is a new feature in R82.10

So when we are talking about Devices in different CMA but managed by the same MDS, Scaled Identity Sharing comes into the game. While normal identity sharing works with SIC, Scaled Identity Sharing works with TLS.

This might be of interest to some of you. For an initial test, I set up a small lab with two CMAs and one gateway per CMA, with the PDP in one CMA and the PEP in the other. I also defined web-based authentication and a local user.

(I have not shown every step below, but they are listed in the documentation.)

When you do the steps described in the docu above and enabled scaled sharing on the involved devices you cann start to select the destination CMAs to share identitys at the pep object. Done in MDS context:


Then you select the target CMAs

Then you can go to the target CMA and continue with the pep. In the Identity Sharing Section you now can see the sharing device with a prefix identifying the source cma (*_of_<source cma name>)
 

Now i logged into the PDP using ida web auth and i see my session in the pdp monitor

 pdp m u OzzyOsbourne

Session:  f4246b45
Session UUID:  {A1FEE917-A510-30F1-1E50-B4AEA06C199B}
Ip:  10.18.53.40
Users:
 OzzyOsbourne {5190ab02}
   LogUsername: OzzyOsbourne
   Groups: All Users;MetalLegends
   Roles: -
   Client Type: portal
   Authentication Method: User & Password
   Distinguished Name:
   Connect Time: Thu Feb 12 11:40:09 2026
   Next Reauthentication: Thu Feb 12 23:40:19 2026
   Next Connectivity Check: Thu Feb 12 23:40:19 2026
   Next Ldap Fetch: -

Packet Tagging Status:  Not Active
Published Gateways:  Local
************************************************************************************

And on the pep you can see firstly the connection to the pdp

 pep s pdp a
Command: root->show->pdp->all
--------------------------------------------------------------------------
| Direction | IP           | ID | Status    | Users | Connect time       |
--------------------------------------------------------------------------
| Incoming  | 10.17.71.196 | 0  | Connected | 11    | 12Feb2026 11:08:13 |
--------------------------------------------------------------------------

And secondly my session:

 pep s u q usr OzzyOsbourne
Command: root->show->user->query


PDP: <10.17.71.196, 00000000>; UID: <f4246b45>
==================================================
  Client ID          : <10.18.53.40, 00000000>
  Authentication Key : <->
  Brute force counter: 0
  Username           : OzzyOsbourne
  Log Username       : OzzyOsbourne

  Machine name       :
  User groups        : <All Users, MetalLegends>
  Machine groups     : <>
  Compliance         : <>
  Identity Role      : <>
  Time to live       : 86400
  Cached time        : 86400
  TTL counter        : 0
  Time left          : 85163
  Cached Session     : No
  Client type        : portal
  Last update time   : Thu Feb 12 11:41:30 2026
  Connect time       : Thu Feb 12 12:40:19 2026

At the top you easily see the PDP the session comes from.

Two things to be aware of:

1, For some reason i don't see the PEP on the pdp using pdp con pep. Maybe i have to use a different command.
2. If you use Push as Sharing method it won't work. Don't know yet why.

[PhoneBoy]

Is it doing the enforcement correctly on the pep, though?

[Vincent_Bacher]

I have no traffic through the device. Would have to think about how to test.

[Vincent_Bacher]

User is shown in the logs when accessing the device but the policy including the access role does not match for some reason

[PhoneBoy]

I suspect it doesn't pull into the PEP until it has a reason to (i.e. generated traffic from a relevant network).
At least this is how it generally works with Identity Sharing.

[Vincent_Bacher]

The pep pulled the session. The user is visible in the "enforcing" pep. 
I authenticated to the pdp using web auth portal. Then the pep pulled the session, you can see that when issuing "pep s u q usr" here the pdp ip is stated.

I have the doubt that the access role does not work work with a local user. I never tried doing anything with a local user before.
Wanted to avoid to configure an ldap account unit to a productive AD but tomorrow i will do.

[Vincent_Bacher]

@PhoneBoy  Regarding your statement 

„I suspect it doesn't pull into the PEP until it has a reason to“

you can give it the reason just by sending an echo request to the client and then the pep pulls info from pdp and you immediately see the session. 
A colleague from Check Point reminded me of this.

[Vincent_Bacher]

Good news. I now defined a LDAP Account Unit connecting to a productive AD server so i can login using my official account.

Created access role and policy on PEP



Then logged into PDP using web auth.

Sessions on PDP



Fetched identities / sessions on PEP:



Now accessed PEP and checked logs



So scaled identity sharing works and correct policy matched and enforced.

[PhoneBoy]

Identity Awareness gets group information from either LDAP or SAML.
Not sure it supports local groups, but maybe it'll support Identity Tags.

[Vincent_Bacher]

Sure. AD is used here since years and works well.

We have a pilot running using IDC connected to ISE/pxGrid and we receive SGT from ISE. Then for the access role to match, identify tags are defined. Works well.

[the_rock]

Amazing job Vince...wow.