Published on 05/16/2017 | Technology
Every IoT system collects data, creates insights based on that data, and shares the data and insights with a variety of users and applications. The need to share the data with a variety of users – each with differing sets of privileges – is the driving force behind the requirement for Role Based Access Control (RBAC) capabilities within systems that expose IoT data to end users. Each Role in an RBAC system grants a user permission to create, retrieve, update, or archive certain data elements under specific circumstances.
Let’s look at a simplified example of an IoT application for managing IoT Buttons (ZipLine) for a better understanding of the underlying complexities of implementing RBAC in a connected industrial system.
ZIPLINE ROLE TYPES
ZipLine defines the following types of Roles that may be assigned to a given user.
ZIPLINE ROLE DESCRIPTIONS
Site Members are assigned to one or more Sites within an Organization. Site Members may view Button history, dashboards, and map views for the Sites in which they are assigned the Site Member role.
Organization Members are assigned to an Organization. Organization Members may view Button history, dashboards and map views for all Sites within the Organization. Organization Member is a shorthand way to grant access to all Sites, instead of making certain users Site Members at all Sites.
Organization Administrators have all of the capabilities of Organization Members and additional capabilities. The additional capabilities include: Registering Alert Notifications, Defining new Sites and Locations within those Sites, Defining Button Types and Events, Assigning Buttons to a Specific Location and Button Type, Adding Organization Members and Site Members assignments to Users, and Inviting Users to join their Organization.
Customer Support users are able to view data from all Organizations, but cannot change data in any of the Organizations. Customer Support can view individual button communication logs.
Replenishment users are able to see the Inventory Pages and view the Remaining Useful Life for buttons organized by Organization and Site.
Super Administrators have Organization Administrator privileges in all Organizations in the system, in addition to the ability to Create new Organizations and view Server logs.
IOT APPLICATION REQUIREMENTS FOR RBAC
Now that we’ve highlighted examples of different roles and the types of permissions each can have, let’s take a deeper dive into implementing RBAC in your IoT Application. In order to enable the scenarios described above, an IoT system must provide the following primary functions:
Role Authoring: The system must enable descriptions of the various data types and create mappings for the Create, Read, Update and Delete (CRUD) operations over that data. (Note: As a reminder, what users think of as Delete in a Strandz system is always really an Archive operation.) This mapping creates a set of potential permissions that are discoverable, assignable and enforceable. Additional permissions may be added at this stage for actions against systems integrated with the IoT application (An example in ZipLine would be the ability to generate and send a test email or SMS notification). These permissions are then grouped into logical groupings based on the types of users that may interact with the IoT application. The logical groupings of permissions are called Roles.
Role Assignment: Role Assignment is the act of stating that a specific, authorized user is granted a specific Role within a specific context, such as an Organization. These assignments are typically stored in a corporate directory like LDAP or communicated via SAML assertions. Strandz supports a wide range of methods for receiving Role Assignment information.
Access Control Enforcement: Once a User has been Authorized to login, the Role Assignments for that User are retrieved. The Server side of the Application must ensure that the user does not perform any actions requiring permissions that aren’t currently granted to the user.
Permissions Discovery: User interfaces often use a progressive disclosure pattern, where they only show a user sections of an application or website that they are authorized to interact with. This prevents user confusion and frustration. In order to understand what actions are permitted for a given user, a system needs the ability to inquire if the current user is permitted to perform a set of actions. The answer to this question enables the user interface code to decide whether or not to show a specific section of the interface to the user.
RBAC AS INFRASTRUCTURE
“Buy your infrastructure, don’t build it” has become a common refrain in modern computing, especially in the cloud. Bright Wolf Strandz provides RBAC as an infrastructure component, supporting all four aspects of an RBAC system and protecting your IoT data.
In the following deployment example, we can see how much simpler management of data access becomes when data is processed and stored centrally within an IoT system architecture that incorporates access control as a foundational design component.
By providing access control at the data-point level through consistent enterprise policy enforcement rather than as feature of each IoT user interface, the responsibility and authority around user management remains a function of Enterprise IT and not an additional risk or burden added to IoT application developers.
DESIGN FOR PRODUCTION FROM THE BEGINNING
In order for industrial IoT systems to produce and protect value through sophisticated access control in production, systems should be architected with a central data management plan in the prototype. If you’re just getting started with an IoT project and have questions, or are facing challenges with your existing system, let us know how we can help.
