Tabs: Difference between revisions
Telcredstaff (talk | contribs) (Created page with "=== Start === After succesful login, the administrator is presented with a start page showing: * Latest alerts * Latest events * Offline doors * Statistics on number of door...") |
Telcredstaff (talk | contribs) |
||
| (20 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Start == |
|||
After succesful login, the administrator is presented with a start page showing: |
After succesful login, the administrator is presented with a start page showing: |
||
| Line 5: | Line 5: | ||
* Latest events |
* Latest events |
||
* Offline doors |
* Offline doors |
||
* Statistics on number of doors, users, devices, etc. |
* Statistics on number of doors, users, devices, etc. |
||
[[File:dashboard.png|Dashboard]] |
[[File:dashboard.png|Dashboard]] |
||
== Roles == |
|||
''Roles'' is one of two ways to |
''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]]. |
More information about roles can be found [[Roles|here]]. |
||
== Assignments == |
|||
''Assignments'' are identical to roles, but have a different purpose: temporary access rights. |
''Assignments'' are identical to roles, but have a different purpose: temporary access rights. Organizations that often need to create temporary access rights for users can use assignments for this, thereby keeping the list of roles short and tidy. |
||
By using assignments for temporary access, the list of roles can be kept short and stable over time. |
|||
More information about assignments can be found [[Assignments|here]]. |
More information about assignments can be found [[Assignments|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. |
|||
''Coming soon''. |
|||
More information about visits can be found [[Visits|here]]. |
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. |
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. |
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. |
||
| Line 44: | Line 46: | ||
More information about users can be found [[Users|here]]. |
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''. |
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. |
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. |
|||
More information about devices can be found [[Devices|here]]. |
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 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. |
||
| Line 62: | Line 62: | ||
More information about events can be found [[Events|here]]. |
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 both, when certain events occur. It is possible to specify which types of events that should trigger a notification, and also when notifications should be generated (e.g. only outside office hours). |
|||
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: |
Policies express access rights, i.e. the right to open one or more doors. A policy is defined by a combination of: |
||
| Line 77: | Line 83: | ||
More information about policies can be found [[Policies|here]]. |
More information about policies can be found [[Policies|here]]. |
||
== Schedules == |
|||
Schedules are used to: |
Schedules are used to: |
||
| Line 89: | Line 95: | ||
More information about schedules can be found [[Schedules|here]]. |
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: |
|||
There are a few parameters to set when creating a new door: |
|||
* Grant access |
|||
* Manually unlock |
|||
* ''Name''. Should be something meaningful to the administrator (and possibly the end users if they have the ''Telcred Entry'' app) |
|||
* Manually lock |
|||
* ''Description''. Optional |
|||
* Return to schedule |
|||
* ''Access time''. This is the time the lock stays unlocked after a credential has been accepted by the reader |
|||
* ''Open too long alarm''. After this time the alert ''Door left open'' will be generated |
|||
* ''Pre-alarm''. 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) |
|||
More information about doors can be found [[Doors|here]]. |
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'' 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]]. |
More information about door groups can be found [[Door_groups|here]]. |
||
== 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. |
|||
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. |
|||
Then there are a number of settings that have to do with the peripherals connected to the door controller: |
|||
Typically, the controller settings will be done by the installer / integrator and not by the end customer administrator. |
|||
* Door monitor |
|||
* Lock configuration and behaviour if power is lost (fail secure or fail safe) |
|||
* Reader(s) |
|||
* REX-button(s) (Request to EXit) |
|||
More information about controllers can be found [[ |
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. |
|||
''Coming soon''. |
|||
More information about hubs can be found [[Hubs|here]]. |
More information about hubs can be found [[Hubs|here]]. |
||
Latest revision as of 16:33, 4 July 2019
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 here.
Assignments
Assignments are identical to roles, but have a different purpose: temporary access rights. Organizations that often need to create temporary access rights for users can use assignments for this, thereby keeping the list of roles short and tidy.
More information about assignments 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) 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 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 delegation.
More information about users can be found 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 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 here.
Notifications
An administrator can setup a Notification in order to get an email, an SMS, or both, when certain events occur. It is possible to specify which types of events that should trigger a notification, and also when notifications should be generated (e.g. only outside office hours).
More information about notifications can be found 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 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 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 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 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.