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

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

Managing Roles

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 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 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 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). 

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 InfraLink acts as security container. That allows InfraLink administrator to restrict user access 

  • Global permissions. Some data objects within InfraLink are global and exist at the 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 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, 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 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. 

From time to time you may need to update an already defined role to grant additional privileges to or revoke privileges from all users the role is assigned to. 

  • To create a new role
    • Access the list of roles via the Configure / Roles menu
    • (Optionally) Use the filtering functions to make sure that the role you intend to create does not already exist (perhaps, by another name and/or combined with other privileges)
    • Click the Create button at the top of the list. The role definition dialog window will appear.
  • To edit an existing role
    • Access the list of roles via the Configure / Roles menu
    • Use the filtering and/or quick search function to locate the role you intend to modify
    • Select the role and click the Edit button
  • Complete/update the role definition as follows:
    • Name - provide a concise, yet descriptive name for the role. This name will appear when roles are listed, including the dialog you use to assign roles to users. Therefore, it is critical for the name to properly communicate the purpose of the role and the kind of permissions it includes.
    • Description - provide additional information you and/or other administrators may need to properly select the role when assigning it to users in the future and/or when updating role definitions. 
    • Scope - specify whether the role will be global or contract-level. See the explanation above.
    • Permissions - use the hierarchical list to select the permissions to be included in the role. Note that the list of permissions available for selection depends on the role scope. If the role is defined as contract-level, only contract-level permissions will be available for selection. A role with a global scope, however, will allow you to select from the list of both global and contract-level permissions.
  • Click OK when all necessary parameters are specified.


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.

To delete a role, complete the following steps:

  • Access the list of roles via the Configure / Roles menu
  • Use the filtering and/or quick search function to locate the role you intend to delete
  • Select the role and click the Delete button. A confirmation dialogue will appear.
  • Select Yes to proceed with deleting the role


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

InfraLink supports multiple user authentication methods. Each authentication method is associated with a corresponding Authentication Provider (Authentication Domain) Type. When an 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. InfraLink may be configured to authenticate users via username/password against a local account database maintained by InfraLink. Note the account database is secure and does not contain unencrypted password. Password storage and authentication rely on approved cryptographic algorithms. If the 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. 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 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.
  • PKI.  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 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 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

InfraLink supports the following MFA alternatives:

  • Internal with Second Factor. 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. 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"). 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 InfraLink instance requires MFA support, the corresponding authentication providers are to be configured at the time of deployment, and the InfraLink deployment team provides necessary implementation details to the InfraLink administrator to support user registration, provisioning, and troubleshooting.

To gain access InfraLink, each user must have a valid user account. 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 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 InfraLink. 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 InfraLink page). 

The 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 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 InfraLink action log filtered to show the activity associated with the particular account

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

Assuming that you have sufficient administrative privileges to manage user accounts, you can review pending account requests by following the link included in the account request email notification or by navigating to the user account list (Configure / User Accounts menu) and filtering the list by the account status set to "Requested". 

To approve the account request, complete the following steps:

  • 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 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 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 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 InfraLink, 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. 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: 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. 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. 

Note, you can revoke contract-level roles on a per-contract basis. For example, if the user account had the role X granted for contracts A, B, and C, you can remove the said role under the contract A and leave it assigned for the other contracts, B and C. That way, the user will no longer have access to the corresponding data/functions under A, but will be able to access them under B and C.

  • No labels