Skip to main content

Case studies

Pluggoo​

Pluggoo is an AI powered web application helping students to learn vocabularies in different languages. Typically, flow:

  1. Teacher create a homework with words the students should learn
  2. The student can read their homeworks and practice on the words

Pluggoo can also be used privately - a parent or student could set their own Pluggoo community and manage the homeworks themselves.

The Pluggoo app stores all data using Akkess actors and nodes only.

Roles​

  • SYSTEM_ADMIN
  • COMMUNITY_ADMIN
  • GROUP_ADMIN
  • STUDENT

Node types​

  • COMMUNITY (represents typically a school or family)
  • GROUP (represents typically a school class)
  • VOCABULARY

Screenshot​

Pluggoo

Lokk​

Lokk is a show-case application emulating a wireless lock product where end users may interact with the lock to lock and unlock it. An owner of a lock may associate it with a building and also to grant access to technicians. Additionally, the systems support factories that manufacture the locks and make them available pairing.

Live demo​

To view the lokk application you can navigate to the lokk demo portal.

Lokk

Scenario​

In this pre-cooked scenario, we have an user that has a single building and a lock associated with it. You sign in as the user to interact with your lock and see its status. In the second section you are signed in as the lock itself to see the last received signals and update the lock status.

This scenario show case the typical interactions and also how the fine-grained access control is applied to give different roles access to different parts of the system. See the lokk role configuration section below for full details of the roles and their access rights. Please view your network tab in the browser to see the interactions made with the Lokk & Akkess services.

Authentication of the owner and the lock is made using the basic identity provider service and its credentials are exposed in the application itself. These credentials are only used for this demonstration and they have limited access to the system.

Key usages of the Akkess toolbox​

  • Fine-grained access control is applied to give different roles access to different parts of the system
    • Owners can only access their own locks and buildings
    • Technicians can only access locks in buildings they are assigned to and with limited access to the lock data
  • Relies entirely on Akkess for data storage using actor and node services
  • Lokk backend for frontend service is used to proxy all calls to Akkess services
    • Ensures that business logic is enforced and that only expected interactions are made
    • The application firewall ensures that no malicious interactions are made on the actor and node services

Components​

The lokk application is composed by a portal and a backend service using typescript and react. These are containerized and deployed as separate components using node and nginx. These in turn interact with Akkess IAM services. The image below demonstrates these components and also the roles in the system.

Interactions​

The tabs below illustrate some of the typical use cases and interactions in the lokk application.

Actor and node configuration​

Actor types​

  • LOCK
  • USER
  • FACTORY
  • SERVICE_ACCOUNT

Node types​

  • ROOT
  • FACTORY
  • OWNER_ROOT
  • HOUSE
  • TECHNICIAN_ROOT

Role configuration​

The following roles are used in the lokk application:

  • LOCK
  • OWNER
  • USER
  • TECHNICIAN
  • SERVICE_FACTORY
  • SERVICE_ACCOUNT

Most of them have their data access limited to their respective associated nodes, while the SERVICE_ACCOUNT role have privileged access to enable claiming of locks on behalf of an owner.

Full example of lokk role configuration can be found here: Lokk role configuration

Identity provider configuration​

The lokk application relies on the basic identity provider to authenticate end users. This is a simple identity provider that only supports username and password authentication and is only used for testing and demonstration purposes.

Firewall configuration​

In the lokk application; none of the calls are made directly to the actor or node service. Instead, all needed interactions are proxied via the lokk backend service which will append a valid firewall authorization key. This ensures that only expected interactions are made on the respective actor and node endpoints and that their respective lokk application data is not manipulated in an unexpected way.

This firewall authorization key is only known to the administrator of the lokk application and is injected into the lokk backend service during deployment.

Tenant setup​

A single tenant is used for the lokk application. Different end users / owners are separated by their respective association their respective owner node. Locks are registered in the system by the factory and can be claimed by any owner as long as they know the lock serial number.

Copyright © 2019 Akkess