Telcred documentation - User contributions [en]

File:Entry usage.png

2022-12-14T20:57:47Z

Admin: Admin uploaded a new version of File:Entry usage.png

2022-12-14T20:37:20Z

Admin:

Telcred Personal

2022-12-14T20:36:46Z

Admin: /* Open doors */

Telcred Personal is an app that allows users to open doors from their smartphone. The app is available for both iOS and Android. In order to use Telcred Personal to open doors, the user must have been configured with [[Users|mobile access]] and a [[Privileges|privilege]] with credential ''Remote''.

== Installing and registering the app ==

When starting the app for the first time, after download and installation, it will ask for the registered email. This email address is entered on the [[Users|user]] page by the administrator.

If, on the [[Users|user page]], a matching email address has been entered and the field 'Mobile access' has been set to 'Yes', a security code will be emailed to the user. The user will be prompted by the app to enter this security code, which only has to be done the first time the user starts the app.

== Using the app ==

=== Open doors ===

After successful registration, the app will display a list of doors currently accessible to the user. In order for a door to show up here, it must be included in a [[Privileges|privilege]] with credential type ''Remote'' that the user has access to through a [[Roles|role]]. To open a door, slide it to the right and press the 'access' button.

[[File:Entry_usage.png|400px|Telcred Personal access from door list]]

It is also possible to first click the door name, which will bring up the detail page for the door, and then slide and press the access button on that page.

It goes without saying that in order to open a door with Telcred Personal, its controller needs to be online (as opposed to cards which are stored locally on the controller and work even if the controller is temporarily offline).

=== Favorites and custom names ===

From the door detail page, it is possible to mark a door as favorite by clicking the little stars. Favorites are displayed at the top of the list of doors. On the same page it is also possible to give the door a custom name, which may be more useful to the app user. To enter a custom name: click the "edit" symbol on the door detail page.

=== Trigger commands ===

Users can also use Telcred Personal to [[Commands and triggers|trigger commands]]. In Telcred Personal these are called ''Actions''. The administrator can define triggers for commands as either ''remote by overview'' or ''remote by door''. The first type should be used for commands where it is not relevant to consider a specific door, and are available by clicking the ''Actions'' tab next to the list of doors. Slide the name of the action to the right to reveal a 'Perform' button and click it.

Triggers defined as ''remote by door'' should be used for commands where it ''is'' relevant to consider a specific door. They are available by first clicking the door name, which brings up a detail page for that door.

Telcred Personal

2022-12-14T20:36:17Z

Admin: /* Open doors */

Telcred Personal is an app that allows users to open doors from their smartphone. The app is available for both iOS and Android. In order to use Telcred Personal to open doors, the user must have been configured with [[Users|mobile access]] and a [[Privileges|privilege]] with credential ''Remote''.

== Installing and registering the app ==

When starting the app for the first time, after download and installation, it will ask for the registered email. This email address is entered on the [[Users|user]] page by the administrator.

If, on the [[Users|user page]], a matching email address has been entered and the field 'Mobile access' has been set to 'Yes', a security code will be emailed to the user. The user will be prompted by the app to enter this security code, which only has to be done the first time the user starts the app.

== Using the app ==

=== Open doors ===

After successful registration, the app will display a list of doors currently accessible to the user. In order for a door to show up here, it must be included in a [[Privileges|privilege]] with credential type ''Remote'' that the user has access to through a [[Roles|role]]. To open a door, slide it to the right and press the 'access' button.

[[File:Entry_usage.png|Telcred Personal access from door list|400px]]

It is also possible to first click the door name, which will bring up the detail page for the door, and then slide and press the access button on that page.

It goes without saying that in order to open a door with Telcred Personal, its controller needs to be online (as opposed to cards which are stored locally on the controller and work even if the controller is temporarily offline).

=== Favorites and custom names ===

From the door detail page, it is possible to mark a door as favorite by clicking the little stars. Favorites are displayed at the top of the list of doors. On the same page it is also possible to give the door a custom name, which may be more useful to the app user. To enter a custom name: click the "edit" symbol on the door detail page.

=== Trigger commands ===

Users can also use Telcred Personal to [[Commands and triggers|trigger commands]]. In Telcred Personal these are called ''Actions''. The administrator can define triggers for commands as either ''remote by overview'' or ''remote by door''. The first type should be used for commands where it is not relevant to consider a specific door, and are available by clicking the ''Actions'' tab next to the list of doors. Slide the name of the action to the right to reveal a 'Perform' button and click it.

Triggers defined as ''remote by door'' should be used for commands where it ''is'' relevant to consider a specific door. They are available by first clicking the door name, which brings up a detail page for that door.

File:Entry usage.png

2022-12-14T20:33:40Z

Admin: Admin uploaded a new version of File:Entry usage.png

2022-12-14T20:21:34Z

Admin: Admin uploaded a new version of File:Accessible-to-user.png

File:Accessible-user.png

2022-12-14T20:20:00Z

Admin: Admin uploaded a new version of File:Accessible-user.png

Validating access

2022-12-14T20:14:44Z

Admin:

After setting up schedules, privileges, and roles it may be useful to check that the desired result has been achieved. Telcred Access manager allows the administrator to check the permissions for either a [[Users|user]], [[Cards|card]], or [[Doors|door]]. Click the link at the bottom of the page to check the permissions:

[[File:Accessible-user.png|border|Accessible to user link]]

This takes you to a page where for users and devices, you can see which doors can be accessed and how:

[[File:Accessible-to-user.png|Accessible to user]]

For doors, instead, the page shows which users have access to the door:

[[File:Access-to-door.png|Access to door]]

In the top-right part of the page, it is possible to choose for which point in time the information should be displayed, and the level of detail (e.g. the roles and privileges which provide access):

[[File:Access-settings.png|Access settings]]

Cards

2022-12-14T20:12:49Z

Admin: /* Card fields */

Cards refers to both actual cards and keyfobs.

== Adding a card ==

A common way to add a new card to the system is to first touch it to a connected reader. Then select [[Events]] in the Monitoring section of the menu. An unknown device should appear at the top of the list with a link to add it (it can take a few seconds before the event shows up). Click the link to add the information for the new card.

== Card fields ==
The fields for a card are:

* ''Name''. The only mandatory field
* ''Notes''. Optional and for information only
* ''Identified by''. Can be 'Raw bits' or 'Number'. Raw bits is the default and means that the card is identified by all the bits that the reader receives from the card. If Raw bits is chosen, the ''Card ID'' needs to be entered with hexadecimal notation (this is done automatically if the process for adding a card above is followed). We recommend to always use Raw bits, which is exactly what the card reader sends to the controller. If the reader model does some pre-processing of the card identity, it can sometimes work to use 'Number' instead
* ''Card ID''. The ID of the card in either hexadecimal or decimal notation (see above)
* ''User''. A card can only belong to one user at the time, but it is possible to reassign it from one user to another. The card can be assigned to a user in this screen or it can be done in the [[Users]] screen.
* ''Active''. It is possible to set a date range for when the card should be active
* ''Blocked''. A card which has been lost can be blocked. In this case it will not be able to open doors. If the card is found again it can simply be unblocked

At the bottom of the page, there is a link that lets you [[Validating access|check the access rights for the card]].

Cards

2022-12-14T20:11:56Z

Admin: /* Card fields */

Cards refers to both actual cards and keyfobs.

== Adding a card ==

A common way to add a new card to the system is to first touch it to a connected reader. Then select [[Events]] in the Monitoring section of the menu. An unknown device should appear at the top of the list with a link to add it (it can take a few seconds before the event shows up). Click the link to add the information for the new card.

== Card fields ==
The fields for a card are:

* ''Name''. The only mandatory field
* ''Notes''. Optional and for information only
* ''Identified by''. Can be 'Raw bits' or 'Number'. Raw bits is the default and means that the card is identified by all the bits that the reader receives from the card. If Raw bits is chosen, the ''Card ID'' needs to be entered with hexadecimal notation (this is done automatically if the process for adding a card above is followed). We recommend to always use Raw bits, which is exactly what the card reader sends to the controller. If the reader model does some pre-processing of the card identity, it can sometimes work to use 'Number' instead
* ''Card ID''. The ID of the card in either hexadecimal or decimal notation (see above)
* ''User''. A card can only belong to one user at the time, but it is possible to reassign it from one user to another. The card can be assigned to a user in this screen or it can be done in the [[User]] screen.
* ''Active''. It is possible to set a date range for when the card should be active
* ''Blocked''. A card which has been lost can be blocked. In this case it will not be able to open doors. If the card is found again it can simply be unblocked

At the bottom of the page, there is a link that lets you [[Validating access|check the access rights for the card]].

Admin: /* Devices */

== 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 the [https://www.axis.com/se/sv/products/axis-a1001 A1001 Network Door Controller], and [https://www.axis.com/products/axis-a1601 A1601 Network Door Controller] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ 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|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 [[Visits|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 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 his/her own area of the building. Delegation is managed through a separate web interface: [[Site 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 the Telcred Entry app 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 five main components:
* Cloud-based server software
* Web-based GUI for installers and end customers
* Smartphone apps for end users (iOS and Android)
* API for communicating with IP door controllers
* API for integration with 3rd party software

[[File:telcred_components.png|Telcred system components]]

Currently, The Telcred solution works with the A1001 and A1601 Network Door Controllers from Axis Communications. One controller can manage one or two doors with electrical locks, alternatively:
* one door with electrical locks and up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* one door with electrical locks and up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the A1001 and A1601 door controllers, it is also possible to use the [https://www.axis.com/products/axis-a91-series|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).

== Account structure and delegation ==

''Delegation'' is a powerful feature in Telcred Access Manager. Below follows a short introduction. More information about delegation can be found [[Delegation|here]].

=== Systems, organizations, officers, and capacities ===

A Telcred customer account is referred to as a ''system''. For any system, an arbitrary amount of ''organizations'' can be created. Each organization has its own users, access rights, cards, events, and doors, which can be seen only by the administrator(s) of that organization.

[[File:delegation.png|System and organizations]]

The purpose of having multiple organizations in a system is ''delegation'', i.e. to let administrators with direct knowledge of, and responsibility for, their users users perform the administration without relying on a centralized 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 relying on the building's owner.

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. The capacities are:

* System owner
* Organization owner
* Administrator

An officer can simultaneously have many capacities and also in many organizations.

=== Sharing doors and access rights with other organizations ===

It is possible to ''share'' doors and access rights between organizations (no data is ever shared between systems).

[[File:sharing.png|Sharing between organizations]]

The purpose of sharing doors and 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 common doors, e.g. the entrance door from the street.

== 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
* remote (the Telcred app)
* 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.

[[File:ac_model.png|Access Control model]]

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.

== Introduction to the administrator GUI ==

The administrator 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:

* System name
* Current organization
* Logged in officer

[[File:login-context.png|Login context]]

If the system has more than one organization (see the section on [[Delegation|delegation]]), and the officer has administration rights in more than one of the organizations, it is possible to switch organizations by expanding the menu right next to the current organization.

[[File:change-org.png|Change organization]]

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

[[File:officer-settings.png|Officer settings]]

More information about the officer settings can be found [[Officer settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|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 [[Validating access|here]].
* [[Main Page#Actions|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".
* [[Main Page#Configuration|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.

[[File:list-page.png|List page]]

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.

[[File:detail-page.png|Detail page]]

== 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 [[Events|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 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. Reference 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 organization owner (see the section on [[Main Page#Delegation|delegation]]).

More information about users can be found [[Users|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 [[Devices|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 [[Doors|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 [[Schedules|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 [[Visits|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 [[Keys|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 [[Roles|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
* a schedule
* a credential

The supported credential types are:
* card only
* card + PIN
* PIN only
* remote (the Telcred app)
* API 1
* API 2

More information about privileges can be found [[Privileges|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 [[Door_groups|here]].

=== Actions ===

==== 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 [[Triggers|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 [[Recipients|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 [[Triggers|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 [[Commands|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. From the door config it is also possible to ''transfer'' the door to another organization, as described in the section on [[Delegation]].

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 [[Door configs|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 [[Controllers|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 [[Hubs|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 in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# 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:

[[File:control_button.png|Control button]]

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 [[A1001 settings#Connection_settings|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 configs|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):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|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 [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

File:Detail-page.png

2022-12-14T18:35:51Z

Admin: Admin uploaded a new version of File:Detail-page.png

File:List-page.png

2022-12-14T18:33:31Z

Admin: Admin uploaded a new version of File:List-page.png

File:Login-context.png

2022-12-14T18:27:07Z

Admin: Admin uploaded a new version of File:Login-context.png

File:Notifications.png

2019-02-25T13:48:34Z

Admin: Admin uploaded a new version of File:Notifications.png

Main Page

2019-02-22T13:27:59Z

Admin: /* Notifications */

== 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, specifically the [https://www.axis.com/se/sv/products/axis-a1001 A1001 Network Door Controller] and [https://www.axis.com/products/axis-a1601 A1601 Network Door Controller] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ 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
* 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 one door in 10 different locations. 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 will then automatically download the connection settings from an Axis server and immediately use them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Entry|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. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|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 some use cases this is an acceptable tradeoff 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 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.

=== 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 on the controllers. 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 use strong encryption and the communication between the Telcred Entry app 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 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

[[File:telcred_components.png|Telcred system components]]

Currently, The Telcred solution works with the A1001 and A1601 Network Door Controllers from Axis Communications. One controller can manage one or two doors with electrical locks, alternatively:
* one door with electrical locks and up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* one door with electrical locks and up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

== Account structure and delegation ==

''Delegation'' is a powerful feature in Telcred Access Manager. Below follows a short introduction. More information about delegation can be found [[Delegation|here]].

=== Systems, organizations, officers and capacities ===

A Telcred customer account is referred to as a ''system''. For any system, an arbitrary amount of ''organizations'' can be created. Each organization has its own users, access rights, cards, events, and doors, which can be seen only by the administrator(s) of that organization.

[[File:delegation.png|System and organizations]]

The purpose of having multiple organizations in a system is ''delegation'', i.e. to let administrators with direct knowledge of, and responsibility for, their users users perform the administration without relying on a centralized 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 relying on the buliding's owner.

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. The capacities are:

* System owner
* Organization owner
* Administrator

An officer can simultaneously have many capacities and also in many organizations.

=== Sharing access rights and users with other organizations ===

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

[[File:sharing.png|Sharing between organizations]]

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.

== 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 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 policy are:

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

[[File:ac_model.png|Access Control model]]

In all cases 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.

== Administrator GUI ==

=== Structure ===

The administrator GUI is web-based and available at:

https://access.telcred.com

After succesful login, the administrator is presented with a start page showing:
* Latest alerts
* Latest events
* Offline doors
* Statistics on number of doors, users, devices, etc.

[[File:dashboard.png|Dashboard]]

The administrator GUI is organized in a number of tabs accessible from the main menu at the top of the screen. Most tabs display a list of entities, e.g. doors. From the list page it is possible to click an individual entity to get more information about it or to edit it.

[[File:Door_list_page.png|Door list page]]

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

[[File:door_detail_page.png|Door detail page]]

=== Main menu tabs ===

==== Start ====

After succesful login, the administrator is presented with a start page showing:
* Latest alerts
* Latest events
* Offline doors
* Statistics on number of doors, users, devices, etc.

==== Roles ====

''Roles'' is one of two ways to give 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.

More information about roles can be found [[Roles|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) that 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.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL can open the door, and it is not possible to know the identity of the actual person who did the opening. On the other hand the access buttons are only visible and possible to use during the time of the visit.

More information about visits can be found [[Visits|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. 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 [[Main Page#Delegation|delegation]].

More information about users can be found [[Users|here]].

==== Devices ====

A device must have a name and a type. Currently, two types of devices are supported: ''Card with ID'' and ''Mobile phone''. The latter refers to the [[Telcred Entry]] app, which is available for both iOS and Android.

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.

More information about devices can be found [[Devices|here]].

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

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.

More information about events can be found [[Events|here]].

==== Notifications ====

An administrator can setup a ''Notification'' in order to get an email, an SMS, or a "webhook" (http request), when certain events occur. It is possible to specify which types of events that should trigger a notification, and when notifications should be generated (e.g. only outside office hours). It is also possible to filter trigger events on e.g. door, user, and method.

More information about notifications can be found [[Notifications|here]].

==== 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)

More information about policies can be found [[Policies|here]].

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

More information about schedules can be found [[Schedules|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
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create policies / 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 [[Door_groups|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 [[A1001_settings|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 [[Hubs|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:

# Select ''Controllers'' in the main menu and click ''Add new'
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# 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 [[A1001 settings#Connection_settings|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):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Schedules|schedule]]
# Create a [[Policies|policy]]
# Create a [[Roles|role]] or [[Assignments|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 ==

=== 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 [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].