User access and permissions

This article summarizes how users interact with Movere.

Tenant accounts, roles, and scopes

Tenant users

There are a few types of tenants in Movere:

  • Customer Tenant: A Customer Tenant user interacts with a specific customer tenant space.
  • Partner Tenant: A Partner Tenant user interacts with a partner tenant space. A Partner Tenant has a one-to-many relationship with any Customer Tenant associated with it. This allows Partner Tenant users to access multiple customer tenants, from a single account.
  • Program Tenant: A Program Tenant has a one-to-many relationship with any Customer and Partner Tenants associated with it. This allows Program Tenant users to access multiple Customer Tenants from a single account, and to manage Customer Tenants associated with their specific program.
  • Movere Tenant: All Customer, Partner, and Program tenants reside under the Movere Tenant, so that Movere Support can support all users.

User roles

A Movere user can be assigned the roles summarized in the table.

Role Allowed Not allowed
Customer Admin role Access the specific Customer Tenant.

Invite additional users to the Customer Tenant.

Grant users access to the tenant.

Manage data processing for the Customer Tenant.

Enable Movere-Azure Migrate integration for the Customer Tenant.
Can't access other Customer Tenants.
Customer Operator role Install Movere binaries in the tenant.

Upload data in the tenant to Movere.
Can't invite additional users to the Customer Tenant.

Can't grant Movere/Program users access to the tenant.

Can't enable Movere-Azure Migrate integration for the Customer Tenant.
Partner Admin role Access the Partner Tenant.

Automatically access any Customer Tenant associated with the partner tenant.

Invite users to the Partner Tenant.

Invite users to any Customer Tenant associated with the Partner Tenant.

Manage data processing for any associated Customer Tenant.
Can't grant Movere or Program users access to customer tenants.
Partner Operator role Access the Partner Tenant. Can't automatically access any Customer Tenant. Partner Operator users must be granted access to individual Customer Tenants by a Partner Admin.

Can't invite users to any tenant.

Can't grant Movere or Program users access to Customer Tenants.

Can't manage data processing for Customer Tenants.
Program Admin role Access the Program Tenant.

Invite users to the Program Tenant.

Invite users to the Partner Tenant.

Invite users to any Customer Tenant associated with the Partner Tenant.

Manage data processing for any associated customer tenant.

Create and manage Partner Tenants.

Create and manage Customer Tenants.
Can't automatically access any Customer Tenant. Must be granted emulate access by a Customer Admin user.

Can't automatically export data from a Customer Tenant. Must be granted export access by a Customer Admin user.

Can't enable Movere-Azure Migrate integration for a Customer Tenant.

Can't grant Movere or Program users access to Customer Tenants.
Program Operator role Access the Partner Tenant. Can't create or manage any tenant.

Can't automatically access any Customer Tenant. Program Operator users must be granted emulate access to individual Customer Tenants by a Partner Admin.

Can't automatically export data from a Customer Tenant. Must be granted export access by a Customer Admin user.

Can't invite users to a tenant.

Can't grant Movere or Program users access to Customer Tenants.
Movere Support & Services role Access high-level customer/tenant statistics for support and troubleshooting. Can't automatically access any Customer Tenant. Movere users must be granted emulate access to individual Customer Tenants by a Partner Admin.

Can't automatically export data from a Customer Tenant. Must be granted export access by a Customer Admin user.

Can't invite users to a tenant.

Can't manage data processing for Customer Tenants.

Can't grant Movere or Program users access to Customer Tenants.

User scopes

Users can be assigned a scope summarized in the table.

Scope Partner Customer Movere/Program user
Read

View all data within their Movere tenant account.
Available for Partner Admin and Operator roles. Available For Customer Admin and Operator roles. Available for Movere and Program users.
Write

Authenticate to the cloud via the Movere installer/Console, to download a token.txt file. The token.txt file is needed to upload data to Movere.
Not available for Partner Tenant users. Available for Customer Admin and Operator roles. Not available for Movere and Program users.
Edit

Create custom data tags, and perform license assignments.
Available for Partner Admin and Operator roles. Available For Customer Admin and Operator roles. Available for Movere and Program users.

Permissions summary

The table summarizes interaction between tenant accounts, user roles, and user scopes.

Tenant Role Read Write Edit
Partner Tenant Admin Access associated customer tenants.

Invite additional users to partner tenant/associated customer tenants.

Can't install Movere Console, or upload data to Movere.
No write access. Can create custom data tags, and perform license assignments.
Partner Tenant Operator Access associated customer tenants.

Can't invite additional users (they don't see the User option in the Movere portal).

Can't install the Movere Console, or upload data to Movere.
No write access. Can create custom data tags, and perform license assignments.
Customer Tenant Admin Access and view specific customer tenant.

Invite users to the customer tenant.

Grant Movere and Program users access to the tenant.
Same as Read access, plus the ability to:

- Install the Movere Console and binaries in the specific customer tenant.

- Authenticate to the cloud in the installer and Console.

- Upload data to Movere.
Access and view their own tenant.

Invite users to their tenant.

Grant Movere/Program users access to the tenant.

Create custom data tags and perform license overrides or assignments.
Customer Tenant Operator Access and view their own tenant. Install the Movere Console and binaries in the specific customer tenant.

Upload data to Movere.

Can't invite additional users (they don't see the User option in the Movere portal).
Can create custom data tags, and perform license assignments.
Program Tenant Admin/Operator Read access to customer tenant if granted by Customer Admin user.

Can export data from a tenant if permission granted by Customer Admin user.

Can't install the Movere Console. generate a token.txt file, or upload data to a tenant.
No write access. Can create custom data tags and perform license assignments.
Movere Tenant Support & Services Read access to customer tenant if granted by Customer Admin user.

Can export data from a tenant if permission granted by Customer Admin user.

Can't install the Movere Console. generate a token.txt file, or upload data to a tenant.
No write access. Can create custom data tags and perform license assignments.

User registration

All users accessing Movere must be invited by an administrator using a valid, private email address. Once invited, users receive an email prompting them to register. Users must allow movere.io, sendgrid and .io to receive the email. The invite is valid for 72 hours.

  • Public email services such as Outlook and Gmail aren't allowed. Nor are generic user IDs.
  • No two users can share the same email address. A user can register only one user account for each unique email address.

Access to Movere is governed by a combination of username, password and access codes. During registration:

  • The user specifies a password.
    • The password has a minimum complexity requirement of standard alpha-numeric normal and upper-case characters, numbers and symbols.
    • The minimum password length is eight characters.
    • The password must include a symbol, a number, and both a lower and upper case character.
  • Passwords are stored in a hashed format, and are cryptographically irreversible.

Protecting against unauthorized access

To protect against unauthorized user access, Movere uses two-factor authentication, and short-lived tokens that are issued upon logon.

  • The actual authentication and token management is performed by specialized APIs, and industry standard providers such as Identity Server.
  • After user identity is validated, the identity is stored in a token with a lifespan of one day. This means that if a logged-on user closes the browser without logging out, they can open the browser, and navigate to the Movere site, for up to one day after the original log in.
  • In addition to using short lived tokens, user identity is protected from impersonation, and man-in-the-middle attacks.

To ensure that a user’s account hasn't been compromised, Movere uses several validation techniques:

  • Firstly, on sign-in, Movere records system-specific information such as IP address, internet browser version, and display resolution. Collectively, this is referred to as the user's system fingerprint. If the system fingerprint changes, then the user is prompted to enter a new seven-digit code, sent over SMS or by voice call.
  • Secondly, if the user enters the wrong password three times consecutively, the account is temporarily locked for 30 minutes. This prevents programs, or other types of unauthorized users, from brute-forcing into Movere.

Movere Console access

The Movere Console orchestrates the scanning, collection and transmission of scanned data. It's protected as follows:

  • It can only be downloaded from the Movere site by authenticated users activity. This activity is tracked and logged.
  • A Movere Console includes several identifiers that make it unique to each customer. One of these identifiers is a global unique ID (GUID). A GUID is used since the Movere Console doesn't include any reference to the organization’s name, the user’s name, or any other PII elements that can link it to a specific organization or user.
  • Each Movere console is associated with a GUID and a region (provided at the time of installation). Movere communicates with only one region at a time.

Movere web access

Movere uses several methods to control user access to web content.

  • Administrator users can't change another user's password, but they can force a user to reset their password at the next sign-on. The user is sent an SMS message, and must enter the new seven-digit code to complete the password reset.
  • Users also can reset their own password from the Movere website. The user is sent an email, and must enter the new seven-digit code to complete the password reset.
  • Movere locks a user account after three failed sign-in attempts. The lockout period is 30 minutes and can't be bypassed. The forgotten password option continues to work during the lockout period.
  • If Movere detects a change in system-specific information associated with the user trying to sign in, for example, a change in IP address or browser, the user is prompted for two-factor authentication. The code is sent to the email address associated with the user Movere account.

Session management

The maximum number of parallel connections to a Movere account is five. A connection is the combination of device and browser.

  • If the same person, or a different person, logs into a Movere account from another device or browser, then an additional connection is made.
  • After five parallel connections are established, no further access to that account is granted until one of the five connections is terminated.
  • Movere uses four cookies for session maintenance on its website. All sessions are kept alive for 24 hours, after which the user is automatically logged-off. If a user logs off manually, the session cookies are immediately deleted.
  • One cookie is issued by the Web API for session state, one cookie is issued by the Authentication API and serves as a bearer token, and two cookies are issued by Qlik, providing authentication to the Qlik service.
  • Users are considered unauthenticated until the application has taken positive action to tie a session with an authentication token, which is validated on each submission or request.
  • Cookies set during an SSL session have the “secure” flag set, and have the domain component set to the domain associated with the public IP address.
  • Non-persistent cookies are only used to identify a client session, and contain the minimum amount of information required to implement functionality. All cookies contain a large enough random component to ensure uniqueness, and are encrypted or hashed.
  • Session tokens are cryptographically-unique, non-sequential, non-predictable, and resistant to reverse engineering. They aren't based on personal information, and have a unique key space large enough to prevent brute force attacks or enumeration. They are renegotiated after a configurable length of time. Brute force attempts at session tokens generate a security event in application assessment logs. Sessions are torn down effectively with logout functionality, and the application can manage normal and abnormal session termination.

Next steps

Learn about scanning, and scanning permissions.