Broker and protections

To apply the IP address of a broker user’s workstation against the protections table, prepend the string proxy- to the workstation’s IP address.

Important

Before you prepend the string proxy- to the workstation’s IP address, make sure that a broker or proxy is in place.

Consider an organization with a remote development site with workstations on a subnet of 192.168.10.0/24. The organization also has a central office where local development takes place. The central office exists on the 10.0.0.0/8 subnet. A Helix Core service resides in the 10.0.0.0/8 subnet, and a broker resides in the 192.168.10.0/24 subnet. Users at the remote site belong to the group remotedev, and occasionally visit the central office. Each subnet also has a corresponding set of IPv6 addresses.

To ensure that members of the remotedev group use the broker while working at the remote site, but do not use the broker when visiting the local site, add the following lines to your protections table:

list    group    remotedev     192.168.10.0/24              -//...
list    group    remotedev     [2001:db8:16:81::]/48        -//...

write   group    remotedev     proxy-192.168.10.0/24         //...
write   group    remotedev     proxy-[2001:db8:16:81::]/48   //...

list    group    remotedev     proxy-10.0.0.0/8             -//...
list    group    remotedev     proxy-[2001:db8:1008::]/32   -//...

write   group    remotedev     10.0.0.0/8                    //...
write   group    remotedev     [2001:db8:1008::]/32          //...

The first line denies list access to users in the remotedev group if they attempt to access Helix Server without using the broker from their workstations in the 192.168.10.0/24 subnet. The second line denies access from the IPV6 [2001:db8:16:81::]/48 subnet.

The third line grants write access to users in the remotedev group if they are using the broker and are working from the 192.168.10.0/24 subnet. Users of workstations at the remote site must use the broker. The broker itself does not have to be in this subnet, for example, it could be at 192.168.20.0.

The fourth line grants access from the IPV6 [2001:db8:16:81::]/48 subnet.

Similarly, the fifth and sixth lines deny list access to remotedev users when they attempt to use the broker from workstations on the central office’s subnets (10.0.0.0/8 and [2001:db8:1008::]/32).

The seventh and eighth lines grant write access to remotedev users who access the server directly from workstations on the central office’s subnets. When visiting the local site, users from the remotedev group must access the server directly.

dm.proxy.protects configurable

When the Perforce service evaluates protections table entries, the dm.proxy.protects configurable is also evaluated. This configurable defaults to 1, which causes the proxy- prefix to be prepended to all client host addresses that connect through an intermediary (proxy, broker, broker, or edge server), indicating that the connection is not direct.

Setting dm.proxy.protects to 0 removes the proxy- prefix and allows you to write a single set of protection entries that apply both to directly-connected clients and those that connect through an intermediary. This is more convenient but less secure if it matters that a connection is made using an intermediary. If you use this setting, all intermediaries must be at release 2012.1 or higher.