inWebo Local Authorization (IWLA)
|Although accessing an online application – such as an account on Office 365, an account on a healthcare provider portal, a mobile banking account… – and accessing a local ‘resource’ – such as a car, a server, a hotel room, a computer, a museum, a train… – happen increasingly through Apps and look quite the same to users, granting authorization to the former is done by verifying the identity of the user requesting the access, whereas granting authorization to the latter is done by verifying the claims that the user is carrying, such as a ticket, a badge, or a key. inWebo has expanded its access security framework, which now covers both the former use cases with multi-factor authentication, and the latter use cases with local authorization.|
Besides the type of verification – identity vs. claims -, the location where the verification takes place is a fundamental reason for providing distinct solutions for MFA and for local authorization. When accessing an application, the identity verification is done by an authentication system, which is a service or a server hosted with the application or in the cloud. In contrast, most local resources can’t maintain or guarantee a permanent connectivity to a central authorization system, therefore they must be able to verify claims and grant access locally and anonymously – a lock shouldn’t need to call a server to verify your name when you turn the right key into it.
inWebo Local Authorization (IWLA) framework consists of the following components:
- An API: it is used to issue, monitor, or revoke smart locks and virtual keys. The whole operation happens in FIPS-certified security appliances (HSMs) and the result is encrypted end-to-end from our HSMs to the user smartphone (for a virtual key), or to the local resource (for a smart lock). Besides, both locks and keys are issued on demand, only once. You can therefore be certain that no one can steal a “database” of locks or keys in your servers and get free access to all the local resources (objects) that you manage.
- A library for access devices: it is used to issue and manage secure access requests to a local resource, on behalf of a user. That library needs to be integrated with the mobile App that you provide users with.
- A library for local resources (objects): it is used to verify access requests. That library needs to be integrated with the environment of the local resource.
The IWLA framework can be used to issue a virtual key for a specific smart lock. The virtual key can be verified by the smart lock locally – without connectivity to a central authorization server – and, most importantly, without being exposed. In addition to a virtual key, the smart lock can verify the integrity of the claims attached to the virtual key, such as a time and day, a duration, etc. Finally, granting the authorization can be conditioned to an explicit validation by the holder of the key, or even to an identification of the holder of the virtual key, thus further protecting the virtual key.
How to get IWLA
The best way would be to schedule a demo and to discuss it with our experts.