Genetec recommendations Federated systems are not the method to be used to manage Cardholders and Credentials centrally. Cardholders and credentials should be created and managed at each federation site and SAFR should be connected to each federated site to synchronize Cardholders and credentials.
Per Genetec subject matter expert on the subject:
Federation is meant as a monitoring tool to bring entities and event data from remote systems into a head end system, such as a GSOC or HQ. Federation is not intended as a means to administer multiple systems.
Although it is possible to give a Federated cardholder local access it is not recursive, meaning the Federation Host cannot grant access to doors at a remote site. Any additional credentials given to a Federated cardholder stay on that local system and are not saved on the source system.
If a customer wants to manage cardholders globally from one location, we typically recommend ClearID or a system design where all Cloudlink devices communicate with a single system. Global Cardholder Management is a last resort and not often recommended or deployed.
There are other options, such as the cardholder sync plugin that could be deployed, but those would be created as local cardholders to the system where the plugin is deployed.
At the end of the day, if you are trying to solve for the Federated model, each system should contain a unique set of cardholders, or should all be synced with the same source (AD or database view), so hopefully you wouldn’t have to worry much about replicated cardholders. If a particular customer chooses to deploy your solution, and their system architecture poses an issue, we should discuss it before deployment.
Cardholders and credentials should be created and managed at each federation site and SAFR should be connected to each federated site to synchronize Cardholders and credentials.
In below diagram, a separate instance of SAFR is connected to each local Genetec Security Center server. No cardholders are managed in the central Genetec Federation server.
This configuration requires a SAFR License Account for each instance of SAFR. This does not incur additional costs but requires that multiple license requests be submitted, one for each SAFR Server.
While not recommended, SAFR maybe connected a Genetec Federation Host. This section describes the behavior when doing so. The recommended configuration (SAFR Server connected to local Genetec Synergis Servers) will result in best performance for both full synchronization and incremental synchronization.
SAFR will synch federated Cardholders from the Federated Host (meaning the Federated Host has cardholders from the Federated system(s)) with the following caveats.
Questions or comments about the documentation? Email us at safr-doc-feedback@realnetworks.com .
1