Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

A user must successfully complete authentication using a valid IMMS InfraLink user account in order to access the functionality of and the data maintained in IMMSInfraLink. The functionality and the data available to the user are controlled by the permissions assigned to the user via IMMS InfraLink Role-Based Access Control (RBAC) by the IMMS InfraLink instance administrator. 

This article describes the features and functionality an instance administrator may rely on to manage user access to IMMSInfraLink

Table of Contents

Managing Roles

IMMS InfraLink relies on the concept of roles to grant privileges to registered users. Each role is a collection of permissions.  In order to grant a user access to certain kinds of data and/or functions, the IMMS  the InfraLink instance administrator must assign one or multiple roles containing permissions for the said data and/or functions to the user account.

Role definitions are instance-specific, and it is up to the IMMS InfraLink instance administrator to plan and define them based on the intended use of the instance, its user categories, security policies, and other factors. Even though new roles may be created and the already defined roles may be modified at any time during the IMMS InfraLink instance lifecycle, it is a good idea to plan and define some core user roles prior to creating user accounts. (Without the roles being defined there's no way to grant permissions to registered users). 

IMMS InfraLink provides two ways of partitioning data within the system: by kind of data (e.g. system elements, locations, cases, etc) and by contract. In other words, in addition to representing full or partial scope of a business arrangement, a contract in IMMS InfraLink acts as security container. That allows IMMS InfraLink administrator to restrict user access 

  • Global permissions. Some data objects within IMMS InfraLink are global and exist at the IMMS InfraLink instance level, not restricted to one or multiple contracts. Global objects include definitions (e.g. system element types, location types, workflows, etc.), user accounts, and roles. The Create, Read, Update, Delete, and other permissions associated with such global data objects are referred to as global permissions. The word global in this context means that the permission applies at the IMMS InfraLink instance level and is not restricted to one or multiple contracts.
  • Contract-level permissions. Most of the business objects that represent the scope of a project, such as system elements, locations, assets, cases, tasks, and the other related ones, support contract associations. For example, each case must be associated with a contract it belongs to, and each system element or locations may be associated with one or multiple contracts that apply to it. The Create, Read, Update, Delete, and other permissions associated with business objects that support contract associations are referred to as contract-level permissions. The contract-level permissions provide additional granularity for controlling access to the respective business objects. 


Similar to permissions, IMMS InfraLink supports two kinds of roles:

  • Global roles. Global roles may contain both global and contract-level permissions. Roles defined as global may only be assigned to user accounts globally (i.e. not at the contract level).
  • Contract-level roles.  Contract level roles may contain only contract-level permissions. Roles defined as contract-level may be assigned to user accounts on a per contract basis or globally. Assigning a contract-level role globally will grant the user the corresponding privileges across all contracts. 

You can access the list of already defined roles via the Configure / Roles menu. The Configure menu is located on the right hand side of the menu bar at the top of the IMMS InfraLink window.  

The view provides the following functionality: 

  • Filtering by scope. Use the Scope widget in the left hand-side filter panel to restrict the view to global or contract-level roles, as defined above. 
  • Filtering by included permissions. Sometimes you need to find all roles that contain a particular permission (e.g. all roles that allow the user to approve account requests). To do so, use the "Included Permissions" filtering widget. Selecting multiple permissions in the filter will allow you to locate all roles that contain the selected combination of permissions.
  • Filtering by permissions not included in the role. Sometimes you need to find all roles that do not provide access to specific data/functionality or, more commonly, the roles that include some permissions but not the others. For example, you may need to answer the question "What roles allow the user to view system elements, but not to create or edit them". To do so, use the "Excluded Permissions" filtering widget. Selecting one or multiple permissions in the Excluded Permissions list will allow you to locate all roles that do not include any of the selected permissions. 

Selecting a role in the Configure Roles view list will bring up the role definition details panel on the right. The layout of the panel is self-explanatory and contains the role name, description, scope (global or contract), and the list of permissions included in the role.

Additional, the role definition details informs you of the number of active users with the particular role assigned to them. That number is displayed as a hyper-link titled "Active Users". Clicking on the link will allow you to navigate to the list of users filtered by the particular role. This function may be especially beneficial when reviewing the users granted elevated (administrative) privileges. 


Typically, you create a new role to support a particular category of users. For example, you would create an "Inventory Manager" role, which includes permissions associated with receiving, tracking, and managing warehouse of materials/spares, to grant necessary privileges to users responsible for managing the inventory. 

...

Note: When editing an existing role, keep in mind that the new privileges will be granted to and previously granted privileges will be immediately revoked from all users associated with the role. Carefully consider the security and usability implications prior to editing the list of permissions included in the previously defined role, especially if it has been already assigned to users. Use the Active Users link on the role definition details to review the user accounts the role is assigned to prior to making changes.

Sometimes, a previously created role definition may become obsolete. For example, if you previously defined the role "Manager", which included a broad range of privileges. Suppose, you later realized that you may need to grant the service management and inventory management privileges to different users. To support that, you will create separate roles, say "Service Manager" and "Inventory Manager". At that point the previously created "Manager" role will become obsolete, and it will be beneficial to delete it to avoid confusion and, more importantly, granting unnecessarily broad privileges to users.

...

Note: When deleting a role, keep in mind that the corresponding permissions will be immediately revoked from the user accounts the role was previously assigned to. To avoid a situation when users are unable to perform their respective business functions, be sure to assign replacement roles (as discussed in the above example) before you delete the role which is no longer needed. You may use the Active Users link on the role definition details panel to review the list of users the role is assigned to prior to deleting it. 

Managing User Accounts

IMMS InfraLink supports multiple user authentication methods. Each authentication method is associated with a corresponding Authentication Provider (Authentication Domain) Type. When an IMMS InfraLink instance is deployed, it may be configured with one or multiple Authentication Providers of the following types (whereas the type defines a particular authentication method):

  • Internal. IMMS InfraLink may be configured to authenticate users via username/password against a local account database maintained by IMMSInfraLink. Note the account database is secure and does not contain unencrypted password. Password storage and authentication rely on approved cryptographic algorithms. If the IMMS InfraLink instance is intended to support internal authentication, a single authentication provider (domain) of the type "Internal" must be configured. If the instance is intended to rely on Active Directory and/or PKI only, the instance should be configured without an internal authentication provider. 
  • Active Directory. IMMS InfraLink may be configured to authenticate users via username/password against an enterprise directory, such as Microsoft Active Directory (AD) accessible via a standards-based LDAP protocol.  An IMMS InfraLink instance may be configured to authenticate users against multiple independent enterprise directories. In such case, a separate authentication provider will be defined for each directory at the time of deployment, and each user account will be associated with an appropriate authentication provider, i.e. the directory, which the user belongs to.
  • PKIIMMS InfraLink may be configured to authenticate users using standards-based Public Key Infrastructure (PKI) certificates, such as DOD CACs or, more generally, US Government PIV cards. An IMMS InfraLink instance may support user certificates of different types and/or issued by different Certificate Authorities (CAs). In such cases, the instance must be configured with multiple authentication providers of the type "PKI", whereas each provider is associated with the specific certificate type and root CA.

...

The security policy for the program relying on IMMS InfraLink may require that all users be authenticated using multi-factor authentication (MFA). MFA typically refers to authentication using two or more of the common authentication factors, such as 

  • Something you know, e.g. password
  • Something you have, e.g. hardware token
  • Something you are, e.g. biometric

IMMS InfraLink supports the following MFA alternatives:

  • Internal with Second Factor. IMMS InfraLink authenticates the user via username/password and subsequently challenges the user for the second factor, such as random verification code. The implementation relies on the Okta (www.okta.com) Universal Directory, Multi-Factor Authentication (MFA), and Single Sign On (SSO) services with multiple options for the second factor delivery, including 
    • SMS to the user's registered mobile device
    • Email to the user's registered email address
    • Push notification to the Okta Verify mobile app installed on the user's registered mobile device
    • Offline software token generated by Okta Verify mobile app installed on the user's registered mobile device
  • Enterprise Directory with Second Factor. IMMS InfraLink authenticates the user via username/password against an enterprise directory accessible via a standards-based identity federation protocol, e.g. Active Directory Federation Services (ADFS), and subsequently challenges the user for the second factor, such as random verification code. The implementation relies on the Okta (www.okta.com) Universal Directory, Multi-Factor Authentication (MFA), and Single Sign On (SSO) services with the same second factor options as outlined above for internal authentication.  
  • PKI. Using PKI-based authentication, e.g. authenticating users via DOD CAC, satisfies the MFA requirements, as the user must provide a PIN ("something you know") to access the certificate stored on the card ("something you have"). IMMS InfraLink relies on the Online Certificate Status Protocol (OCSP) to query the OCSP responders associated with the CA/user certificate and verify that the presented valid certificate has not been revoked.

If the IMMS InfraLink instance requires MFA support, the corresponding authentication providers are to be configured at the time of deployment, and the IMMS InfraLink deployment team provides necessary implementation details to the IMMS InfraLink administrator to support user registration, provisioning, and troubleshooting.

...

To gain access IMMSInfraLink, each user must have a valid user account. IMMS InfraLink user accounts are defined as follows:

  • Authentication Provider (Authentication Domain). A user account must be associated with one and only one of the authentication providers configured for the IMMS InfraLink instance. The choice of the authentication provider defines how the user will authenticate with the system and may impose specific requirements/restrictions on the user's login name.
  • Login Name. Each user account must have a unique login name. The authentication provider selected for the account may impose additional requirements on the login name. Specifically, 
    • If the account is configured to use an enterprise Active Directory (AD)/LDAP authentication provider, the login name must match the user's login name registered in the AD/LDAP directory;
    • If the account is configured to use PKI, the login name must correspond to the information in the user certificate;
    • If the account is configured to use an external OpenID Connect provider, the login name must be the user's email address registered with the OpenID Identity Provider (IDP)
  • Name, Contact Information. Each account must include standard attributes, such as first and last name, and email address. Optional contact information, such as phone number and address, may also be included.
  • Roles. One or multiple roles must be assigned to the account in order to give the user access to the information and/or actions within IMMSInfraLink. See the "Granting Privileges" section further in the document.
  • Affiliations. Use the Affiliations tab of the User Account Edit dialog to manage the affiliations, such as Government/Contractor, CIV, etc.

The list of user accounts is available via the Configure / Accounts menu. (The Configure menu is located on the right of the menu bar at the top of the IMMS InfraLink page). 

The IMMS InfraLink user accounts list include all requested and active accounts, as well as those that have been deactivated. The view provides standard controls, including the filter panel on the left, quick search by keyword, the ability to configure columns, and the ability to export list of accounts in a standard format, such as MS Excel.  

Selecting a single account in the list activates the user account details panel, which provides comprehensive information for account provisioning, maintenance, and troubleshooting. 

The user account details panel includes the basic identifying information (name, login) and contact details, as well as the following key features and controls:

  • Change Status. Allows the administrator with sufficient privileges to activate or deactivate the account. 
  • Last Login. Displays the date and time of the last successful login and is useful  for troubleshooting and account activity review purposes.
  • Access log. Provides direct access to the IMMS InfraLink access log filtered to show the activity associated with the particular account. The log displays successful and unsuccessful login attempts along with their respective time stamps, client type (mobile or web), and additional information, such as remote IP address.
  • Action Log. Provides direct access to the IMMS InfraLink action log filtered to show the activity associated with the particular account

To gain access to the IMMS InfraLink instance, a prospective user will request an account via the Request Account link on the IMMS InfraLink login page. When an account request is submitted by a prospective user, IMMS InfraLink will generate email notifications to all instance administrators who have the user account create/update privileges. 

...

  • Select the account in question from the list of accounts. Note the status of the account should be set to "Requested"
  • Review the information, including the justification listed in the Description field in the details panel. If the justification is insufficient and/or if you are not familiar with the prospective user requesting an account, contact the prospective user and/or supervisor out of band to validate the request. Do not activate the account unless you have sufficient rationale/justification. 
  • If necessary, update the selected Authentication Provider. In some situations, the prospective user may not be sufficiently familiar with the environment to select the right authentication provider. You may update the selection prior to activating the account. 
  • Based on the justification provided in the Description field, assign one or multiple roles to the account to provide necessary privileges to the user. See detailed explanation in the Granting Privileges section below.
  • If the provided justification is sufficient, click Change Status / Activate in the details panel to activate the account. Alternatively, if you performed additional investigation and determined that access should not be granted, select Change Status / Reject to reject the request. 

In order to maintain the security posture of the IMMS InfraLink instance, it is necessary to perform periodic reviews of the account database. The list of accounts accessible via the Configure / Accounts menu provides several important controls that enable the review and auditing features, as outlined below.

Use the Role Scope / Role filter panel widget to locate and review the accounts with elevated global or contract-level privileges. Select the scope (e.g. one or multiple contracts) and one or multiple roles to display the list of accounts associated with that role. Review the account details (using the details panel) to ensure that the assigned privileges are consistent with the justification/rationale.

Note: to determine which roles should be used for this review, you may need to rely on the "Included Permissions"/"Excluded Permissions" filters of the IMMS InfraLink role list (Configure / User Roles). 

Use the Last Login widget of the filter panel to generate the list of users who haven't accessed IMMS InfraLink within a set interval. 

Select accounts and use the Change Status control to deactivate upon review.


Use the Rules Accepted  filtering widget to verify that all users have accepted the rules/AUP at the time of registration. 

Granting Privileges to Users (Assigning Roles)

In order to give the user access to data and/or functions within IMMSInfraLink, the user account must be assigned one or multiple roles. To do so, complete the following steps:

  • Access user account details. You can do so using the Configure / User Accounts menu to access the account list or by using the details panel drill-down navigation from a related entity.
  • Expand the Roles widget of the Account Details. 

To grant privileges at the instance level, complete the following steps:

  • Click the "Add" button and select "Global" from the drop-down. IMMS InfraLink will present a pop-up window listing all global and contract-level roles defined on the instance
  • Select one or multiple roles in the pop-up window and click "Grant Privileges" 

Note: IMMS InfraLink allows for both global and contract-level roles to be assigned globally. If you assign a contract-level role to the user account globally, the user will have access to the respective business objects across all existing and future contracts. It is important to exercise good planning and judgment to avoid inadvertent expansion of user access.

To grant contract-level privileges, complete the following steps:

  • Click the "Add" button and select "Global" from the drop-down. IMMS will  InfraLin will present a pop-up window listing the contracts and contract-level roles defined on the instance
  • Select one or multiple contracts in the list on the left. Use keyword search and filters as necessary to narrow down the list and help with selection.
  • Select one or multiple roles in in the list on the right. Use keyword search to help with the selection. 
  • Click "Grant Privileges". Selected roles will be assigned to the user account for each of the selected contracts.

To revoke already granted privileges, select one or multiple roles by clicking in the corresponding check-boxes and click the "Remove" button. 

...