Avigilon Access Control Manager
Motorola Solutions (Avigilon)·AE_HSc_AvigilonConnectorGuide
Overview
The Avigilon connector integrates AlertEnterprise Guardian with Avigilon Access Control Manager (ACM) — Motorola Solutions' on-prem enterprise PACS appliance (acquired from Avigilon Corporation in 2018). ACM is typically deployed on customer-managed infrastructure as a dedicated server appliance running a hardened Linux distribution; it exposes a REST API used by integrators.
The connector ships as ALNTAvigilonConnector-5.0-SNAPSHOT.jar and deploys with the AE application build. The Alert Connector Framework (ACF) dispatches to the Avigilon Connector module, which calls the Avigilon REST API service over HTTPS. ACM uses an embedded directory model — cardholders are represented as objects with LDAP-style attribute names (e.g., cn) and credentials are called Tokens (Avigilon's terminology) rather than Badges.
Two operational notes are unusual for AE PACS connectors: (1) the data format on the wire is XML, not JSON; (2) for ACM 5.6+ the integration uses AES-256 token encryption, which requires the AE-side JVM to have the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files installed.
Architecture
Composed from this connector's actors + edges. Trust zones are color-coded; trust crossings render as thicker lines.
Authentication
1 method supported
ACM authentication uses a dedicated API user (User Id) and password. Credentials are submitted to the Avigilon REST API which returns a session token; the token is then used for subsequent calls. SSL must be enabled (SSL = True system parameter) — the connector will not communicate over plaintext.
Prerequisites
Everything that must be in place for this connector to work, with the owner who's responsible.
Avigilon ACM with REST API enabled
customerAn Avigilon Access Control Manager appliance (version 5.4.4 or 5.6.4+) with the REST API enabled and a dedicated API user provisioned with provisioning + read privileges. The REST URLs and credentials are provided as part of the Avigilon ACM deployment.
JCE Unlimited Strength Jurisdiction Policy Files (5.6+ only)
aeACM 5.6 and above uses AES-256 token encryption. The AE-side JVM must have the JCE Unlimited Strength Jurisdiction Policy Files installed. Copy local_policy.jar and US_export_policy.jar to $JAVA_HOME/jre/lib/security and restart the application server. IBM JDK has equivalent jar files obtainable from IBM Support.
SSL certificate trust
aeThe Avigilon ACM appliance's SSL certificate must be imported into the AE host's JVM cacerts keystore. The guide documents the manual keytool -importcert procedure followed by a restart of the Job and API services.
Templates directory and date format configuration
aeThe connector requires a Templates Directory (filesystem path to XML templates installed during connector installation) and explicit date-format system parameters (Alert Application Date Format = MM/dd/yyyy, Provisioning Date Format = yyyyMMddHHmmss, Reconciliation Date Format = yyyyMMddHHmmss).
Known limitations
Documented constraints to set customer expectations before deployment.
XML payload format
informationalUnlike most modern AE PACS connectors which use JSON, the Avigilon connector serializes payloads as XML. Customers using AE in customer-cloud deployments where outbound XML payload inspection is constrained should verify that any inspection layer (CASB / DLP / WAF) permits XML to Avigilon ACM endpoints.
AES-256 cipher requires JCE policy files (5.6+)
importantWithout JCE Unlimited Strength Jurisdiction Policy Files installed on the AE-side JDK, the connector cannot communicate with ACM 5.6+ at all — token encryption will fail at connection setup. This is a hard prerequisite, not a graceful degradation.
Data fields
35 fields mapped between AE Guardian and the vendor system.
| AE field | Vendor field | Description | Direction | Required |
|---|---|---|---|---|
| UserId | Cn | ACM uses LDAP-style `cn` (common name) as the primary user identifier. | bidirectional | yes |
| ExternalSystemId | ExternalSystemId | — | bidirectional | yes |
| FirstName | FirstName | — | bidirectional | yes |
| LastName | LastName | — | bidirectional | yes |
| MiddleName | MiddleName | — | bidirectional | no |
| EmployeeType | Type | — | bidirectional | no |
| Status | IDStatus | Mapped enum: Active=1, Inactive=2, Not-Yet-Active=3, Expired=4. | bidirectional | no |
| Title | Title | — | bidirectional | no |
| Department | Department | — | bidirectional | no |
| Division | Division | — | bidirectional | no |
| Street | Address | — | outbound | no |
| City | City | — | outbound | no |
| State | State | — | outbound | no |
| Zip | ZipCode | — | outbound | no |
| SiteLocation | SiteLocation | — | bidirectional | no |
| Building | Building | — | bidirectional | no |
| EmailAddress | — | bidirectional | no | |
| Mobile | Phone | — | bidirectional | no |
| Photo | ImageData | Cardholder image data, embedded in XML payload. | outbound | no |
| BadgeId | TokenInternalNumber | ACM's internal "Token" identifier (Avigilon term for a credential). | bidirectional | yes |
| BadgeValidFrom | TokenActivateDate | Date format yyyyMMddHHmmss. | outbound | no |
| BadgeValidTo | TokenDeactivateDate | Date format yyyyMMddHHmmss. | outbound | no |
| BadgeStatus | TokenStatus | Active=1, Inactive=2. | bidirectional | yes |
| TokenEmbossedNumber | TokenEmbossedNumber | Physical printed number on the card body. | bidirectional | no |
| PIN | TokenPin | — | outbound | no |
| TokenDownload | TokenDownload | Whether the token has been pushed to door controllers ("TRUE"/"FALSE"). | bidirectional | no |
| TokenLevel | TokenLevel | Numeric access level on the token. | bidirectional | no |
| TokenVIP | TokenVIP | VIP flag — door unlocks immediately, bypasses some timers ("TRUE"/"FALSE"). | bidirectional | no |
| TokenNoExpire | TokenNoExpire | Token never expires ("TRUE"/"FALSE"). | bidirectional | no |
| TokenTrace | TokenTrace | Audit-trace flag — records every use of this token ("TRUE"/"FALSE"). | bidirectional | no |
| TokenPinExempt | TokenPinExempt | Exempts the token from PIN-required reader prompts ("TRUE"/"FALSE"). | bidirectional | no |
| TokenExtAccess | TokenExtAccess | Extended access duration (ADA / accessibility support — door stays unlocked longer; "TRUE"/"FALSE"). | bidirectional | no |
| TokenUserLoseExempt | TokenUserLoseExempt | Token is exempt from auto-deactivation if the user is marked lost or inactive ("TRUE"/"FALSE"). | bidirectional | no |
| RoleName | ROLE_NAME | — | bidirectional | no |
| RoleActive | ROLE_ACTIVE | — | bidirectional | no |
PACS specifics
ACM uses an LDAP-style attribute model — cardholders are objects with cn (common name = UserId), FirstName, LastName, Type, IDStatus, Title, Department, Division, address fields, SiteLocation, Building, EmailAddress, Phone, and ImageData. Each cardholder has one or more associated Tokens (Avigilon's term for a credential / badge), each with TokenInternalNumber, TokenStatus, TokenActivateDate, TokenDeactivateDate, TokenLevel, and a set of boolean flags (TokenVIP, TokenNoExpire, TokenTrace, TokenPinExempt, TokenExtAccess, TokenUserLoseExempt).
Access is granted by associating a Token with a TokenLevel (numeric access level) and assigning the cardholder to one or more Roles (ROLE_NAME / ROLE_ACTIVE). The connector supports Modify User Roles and reconciles role assignments bidirectionally.
A single Avigilon ACM appliance is typically a single tenant. Customers running multiple ACM appliances (e.g., per-site) require one AE→Avigilon connector instance per appliance.
- Topology
- on-prem
- Event model
- polling
- Anti-passback
- unknown
- Holiday schedules
- unknown
- src/connectors/avigilon/source.pdf — Full connector guide — 20 pages, updated 2024-12-03
- src/connectors/avigilon/source.pdf — p5 — Supported Version
- src/connectors/avigilon/source.pdf — p7 — Connector Architecture diagram
- src/connectors/avigilon/source.pdf — p6 — Provisioning Capabilities