How to Build a Customer-Facing Portal with Formant IAM

In robotics, especially in end-user facing verticals like agriculture, there is a hypercritical need for an immediate return on investment. The focus needs to be on the business value to the customer and not just on the robots; customers need to be able to view, manage and understand the impact of robots to their user case and their business just like their other business assets. 

One of the ways to expose this information is to gather data from the robot and expose it to the end user as part of a web portal or app. In many cases, there are several layers to the hierarchy of users who might want to see this data.

Consider the following scenarios:

1. A large organization with multiple robotics divisions wants to use a unified system that their individual departments can leverage for their specific use cases. One department use case requires them to have a regional ops team to manage and operate the robot, while the other department specializes in selling their robots directly to the end user.
   
2. A robotics startup wants to expose an app to their customers with real-time location, videos and metrics displaying the number of grapes picked by the robot.
   
3. An OEM that manufactures robot arms wants to provide a software to the distributors so that the distributors can provide enhanced features and support to their customers.
   
4. An enterprise wants to automatically provision new devices using a server. For security reasons they only want the server have access to Formant device creation APIs

All these use cases have two things in common,

• Expose their robot’s data as part of a use case-specific application to a tier of customers. 
• Scope down access at different hierarchical levels

With Formant’s APIs and programmable webviews, robotics companies can already build a white labeled solution with minimal design and coding. With the launch of Formant IAM (Identity and Access Management), a hybrid RBAC-ABAC identity and access management system, we have provided a solution capable of enforcing rules based on groups or individual profiles and business environment parameters. 

Role-based access control (RBAC) is an access control mechanism defined around roles and privileges. Roles define access policies — authority to access specific Formant resources. Users who perform the same function for an organization are placed into groups by an administrator. Groups are then assigned a role.

Attributes-based access control (ABAC) is an authorization strategy that defines permissions based on attributes. In Formant, these attributes are called tags — which is a key:value pair. Using ABAC, the access can be further scoped down for a group of users or individual users to a set of entities within the resource.

Formant IAM comes with a set of default roles, such as Admin, Operator, and Viewer, that allow users to get started in simple steps. Complex use cases, such as the one listed above can be built using a combination of custom roles, teams and tags. 

Access policy mapping

At its core, resources expose a set of access policies that can be customized for each role. By default, Formant comes with a set of predefined roles that map each resource and its access to a role name. For example, by default, an administrator comes with all access to all resources.

Here is a list of resources in Formant and the access policies available for them:

Access to the resources can be scoped down further. For example, a user might have VIEW access to certain Visualizations, but also scoped to certain devices. This can be achieved by using tags on the resources and the users thereby limiting access to the specific resources that have the same tag as the user. Since tags can be applied programmatically or manually, it is simple to scale this access methodology as the devices or users scale.

In summary:

• Custom roles allow you to add a Role to the current list (Admin, Operator, Viewer, Customer) and define exactly which what level of access (read, write, execute) that role has for every resource (views, devices, users, comments, teleop, event, share, etc…).
• Tags allow you to customize what views and devices a user has access to. Any user other than an organization owner/administrator can have tags.
• Custom roles and tag restrictions can be assigned to specific users to restrict exactly what permissions they have for which entities, and which views/devices they can exercise their access on.

An example – building a Formant customer portal

In this example, an early-stage agricultural RaaS company wants to expose a custom portal to their customers. This custom portal would expose the health of the robot, progress of the task (percentage complete), live location and camera feeds along with a button to submit support tickets. They used Formant data modules to expose the health, progress, location and camera feed, and built a Custom View on Formant with the Zendesk web widget embedded directly on the View. Their goal was to expose this Custom View to their customer’s organization.

Here’s how you would go about setting roles and permissions to enable that customer portal:

1. Create custom roles. Create a user administrative role so that the customer’s admin can manage access to their users. Create any other custom roles that the customer might want to use.
   
   
2. Create the team that represents a specific customer. Create a team (e.g. customerName) with the above user admin role so that any new users added to this team will automatically inherit these tags.
3. Assign a new tag. Create a unique tag that will grant access to the users of this customer organization to the roles, teams, devices and specific Views.
4. Invite the customer admin. Create & invite the first customer user and add them to the team created above. This customer will only be able to access the custom UI View on the devices assigned to them. Since they were invited as an admin with privileges to invite users, they can now add/remove users from their organization. However, they cannot see any users outside their organization. The customer admin can also limit the privileges of their users. The highest role these users can get is what their admin inherited.  

For this customer, the custom portal provided a snapshot of what was happening in the field – where the robots are located, live camera views, basic task progress, for the specific group of robots related to the customers.

In addition to displaying the current state, it was critical for them to enable customer communication. As an early stage company, they knew that easy customer feedback and communication was essential to providing a good experience. For more information, please visit the Formant IAM documentation.

Next Steps

Currently, Formant supports single sign-on (SSO) with Google. Our next step is to enable integration with third-party identity management systems for expanded support of customer SSO environments.