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, and specifically the A1001 Network Door Controller from Axis Communications.

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:

• Hosted service
• One-click-connection
• Smartphone app
• URL access for visitors
• Delegated administration
• Strong security
• API for external integrations

With a hosted service there is no need to install software locally or worry about upgrades, security patches, backups, etc. This is all professionally managed by Telcred. All relevant data is also 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 cloud service.

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 will then automatically download the connection settings from an Axis server and immediately use them to connect to the Telcred service.

The Telcred Entry app for iOS and Android can be used to open doors as a complement, or alternative, to traditional cards and keyfobs. Opening a door with the app takes less than a second and can be used to let someone in remotely. Alternatively, if all users have the 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.

It is possible to generate a hard-to-guess URL that will open one or more doors during a specified time. This URL can then be included in e.g. an email to visitors to a meeting or an event. When the visitors arrive, they can let themselves in simply by clicking the URL in their smartphone email application, without having to receive an access card or install an app. The URL method of access is to be considered low security (anyone who has access to the URL can open the doors), but for some use cases this is an acceptable tradeoff for the convenience it provides.

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 let different organizations, e.g. tenants or sub-contractors, manage their own doors, users, and access rights. At the same time, simple yet powerful features allow for sharing of users and access rights between organizations. This functionality supports use cases where e.g. a user belonging to one organization must first pass doors belonging to another organization in order to get to the doors belonging to his/her own organization.

All communication between the door controllers and the Telcred cloud service use strong encryption. The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. The communication between the Telcred Entry app and the cloud service uses strong authentication based on PKI.

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 or a workforce management system with the Telcred access control service.

System components

Telcred Access Manager consists of five main components:

• Cloud-based server software
• Web-based GUI for installers and end customers
• Smartphone app for iOS and Android
• API for communicating with IP door controllers
• API for integration with 3rd party software

Currently, The Telcred solution works with the A1001 Network Door Controller from Axis Communications. One A1001 controller can manage one or two doors with electrical locks, alternatively one door with electrical locks and up to eight Assa Aperio battery operated wireless doorblade readers (via an Assa Aperio wireless hub that is connected to the A1001).

Delegation

This section provides a high level overview of Telcred's delegation concept and features. A more detailed description can be found here.

Systems and organizations

A Telcred customer account is referred to as a system.

For any system, an arbitrary amount of organizations can be created. These can represent e.g. subcontractors or tenants. The purpose of organizations is to enable delegated administration of access rights. Each organization has its own users, access rights, cards, events, and doors, which normally only can be seen by the administrator(s) of that organization.

Sharing access rights and users with other organizations

It is also possible to share access rights and/or users between organizations (no data is ever shared between systems).

The purpose of sharing access rights is to let an administrator of one organization assign access rights to doors belonging to another organization to his or her own users. One example of this could be where a building owner wants to allow the tenants to manage their own doors, users, and access rights, but also to create access rights to the shared entrance door from the street, which belongs to the building owner.

Sharing users, instead, is useful when a person belonging to one organization often visits premises belonging to another organization. Instead of having to maintain two identities for what is actually the same person, the administrator of the user's home organization can share this user with the other organization, so that that administrator can assign access rights to him or her.

Officers and capacities

A person doing any type of administration in the Telcred system is known as an officer. These can have different capacities depending on what they should be able to do, and one officer can have several capacities. The capacities are:

• System owner
• Organization owner
• Administrator

More detailed information about officers and capacities can be found on the page about delegation.

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 policy. A policy expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a policy is defined by the credential that needs to be used (e.g. card + PIN) and a schedule that determines when it is valid. 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 policy are:

• card only
• card + PIN
• PIN only
• remote (the Telcred app)
• URL

In all cases, except for policies with URL, users receive access rights (i.e. policies) through either a Role or an Assignment. A role can contain many users and many policies, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, etc. Assignments work the same way as roles but have a slightly different purpose. While roles are meant to be few and long lived, assignments are meant to be used to give a user temporary access rights. This way, the need to create temporary access rights does not lead to a large number of roles which could be hard to overview after a while. Both roles and assignments can have a start and end time, during which the assigned policies 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 "unlinked" from a user it will lose all its access rights and not be able to open any doors.

Policies with URL as credential function differently from the model described above, since they are meant to be used by people who are not registered users in the system (e.g. temporary visitors). They are only meant to be used together with Visits. When creating a new Visit, the administrator chooses which doors the URL of the Visit should be able to open, by selecting a corresponding policy.

Administrator GUI

The administrator GUI is available at:

https://access.telcred.com

Dashboard

After succesful login, the administrator is presented with a dashboard showing:

• Latest alerts
• Latest events
• Offline doors
• Statistics on number of doors, users, devices, etc.

Roles

Roles is one of two ways to assign access rights to a user (the other being Assignments). A role connects one or more users to one or more policies. Roles have names and would typically express the user's job function, e.g. "technician" or "student". A user can have many roles.

Assignments

Assignments function identical to roles, but have a different purpose: temporary access rights.

By using assignments for temporary access, the list of roles can be kept short and stable over time.

Users

Users are the end users of the system that need to be able to open doors. A user must have a name.

Access rights are always set for a user (using either Roles or Assignments). A user can be the owner of one or more devices. Every device that a user owns, will inherit the access rights of its owner.

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

A personal PIN can also be set for a user. Some policies require the entry of a correct PIN to open the lock (typically for high security doors or out of office hours). The PIN needs to be numeric and four digits long.

A user can also be shared with other organizations, which is explained in the section on Delegation.

Devices

A device must have a name and a type. Currently, two types of devices are supported: Card with ID and Mobile phone. When creating a new device of type Mobile phone, a Registration code will be displayed. This is a one time code that the user must enter when starting the Telcred Entry app for the first time (its purpose is to associate the newly installed app with the right system and device). A device of type Mobile phone refers to a specific app installation on a phone. If the user uninstalls the app and later reinstalls it on the same phone, a new device with a new registration code needs to be created.

A user can have one or more devices, e.g. a card and a phone or two cards. All devices belonging to the same user will inherit the access rights for that user. A device can only belong to one user at a time, but it is possible to reassign a device to a different user.

It is optional to enter a description for a device. This field is only for the administrator's benefit.

Events

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

Events based on PIN only credentials cannot always be attributed to an individual user. This is because there is no guarantee that the PIN is unique (several users could have the same PIN). If the user's PIN is indeed unique, the system will display the user's name in the event log. If not, no user will be displayed in the event log.

Policies

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

• one or more doors
• a schedule
• a credential

The supported credential types are:

• card only
• card + PIN
• PIN only
• remote (the Telcred app)

Schedules

Schedules are used to:

• Control when a door should be single locked, double locked or unlocked
• Specify when a policy 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.

Doors & door groups

There are a few parameters to set when creating a new door:

• Name. Should be something meaningful to the administrator (and possibly the end users if they have the Telcred Entry app)
• Description. Optional
• Access time. This is the time the lock stays unlocked after a credential has been accepted by the reader
• Open too long time. After this time the alert Door left open will be generated
• Pre-alarm time. The number of seconds before Open too long time that the reader will warn the user to close the door
• Unlock. The door will be unlocked according to a schedule (e.g. weekdays between 09.00 and 17.00). If the door has two locks, both will be unlocked
• Unlock lock 2 only. Allows to unlock only the second lock according to a schedule (typically a night lock / motor lock)

Door groups are collections of doors. The purpose of door groups is to make it easy to create access rights for groups of doors, without having to list all the individual doors. For example, door groups could express type of room/door, security level, geographical area or something else.

Controllers

The first parameters to set for a new controller are time zone, connection mode, if a hub will be used, and which door(s) are connected to the controller.

Connection mode can be O3C or direct. O3C stands for One-Click-Connection-Component and is a technology developed by Axis Communications that allows the door controller to connect to a cloud service in a secure way, without any need for setting up port forwarding and that is accepted by most firewalls. After connecting the reader and other peripherals, the installer pushes a button on the door controller which then contacts first an Axis server to get a certificate, and immediately after that connects to the Telcred service.

Two numbers are needed for O3C to work: the door controller's serial number and OAK (Owner Authentication Key). The serial number is printed on the door controller itself and the OAK is provided on a piece of paper in the box it is shipped in. If the connection mode is direct, the Telcred service will contact the door controller, as opposed to the other way round. For this connection mode, it is necessary to specify the IP-address and port of the door controller (and it is also necessary to configure the local firewall or router to allow this traffic to pass through).

A hub refers to a device necessary to communicate with Assa Aperio wireless locks. If Assa Aperio is not part of the installation, no hub should be configured.

The door(s) connected to the controller are created using the 'Doors' tab. In other words, it makes sense to create the door first before setting up the controller.

Then there are a number of settings that have to do with the peripherals connected to the door controller:

• Door monitor
• Lock configuration and behaviour if power is lost (fail secure or fail safe)
• Reader(s)
• REX-button(s) (Request to EXit)

A detailed description of all the controller settings can be found here.

Guides & tutorials

Connect an Axis A1001 controller with O3C

To connect an Axis A1001 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 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 Waiting for controller to connect. 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.

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 configured and connected to the controller, you are ready to start defining and testing the actual access. The 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 schedule
4. Create a policy
5. Create a role or assignment linking the user to the policy

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

Change log

As with many other cloud services, new features and improvements to Telcred Access Manager are being deployed continuously. If you are interested in seeing the latest changes, you can find them here.

API documentation

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

• 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.