11 July, 2016
Recently, we took a closer look at the architectural basics that enable security in innius. In today’s blog post, we discuss how innius security decides who the actors interfacing with the solution are, how to identify them, how they prove who they are, and what they are allowed to do.
Identifying and authenticating innius actors
In the context of the cloud and cloud services, are well-used and closely related aspects of security. A simple definition: Identification renders an identity. Authentication offers the evidence to prove to a system that a user is permitted to assume that identity.
In innius, we use four types of identification for different entities or actors:
- A company is known through its primary internet domain. We assume that internet domain name restrictions and conventions safeguard against unwelcome identifications.
- A person—the term for an innius user—is identified by an email address whose domain (the part following the @ sign) is the same as that of the company.
- A machine can have a single or several identifications. Each machine identification consists of a system of reference—a prefix followed by the domain name as the suffix—and an innius internal ID.
- An innius service has a unique name.
When it comes to authentication, this depends on the kind of token each of these four actors needs to acquire.
- Persons using the innius mobile or web apps authenticate with Auth0. They enter their identification email and password in a dialog box. Auth0 verifies the authentication request and return an Auth0 token.
- Companies, machines, and services use a token, generated earlier, to request access to the innius cloud.
You should know that the generation of tokens for companies and machines depends also on the authentication and authorization checks for the person making the token request. Token generation for services, on the other hand, takes the already authenticated user of the original request, assuming that authentication and authorization already took place.
Authorization for collaborative environments
The innius authorization technology is designed to support collaborative, multi-tenant maintenance and management of industrial assets. The collaboration network can include machine manufacturers, customers, service providers, and other stakeholders.
Key features of innius authorization include the following:
- Companies can only define policies for the resources they own. Each innius resource is owned by the company to which the user creating an authorization policy, machine, or back-end belong.
- If no authorization policy applies, an authorization request fails. This model is also known as deny-by-default.
- The three main components of the innius authorization structure:
- Authorization groups consist of members or actors, as defined above. They are defined by companies, which place the actors in them.
- Authorization policies comprise a number of statements. Statements define the outcome of the authorization—permission or denial—for a combination of resources and actions and match the specifications of resources and actions in the statement. One or multiple authorization policies are associated with each authorization group.
When you first create a company in innius, you predefine a number of authorization groups for administrators and users. The company administrator is a fully authorized member of the administrator group.
If you would like to explore innius more practically, have questions, or want to provide feedback, please contact us
Follow us
