Browse through the most common questions of our potential and existing customers or contact us so that we can provide you with the support you need.
PaaS in case of a cloud. On-premise in case of a private installation.
Users are identified by their unique email address.
Yes – Minimum 8 characters, must contain a mixture of uppercase, lowercase, and numerics.
This can be also configured system-wide.
By default, we lock out users after 10 failed attempts for 10 minutes. It can be configured on on-premise server.
Tokens are invalidated after 30 minutes of inactivity. After that time, the user must login again. The user will not be deleted.
If the user is coming from SSO, it won’t have a password.
If the user is created in Wallboard with an “empty” password, then the user must set a password via reset password form (details are sent via email).
When installing a new system, the default admin must change its password on the first login.
Yes.
We can force users to use SSO only.
With on-premise installation, we don’t have to store anything in the cloud.
With cloud installation, everything is stored in the cloud and the server is protected with best security practices.
Yes, with SSO.
We store admin and regular accounts in the same database table.
We don’t have guest accounts.
Yes, in system logs.
Docker container logs have a maximum file size (300MB) and once reached will be compressed, a maximum of 5 files will be kept and the
oldest overwritten.
Dependent on Server usage logs are generally kept for one month. The file size and count can be increased but is not user-configurable, therefore Wallboard will need to make the required changes.
These logs can be stored in an ELK stack which enables us to configure a longer time to store logs, depending on the storage space. We usually recommend 3 months.
The Wallboard application is designed as a 3-Tier Application:
- Backend as a server-side application that provides an API.
- Frontend UI is a web application that communicates with the server using that API.
- Client applications that are running on the player, communication with the server over an API.
- Displayer web application as a presentation layer running on the client applications also communicates over an API with client and server layers.
The database is not available directly from the internet, its port is not exposed to the internet and it is only available on the server’s localhost.
To connect from the outside requires an SSH connection with private key authentication.
We can customize this on an on-premise or dedicated cloud server installation.
All traffic is encrypted between the application server and all of the connectors/endpoints.
All traffic goes over HTTPS, the certificate is issued by Comodo or Let’s Encrypt.
We can customize this on an on-premise or dedicated cloud server installation.
By default, we have enabled TLSv1.0 as well to support IE 8-10.
SSL2/3 are disabled and TLS is enabled up-to v1.3. Client applications use the most secure version that is applicable on the client platform.
Enabled protocols can be customized on an on-premise or dedicated cloud server installation.
Sensitive data, like user details, device information are stored in a database that is not exposed to the internet.
By default, we don’t have data at rest encryption on the database. The database can be customized or can be provided by the customer on an on-premise or dedicated cloud server installation. Uploaded files are stored outside of the database and only available on a web-based API.
Open registration is not enabled, it is a private service. We only store user email, optional name, and phone number. The user can delete itself.
Retention policy cannot be configured. You must delete unused files and contents manually. Statistics, metrics, logs are deleted regularly.
Only the required content files are synced to the player application.
By deleting a customer, we delete all of the customer data and user information immediately except logs.
Traffic is logged within the NginxApplication access log. User logins, failed attempts, and actions are logged within Wallboard also.
Asset inventories are created project-by-project and updated whenever technology changes are made.
Client-Side Application: Wallboard tests and releases build on internal servers first and are usually deployed onto production servers within weeks.
Server-Side Application: Wallboard is continually monitoring, testing, and updating the software depending on specific vulnerability notifications of the technology used
As soon as we are aware of a new vulnerability, we do fix and deploy them as a server update as soon as possible.
Regular host machine updates can be a part of the contract.
Vulnerability scanning tools are currently run manually on a scheduled basis. Wallboard is looking to automate this process.
Supported protocols: SAML 2.0, OpenID Connect, LDAP.
Supported platforms(examples): Okta, Keycloak, Microsoft Cloud (with your own personal ms account), AD, ADFS, Google.
The application has a Test instance. Access has to be requested to the beta server.
Yes, with SAML2.0 if the IDP supports.
Application Vendor (Wallboard) has to configure it.