Inlet's ecosystem:
Inlet's lock service is the core that enables a complete digital customer journey. To handle this, we connect vital components such as ordering, payment, access, communication, and control systems, collectively referred to as the Inlet Ecosystem. These modules together facilitate a frictionless customer journey and a comprehensive solution for customers.
Inlet is "access control-/lock system" agnostic:
Inlet has the opportunity to talk to a wide range of lock systems and can combine functionality from multiple solutions into a single one, given that the lock systems supports it. We can assign same code between systems, and also give different keys based on a wide range of user journeys.
How inlet is talking to the locks:
Inlet need some spesific information to talk to the lock system, API access, and whitelisted IP address and port. This strenghtens the security greatly, and also gives Inlet the possibility to fetch status from a wide range of lock systems, to tie it together in a single user interface.
Booking:
On the left side of the diagram is the booking/ordering of an object. We have several partners, ranging from SMS or QR code booking to complete PMS solutions for hotels or recurring booking of activity venues. There is a wide range of booking needs and corresponding booking agents and providers. We have partnerships with several to offer the best booking solution for end customers.
API:
Our API is based on Laravel's standardized and tested security methods (Laravel Security). We use a session-based API token linked to a customer and one or more IP addresses. This means an API token can only be used by an entity from a given IP address. All communication is based on HTTPS with SSL certificates issued by LetsEncrypt and managed in Azure by Microsoft. The API is behind an Azure gateway, enhancing security against DDoS and other types of attacks.
Azure:
All parts of Inlet are hosted in the cloud. This allows our services to communicate quickly and move freely between each other, as Azure and security layers ensure robust shell protection, allowing our internal work to proceed without delays from constant encryptions and security analyses with 100% control over all internal components.
Despite this, we design the internal parts with good security and logging, in separate silos, to prevent a potential error in one place from spreading to other parts of the application. We use Docker for this purpose, ensuring backup, automatic deployment of new versions with testing, and easy rollback if something goes wrong. For more in-depth information, you can read an article about Docker and security here: https://docs.docker.com/engine/security/
"Docker containers are, by default, quite secure; especially if you run your processes as non-privileged users inside the container." - docker.com
Locks Connector:
On the right side of the diagram, you can see how Inlet will connect to different locks. The principle is the same for all lock systems. We use the security mechanisms defined by IT and lock providers to connect to the server, often an IP address and a specific port. We recommend SSL traffic where supported by the server. The IT provider should have a firewall whitelisting IP addresses to our production facility.
Additionally, we need a username and password to connect to the lock program that controls the locks, whether in the cloud or installed on a server at the customer's site. Passwords here should be difficult to guess, and we recommend a minimum of 12 characters with a mix of letters, numbers, and symbols. (More details in Security Recommendations)
Portal Dashboard:
We have a basic dashboard that allows us to monitor locations, locks, and the status of the locks. This provides us with good control over what is happening at the lock level, allowing us to issue alerts if we detect unusual behavior or other unauthorized use.