Main Page

Introduction & benefits

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily Network Door Controllers from Axis Communications. The Axis door controllers can also be extended with wireless locks using either SimonsVoss SmartIntego or Assa Aperio.

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:

• Cloud-based service
• Simple and secure connection of door controllers
• Mobile access with smartphone app or URL
• Simple access for visitors
• Delegated administration
• Powerful framework for custom actions
• Strong security
• API for external integrations

Cloud-based service

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely independent of location. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is no need for system maintenance, i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution keeps working during temporary network failures. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

Simple and secure connection

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

Mobile access

The Telcred Personal and Telcred Home apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

Visitor access

A Visit allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

Delegation

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is delegation. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: System Manager.

Actions

Telcred offers a powerful framework to perform both built-in and custom actions when a trigger is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a command, which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:

• Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
• Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
• Put a building in lockdown (all doors are locked and access control readers are blocked)

Security

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

API for integration

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

System components

Telcred Access Manager consists of four main components:

1. Cloud-based server software
2. User interfaces for access administration, configuration and end users
   • Web-based GUIs (Access Manager & System Manager)
   • Apps (Telcred Personal & Telcred Home)
3. APIs for integration of GUIs, apps, and 3rd party software
4. API for communicating with IP door controllers

Currently, The Telcred solution supports Network Door Controllers from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

• up to 16 wireless locks from SimonsVoss SmartIntego (via a SmartIntego hub connected to the controller over IP)
• up to 8 wireless locks from Assa Aperio (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the Axis Network I/O Relay Modules. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

• The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

Access control model

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a privilege. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

• Card only
• Card + PIN
• PIN only
• Mobile
  • Remote
  • On site
  • At door
• API 1
• API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

Users receive privileges (i.e. access rights) through a role. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

Account structure and delegation

Account, Systems, and delegation

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc, and has its own administrators. The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without being dependent on the building's owner.

System types

There are four types of systems:

• Standard
• Standard with delegation
• Virtual
• Sub-system

A standard system contains all functionality, including hardware configuration, except delegation. A standard system with delegation also provides the opportunity to create Sub-systems and share doors with Virtual systems (see below).

A virtual system does not have any own hardware, but instead gets doors from other systems of type Standard with delegation. A typical use case for a virtual system is an organization where the employees visit many different sites.

Sub-systems also must get their doors from somewhere else, but in this case they can only get doors from the parent system of which they are a part. A typical use case for a Sub-system is a tenant.

Domains

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a Virtual system, the doors and privileges of the Domain become available for access administration in the receiving system.

Example

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to a Virtual system, they can manage the two offices together.

Systems and Domains are created, organized and maintained in System Manager.

Administrators and capacities

A person doing any type of administration in Telcred Accress Manager can have different capacities depending on what they should be able to do. The capacities are:

• Account management (Account settings, create and edit Systems and Administrators)
• System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
• Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

Administration GUIs

System Manager web GUI

• Account orchestration. Manage:
  • Systems
  • Domains
  • Sub-systems
  • Administrators
• Card management for any system in the Account

Access Manager web GUI

• Access Management (for Systems and Sub-systems)
• Hardware configuration (for Systems)

Telcred Home app

• Access Management for residents

Introduction to System Manager

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

• Account
• Systems
• Sub-systems
• Administrators

Account

An Account contains at least one System. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

Systems

An account has to contain at least one system. Each system has some settings, e.g.:

• Name
• Default time zone
• Max PIN size
• Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards to Domains and Sub-systems.

Sub-systems

These receive doors and potentially Cards from the parent System. Typically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

Administrators

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

Introduction to Access Manager

The Access Manager GUI is web-based and available at:

https://access.telcred.com

Login context

In the top-right of the screen, the login context is displayed:

• Account name
• Current System
• Logged in Administrator

If you have access to more than one Account, it is possible to switch between them using the dropdown-menu to the right of the Account name. Likewise, if the Account has more than one System, and the Administrator has administration rights in more than one of the Systems, it is possible to switch System using the dropdown-menu to the right of the System name.

To access the Administrator settings, e.g. to change password, expand the menu right next to the currently logged in Administrator.

Four main menu groups

The administrator GUI is divided into four main menu groups:

• Start. The most common options including view status and event log; Manage users, devices, doors, and schedules.
• Roles. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found here.
• Actions. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a Door forced open alarm".
• Configuration. Manage hardware configuration for doors, door controllers, and hubs.

List pages and detail pages

In each group a number of list pages are available from the menu. From the list page it is possible to click an individual item to get to its detail page where it is possible to view or change detailed information.

1. Currently selected list
2. Click a list item to see the details
3. Number of items in list

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

Administrator GUI menu options

Start

Status

After successful login, the administrator is presented with an overview page showing:

• Latest alerts
• Doors with issues (offline or failing sync process)

Events

Events include the results of user interactions, i.e. access granted or denied, as well as different types of alerts, e.g. door forced open or door left open. In the GUI, events can be filtered and sorted.

More information about events can be found here.

Users

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found here.

Cards

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found here.

Doors

The Doors tab is used to change the door settings, e.g. access time, "open too long" alarm, and unlock schedule. It is also possible to check the status of the door (if it is locked and closed) and to perform the following actions:

• Grant access
• Manually unlock
• Manually lock
• Manually block
• Return to schedule

More information about doors can be found here.

Schedules

Schedules are used to:

• Control when a door should be single locked, double locked or unlocked
• Specify when a privilege is valid
• Specify when a visit is valid

A schedule contains one or more schedule items. A schedule item can occur once, or recur weekly or yearly.

It is possible to define that a schedule item should be excluded from the normal schedule, which can be useful to manage e.g. public holidays.

More information about schedules can be found here.

Visits

The purpose of Visits is to enable people who are not registered users in the system to access one or more doors during a limited time. A typical use case could be an event where you want the guests to be able to let themselves in through the front door, but only on the night of the event.

When creating a new visit, the system will generate a URL (web address), a random PIN, or both. The URL can be pasted into an email and sent to the visitors. When the visitor clicks the URL in the email application on their smartphone it takes them to a web page where they will see an "Open" button for each door included in the visit. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that Visits is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found here.

Keys

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found here.

Roles

Roles

Roles is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and typically express the user's job function, e.g. "technician" or "student". A user can have many roles.

More information about roles can be found here.

Privileges

Privileges express access rights, i.e. the right to open one or more doors. A privilege is defined by a combination of:

• one or more doors
• one or more credentials
• an optional schedule

The supported credential types are:

• Card only
• Card + PIN
• PIN only
• Mobile remote
• Mobile on site
• Mobile at door
• API 1
• API 2

More information about privileges can be found here.

Door groups

Door groups are collections of doors. The main purpose of door groups is to make it easy to create privileges / access rights for groups of doors, without having to list all the individual doors.

Door groups is a generic construct which can be used to express any logical grouping of doors, e.g. site, floor, type of room, security level, geographical area or something else.

More information about door groups can be found here.

Triggers

Triggers

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:

• Event
• Reader input
• Remote action
• IO port activity
• External request

More information about triggers can be found here.

Recipients

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the Recipient specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found here.

Commands

A command is a set of one or more actions that can either be performed by an administrator or as a result of a trigger. Some use cases for commands include:

• Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
• Interact with an external system (e.g. arm or disarm an intrusion detection system)
• Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found here.

Configuration

Door configs

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found here.

Controllers

A controller controls one or more doors and has a number of settings related to the door hardware, e.g. the lock configuration, type of reader, if a door monitor or REX-button (REquest to Exit) is used etc. The controller also has settings related to its own time zone, connection mode and firmware.

Typically, the controller settings will be done by the installer / integrator and not by the end customer administrator.

More information about controllers can be found here.

Hubs

Hubs are only used in connection with wireless locks from SimonsVoss SmartIntego or Assa Aperio. Before a hub can be linked to a controller, it needs to be created here.

More information about hubs can be found here.

Guides & tutorials

Connect an Axis controller with O3C

To connect an Axis Network Door Controller to the Telcred service you need:

• The controller
• An Ethernet connection capable of supplying PoE (Power over Ethernet)
• The MAC address of the controller (printed on the device but called S/N)
• The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

1. Select Controllers in the main menu and click Add new
2. Give the controller a name
3. Make sure the Connection mode is O3C (this is the default)
4. Enter the MAC address and OAK
5. Click Save

After a few seconds, the status message at the top of the page should now say Ready - Waiting for the controller to initiate connection. This means that Telcred Access Manager managed to connect to the Axis Dispatch server and claim this controller.

The final step is to push the control button on the controller for 1 - 2 seconds:

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to Online.

• Detailed information about the A1001 communication settings can be found here.
• Detailed information about the A1601 communication settings can be found here.

Set up a new user & provide him or her with access to a door

After a new system has been set up, at least one controller with a reader has been connected, and at least one door config configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

1. Create a user
2. Register a new card and assign it to the user
3. Create a privilege
4. Create a role linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

Technical references

API documentation

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:

• Webhooks API. Used to let another system receive push notifications. The API documentation can be found here.
• Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found here.
• Owner API. Used to e.g. manage organizations and officers. The API documentation can be found here.