-
Accessing the application
-
Application security
-
Devices and communication protocol
-
Application access control levels
-
Employees, departments and device users
-
Time & Attendance Functionality
-
Access control
-
Batches & payroll integration
-
Binary City Time API (Application Programming Interface)
-
Binary City Time integration with BioTime Technical Documentation
User security
Importing branch(es) into BC Time
BC Time includes an import feature that allows users to upload multiple branches into the system at once. Once imported, branches become available for selection and can be linked to employee profiles.
As branches are required when creating employee records in BC Time, this functionality provides a faster and more efficient alternative when managing a large number of branches. Rather than adding each individually, users can import them in bulk, reducing administrative effort.
Step 1: Navigate to the branch(es) menu in BC Time.

Step 2: Once in the branch menu, click the meatballs (3 dots ) to access import option.

Step 3: Once you've clicked the "Import" option, the below window will appear, which will allow the user to "download the list of cities" currently available in BC Time as well as download the template that will be populated with the required branches.

The sheet with the list of cities will download, with the following information which will be used in the template; city ID (primary key), Country, Province, Name, Time zone.

Step 4: Once you've downloaded the template, use the information in the cities sheet to update the template with your required branch name and ID (PK). The template below shows the unique cities in Namibia with their respective ID's.

Step 5: Download the template as a csv. file as shown in the image below.

Step 6: Upload the downloaded template, by choosing the file from your saved location.

Step 7: Click Upload data, and the system will validate the data in the template and ready it for import once validation is successful. Click "Import now".

Step 8: Upon successful import, all the branches will then be created in BC Time, with their correct name and city.

For clients using Geofencing, the template allows for the population of the Geofence ID(s), to ensure that the created branches are linked to their required geofence area (if applicable). Step 4 above showed that we had the geofence id for Windhoek and Swakopmund on the sheet, thus when the import was done, these two branches had their geofence areas linked.


User security
Binary City Time is password protected, therefore you will need to be an existing user with a known username and password, to gain access to the service. When logging in, it will be necessary to enter both you email address (which will act as your username) as well as your password.
As an additional layer of security, 2-step authentication is required to access the system. Once you've logged in with a known username and password, the system will email the user a unique 6 digit code, which is needed to gain access to the application.
A password policy is automatically applied to all clients and can be configured with the following options:
Minimum password length
This setting determines the minimum number of characters a password should contain.
The default value is 8.
For example, if the Minimum Password Length is set to 6, then the password must contain at least 6 characters.
Minimum Password age
This setting determines the minimum number of days a password must be in use, before it can be changed. Only when the minimum password age expires, users are allowed to change their password. It ensures that users don't change their password too often. The value can be set between 0 (disabled) and 720 days.
The default value is 1.
For example, if the Minimum Password Age is set to 10, then the user cannot changed his/her password for 10 days after the last password change.
This setting is used to ensure the effectiveness of Enforce Password History setting. If the Minimum Password Age is set to 0 (disabled), then the user can change his/her password until the value set for Enforce Password History is reached and reuse his/her favorite old password. By setting the Minimum Password Age to a certain value, a user cannot change his/her password often enough to render the Enforce Password History setting ineffective.
The value for Minimum Password Age should always be less that the Maximum Password Age.
Maximum password age
This setting determines the maximum number of days a password can be used. Once the Maximum password age expires, users must change their password. It ensures that users don't stick with one password forever. The value can be set between 0 (disabled) and 720 days.
The default is 360.
For example, if the Maximum Password Age value is set to 60, then the user must change his/her password after every 60 days. If the value is set to Disabled, then the password never expires, and the user is not required to change his/her password ever.
Enforce password history
This setting determines the number of new passwords that have to be set, before an old password can be reused. It ensures that old passwords are not continuously by users which will render the Minimum Password Age policy setting useless.
The default value is 10.
For example, if the Enforce Password History value is set to 10, then the user must set 10 different passwords when the password expires, before setting his/her password to an old value.
If the value is set to Disabled, then the password history is not remembered and the user can reuse their old password when their password expires.
This setting determines whether the password must meet the complexity requirements specified. If this setting is enabled, passwords must meet the following requirements.
Not contain the user's account name or part of the user's full name that exceed two consecutive characters
The password contains characters from at least three of the following four categories:
English uppercase characters (A - Z)
English lowercase characters (a - z)
Base 10 digits (0 - 9)
Non-alphanumeric (For example: $, #, or %)
By default, this setting is disabled
We have built the following security module to ensure that credentials remain private.
On the client side (Browser and Local Area Network):
With private and public keys, using OpenSSL, HTML login form, data is encrypted before posted to server, and decrypted server-side, to ensure data is not compromised locally.
Server-side (Where Binary City Time is hosted):
Data is send/posted to an HTTPS connection (via secure port).
One way string-hashing, with a cost higher than 10.
Salt is generated by means of pseudo-random string of bytes, of length longer than 15.
After 4 failed attempted logins, an account is locked.
Only authenticated users with the required access, will be able to grant access to or load other users on Binary City Time.
Nenhum comentário até agora.