This blog will focus on three protocols that PSIM (Physical Security Information Management) and PACS (Physical Access Control) vendors must adopt if I was a customer looking for a new PAC system or wanting to integrate my existing PAC with my enterprise identity and access management (IAM) system:
As the planet digitizes, there is an ongoing convergence of physical and logical security which my previous blogs have explored and which I have implemented on two prior occasions. Using open protocols means that instead of writing unique API's (Application Programming Interfaces) for the PAC products for each identity and access management vendor, integration can be easily and cost effectively achieved by adopting open protocols.
As indicated above there are three protocols that PACS need to write into their code kits:
LDAP (Lightweight Directory Access Protocol) is already implemented in many PACS. This enables the enterprise directory (which contains the most current state of enterprise identities) to interface with the PACS. At Capital One in the mid 2000's my team wrote LDAP scripts to on and off board identities from enterprise directory to the Lenel PAC we had standardized on.
SPML (Service Provisioning Markup Language) is an open protocol that enables enterprise identity management provisioning services to automatically on and off board identities in PACS. At Toronto Hydro, my team is currently in the test phase of deploying SPML with Tyco's Intercon PAC. I explained to the Intercon team in my first meetings with them that using SPML was the obvious choice to having to write and maintain unique API's to the numerous identity and access management vendors' provisioning products. Instead, they would simply write and test the SPML interface once and then easily allow their customers to integrate with the identity provisioning service of whichever provisioning product they were using since almost all provisioning products are becoming SPML compliant.
XACML (eXtensible Access Control Markup Language) is a new open protocol that allows other systems to make access control decisions. It is conceivable that some enterprises will want their enterprise identity and access management system to make the decisions of who can get in the door. However, at Toronto Hydro, I decided to not do this immediately. There are also cons to this approach.
The enterprise identity and access management system network connectivity may be down or slow. As hundreds or thousands of people try to access certain doors at peak times, any slowdown will not be well received by the identities trying to get in or out of the door. I was planning in later releases to deploy a limited XACML where the vendor would build code that if the network connection was fine, it would accept XACML from the IAM system but, if the system response was too slow, it would revert to the PAC's own database.
In the future, I can see many variations on this. For high or critical security zones, the enterprise might want to use XACML and have the IAM system do the authentication and authorization decisions for certain physical access but decide to use the PAC's own database for medium or low security zone access, etc.
If I was a PAC customer, this is what I would demand of my PAC vendors to even get on the bid list. I would be aiming at easy integration of the selected PAC with my enterprise IAM systems. "With it" PAC vendors will quickly adopt and retrofit their PAC offerings with this if they want to continue to be successful in the future.