Matrix42 IGA solution is available in three (3) packages, Starter, Growth and Enterprise. Each package contains a number of ready-made use cases. Each package builds on the previous one: for example, Matrix42 IGA Growth package includes all of the use cases provided with Matrix42 IGA Starter package.

IGA packages include everything from the cloud environment to installations, definitions, project management, use case testing, and project go-live. 

Matrix42 IGA Starter package

Matrix42 IGA Starter package is designed for organizations starting their IGA journey. It is the first step in any IGA implementation, which is why it is included in all other IGA packages. 

Matrix42 IGA Starter package contains all of the essential use cases for an easy start, while still building a solid base for security requirements, access rights requests and future development - for example adding further user lifecycle management use cases, such as onboarding and offboarding. 

Matrix42 IGA Starter package enables you to provide end-user services for requesting and removing access rights. It also contains important tools for IGA admins to manage and audit user and access rights information.

Matrix42 IGA Starter package contains provisioning and de-provisioning towards Active Directory (AD) or Azure AD directory. If you are running a different directory, such as OpenLDAP or IBM LDAP, it requires additional planning. 

Matrix42 IGA Growth package

Matrix42 IGA Growth package is for organizations that need to automate user lifecycle management based on information from an integrated source system (usually an HR management system) or the Matrix42 Self-Service Portal.  

Matrix42 IGA Growth package also contains several new use cases for IGA Administration and IGA Governance. 

Matrix42 IGA Enterprise package

Matrix42 IGA Enterprise package contains all of the ready-made use cases from the Starter and Growth packages, plus several more advanced use cases - for example to manage privileged access. 

Matrix42 IGA Enterprise package can also contain customer-specific configurations, approval processes, Matrix42 Self-Service Portal services, and more.

You can find our step-by-step approach with the 3 packages and their ready-made use cases in the image below:

You can configure Matrix42 Self-Service Portal for your organization in a number of ways that don't affect the project schedule or work estimations. These configuration options are described in the detailed use case description document.

You can also customize the look and feel of Matrix42 Self-Service Portal through elements such as the color palette, logo and background image. Additionally, you can include your own contextual help text and customize the attribute names that appear on each service or page. 

The end-user can see their own open requests in the Matrix42 Self-Service Portal home page, and view their request history in the "My requests" page. 

If the user has approval responsibilities, they can view requests awaiting their approval in the Matrix42 Self-Service Portal home page. They can view their approval history in the "Approvals" page. 

My things is a feature that allows end-users to view their own personal information and active access rights. Managers can also view information relating to their subordinates.

This functionality is available for all customers using Matrix42 Self-Service Portal. You can define what information is shown in the My things page.

Good to know

Your users can only ever view the access rights that they are permitted to request or remove. If a user wants to request the removal of an access right, for example, they can only see access rights that they are permitted to request. 

Matrix42 IGA solution allows you to create knowledge base articles that can be shown to your end-users, for example if you want to provide end-user instructions. This functionality is available with Matrix42 Self-Service Portal, but you will need to create the knowledge base articles yourself.   

Every request from Matrix42 Self-Service Portal triggers the creation of an IGA Service Request. If the request covers multiple services, an IGA Service Request Bundle is created.

Add new user

Many organizations lack tools to create new users, so the process is done manually using paper, MS Word, MS Excel, etc. In some organizations, user creation is based on custom-built scripts in AD, which do not allow easy updates. This can lead to security risks and possible non-compliance with EU regulations.

With this use case, new users are automatically created in Matrix42 IGA solution based on information received from Matrix42 Self-Service Portal. The new user information is automatically provisioned to the customer directory.

Outcomes of this use case include:

• Improved security
• Easier audits and compliance with EU regulations
• Reduced IT admin workload related to new user on-boarding

Update user information (including leaving users)

Many organizations lack tools to update user information during the user lifecycle or when the user is leaving the organization. Updates tend to be done manually using paper, MS Word, MS Excel, etc. This can lead to errors and outdated information, as well as security risks if access rights remain active after an employee leaves.

With this use case, you can update users' personal and organizational data via Matrix42 Self-Service Portal. The information is provisioned to AD or Azure AD. A record of updates to user information or access rights is preserved for audit or regulatory compliance purposes.

For leavers, Matrix42 IGA solution disables the user's accounts in the target systems and removes related access rights from the user's account. You can define the timelines for disabling the accounts and removing access rights. The user's account is stored.

Outcomes of this use case include:

• Improved security
• Easier audits and compliance with EU regulations
• Reduced IT admin workload related to user off-boarding

Request access rights

Security risks and inefficiencies can arise when there is limited or no automation for access rights requests and provisioning, multiple ways to request access rights (for example via email or Word/Excel templates), and/or no single point where all records are maintained. Organizations also need to be able to trace digital identities and related access rights, and enforce approval chains.

With this use case, users can easily request access rights for themselves or their subordinates via Matrix42 Self-Service Portal. They get always-on visibility to request status in Matrix42 Self-Service Portal, and all audit details are saved and can be reported. Approval chains are flexible and trigger provisioning of access rights towards your directories. 

Outcomes of this use case include:

• Improved efficiency
• Improved security
• Easier audits and compliance with EU regulations

Remove access rights

Organizations can face problems when users have accumulated more rights than they need for their job, and there is a lack of visibility into which rights need to be removed and the status of current accesses overall. Organizations need a convenient way to remove unnecessary access rights, roles and entitlements, and trace changes for auditing purposes.

With this use case, organizations can request removal via Matrix42 Self-Service Portal, with automated provisioning. Users and managers can follow up request status. All audit details are saved and can be reported.

With IGA Enterprise package, also admin accesses can be removed using the same service.

Outcomes of this use case include: 

• Improved management of licensing costs
• Improved security and compliance with EU regulations

Manage physical access rights
 
For security purposes, organizations need to control physical access to premises, assets and keys. However, physical access must be easy to manage, otherwise problems can arise when users cannot gain access to facilities they need to carry out their work. 

With this use case, organizations can use the self-service portal services for the following functions:

1. Change PIN-code (for physical access card or badge)
2. Remove existing physical access rights
3. Report missing physical access card or badge
4. Request new physical access rights

Physical access rights can be added to business roles, automated rules or toxic combinations.

Outcomes of this use case include:

• Reduced risk of unauthorized entry
• Improved employee safety

Manage privileged access rights 

Organizations need to control elevated or privileged access rights and permissions for users and accounts. For example, every organization that uses Active Directory (AD) has domain admins who can carry out any task in AD and can potentially access any information in the organization. 

A process is needed to manage activities relating to higher-level accounts, such as requests and approvals, without the need for full-blown Privileged Access Management (PAM) capabilities such as recording or password vaulting. 

There are three (3) services in the Self-Service Portal related to privileged accesses. These services are interdependent and must be used in the correct order:

1. Request privileged account: A bundle request which then allows the user to request privileged access rights to be added to the account requested.
2. Request privileged accesses: Used instead of the above if the user already has a privileged account.
3. Activate privileged accesses: Fulfilled when the user needs to use their privileged access rights (which are only ever active for certain period of time).

Outcomes of this use case include:

• Reduction in the potential attack surface
• Prevention/mitigation of damage from external attacks and/or insider malfeasance or negligence

Change password 

Simple tasks like password resets account for 29% of all tickets received by IT Service Desk.  Lost passwords can also impact productivity - for example when a user can't log in to their computer if their AD password is lost, or can't change their active password for any application they have permission to access.
This use case empowers the user to change their own password in Matrix42 Self-Service Portal. The functionality can be expanded by adding Strong Authentication capabilities to the process, or by enabling password change to all user's accounts (if they have multiple accounts). 

Outcomes of this use case include:

• Reduced workload for IT admins, freeing time for more valuable work

 
Lock user account 

Over 60% of data breaches in 2021 were related to access rights misuse. Organizations need to be able to lock a user immediately if their use of access rights is linked to suspicious activity or fraud.
This service is used only in situations where a user's access rights must be disabled immediately: for example if their access rights are being misused. It will lock the user's accounts and access rights, inform manual request handlers, and freeze the user's identity in IGA Identity Storage.  

Outcomes of this use case include:

• Rapid lock of user accounts when necessary
• Simple process to stop access rights misuse

Create and update entitlements

Organizations need a way to create and update entitlements by users who are not admins. For example, a project manager may need to create several AD groups or entitlements at the beginning of a project.

With this service, end-users can request new entitlements to be added or updated to the directory, and the admin only needs to review and approve the requests. Note that this use case is different from requesting access rights (use case #3), since in this case a directory group object is created or updated. 
This service contains three (3) different options:

 

1. Create new entitlement: Automatically create a new group in the directory
2. Update entitlement: Automatically update group information in the directory, or update (for example) entitlements visibility in the Self-Service Portal 
3. Mass import entitlements: This will generate an IGA Admin Task to create the data import

Outcomes of this use case include:

• Reduced workload for the IGA admin team
• Improved business agility

Delegate approval responsibilities

Organizations need a convenient way to delegate approval responsibilities when the primary approver is unavailable (e.g.: on leave).
This service is commonly used by users with approval responsibilities, such as Managers and Business Role or Entitlement Approvers. The user can view and select from among the following options:

 

1. Substitute for all approval responsibilities
2. Substitute for IGA Entitlement 1. Approver
3. Substitute for IGA Entitlement 2. Approver
4. Substitute for IGA Business Role 1. Approver
5. Substitute for IGA Business Role 2. Approver
   
    

Outcomes of this use case include:

• Improved efficiency and business agility 

It is possible to expand the service catalog in Matrix42 Self-Service Portal.

Matrix42 Self-Service Portal can be used for many types of service requests. The services you publish in the portal will depend on which Matrix42 solutions you are using. ITSM services are most commonly published to the portal, but service can also be anything from a training request to complex finance services requiring special approvals. Expansions are always subject to a separate scope of work that we define together with you.

Matrix42 IGA solution customers are often looking to automate the provisioning process, in order to reduce manual IT admin work and improve system security.

Matrix42 IGA solution contains the cloud component Matrix42 Provisioning Engine, which is capable of reading and writing data to different directories. 

Matrix42 Provisioning Engine is configured in the IGA Solution Configuration Console and executes provisioning using the workflow engine's orchestration nodes. Connection to the directory is created using event-based and schedule-based provisioning tasks. 

Matrix42 Provisioning Engine has its own component description where its technical capabilities are described in more detail. 

Matrix42 Provisioning Engine is able to read and write data to following directories:

* Only possibility to read data (scheduled-based provisioning)

When Matrix42 Provisioning Engine is reading or writing data towards the directory, it uses the IGA Account data card for user account information and the IGA Entitlement data card for group information. 

Provisioning capabilities for writing data towards directories (event-based provisioning): 

Provisioning is part of several workflows and may happen several times during the process, depending on which type of action is needed to execute towards directories. 

To comply with regulation and pass internal and external audits, organizations need a single, accurate and always-on “system of truth" containing all information about access rights.

Additionally, to avoid insider attacks, organizations must ensure that nobody is able to gain extra access rights directly without approval.

The De-provisioning and Reconciliation use cases address these challenges. Matrix42 IGA solution becomes the master for AD or Azure AD, and if changes are made directly in AD if a user has access rights which have not been approved - the issue will be flagged (de-provisioning) and a correction action or approval request will be triggered (reconciliation).

Outcomes of these use cases include:

• Improved security and prevention of unwanted data exposure and breach of information
• Compliance with regulation and audits

When data from the customer's directory is read to the IGA Entitlements and IGA Account data cards, there are two possible ways to manage the information:

De-provisioning

De-provisioning is part of several workflows and use cases. In Matrix42 IGA solution, de-provisioning can be done: 

1. From Matrix42 Self-Service Portal by requesting access right removal

2. As part of IGA Automated Rules functionality. When rules no longer apply, access rights are automatically removed from the user

3. As part of user lifecycle management, when leaving users are managed in Matrix42 IGA solution

4. During the re-certification use case, if automatic removal is included

5. When reporting changes between Matrix42 IGA solution and the directory

Reconciliation

When data is read from the directory, Matrix42 IGA solution validates whether any changes relating to user account and group membership information have been made directly to the directory . 

If there are any changes to the user account information, Matrix42 IGA solution will generate an admin task for the IGA admin to synchronize user data between the source system, Matrix42 IGA solution, and the directory.

If there are any changes to a user's group memberships, Matrix42 IGA solution will generate an approval request in the Matrix42 Self-Service Portal for the relevant manager to approve or decline the additional access rights. 

Organizations typically have hundreds of applications, and the number is increasing rapidly. They need to know who has access to which app, but not every app is attached to customer directories, so admins need to keep this info manually.

The Manage data imports use case addresses this challenge. Matrix42 IGA solution enables a one-time import of data without triggering provisioning towards AD, Azure AD, or another customer directory.

Outcomes of this use case include:

• Cost savings by reducing IT admin manual work
• Security improvements by ensuring visibility of apps and their users and access rights

Data imports can be used for data such as:

• Access rights from apps
• Business roles
• Applications list
• Access rights records from source apps

For example, IT admins can fill out an IGA app template any time they need to add an app or update related entitlements. This information is then imported to IGA master data.

The IGA Import Task data card is used for importing data as described. Data imports allow IGA admins to import one-time data content to certain data cards, and to provide current user, access right and group membership data. 

Data imports are not scheduled and have no restrictions regarding data content, which means that data is read as it is in the import file. 

Different types of data imports include:

1. IGA entitlements from different applications 

You can export group information from the application and import it to IGA Entitlements. After import, the information can be used in the same way as IGA Entitlements where the provisioning type is manual. Usually this is done when a new application is starting to use Matrix42 IGA solution's centralized services, processes and workflows for requesting and managing applications access rights. 

2. IGA business roles

You can import a list of pre-defined roles (or export one from another application) into Matrix42 IGA solution. This kind of import is typically done once, when Matrix42 IGA solution is first deployed for technical users. 

3. Application list

If you have a list of all of the applications used in your organization, you can import it into Matrix42 IGA solution for further usage. This import is typically done once, after which the applications are managed in Matrix42 IGA solution.

4. IGA access right records

Group membership information can be exported from the source application and imported into Matrix42 IGA solution. This will provide audit information about who has currently active access rights to the application.

5. Proof of concept 

IGA Import Task can be used in IGA Proof of Concept (PoC) projects to simulate HR integration and user imports. PoCs do not typically include real HR integration, but it is important to test how future HR integration would work.

Attribute information

* same field appears for each selection

 

Users across the organization often spend time doing manual, user-by-user updates whenever there are changes in the organization structure, cost centers, or employee job titles. Sometimes these updates are missed and information becomes outdated, with the out of date information visible across IT systems and apps like Outlook.

With this use case, organizational units, cost centers and job titles are automatically updated in Matrix42 IGA solution from HR systems. They can be reused across users, and sorting information by these parameters is possible. This improves efficiency across the organization thanks to a reduction in manual work and human error.

Different types of data card are needed to manage organizational information, depending on what kind of information is read from the source system. Matrix42 IGA solution has three (3) commonly used data cards, but it is also possible to read other types of organizational information depending on your specific needs, and use it for example in IGA Automated Rules:

1. Organization

2. Cost Center

3. Title

We highly recommended that you automate organizational data read if you decide to use IGA Automated Rules, to ensure consistently high quality of data content. 

Attribute information

1. Organization

The Organization data card contains the required attributes for all Matrix42 solutions. For Matrix42 IGA solution, the most important information is listed here. 

2. Cost Center

The Cost Center data card contains the required attributes for all Matrix42 solutions. For Matrix42 IGA solution, the most important information is listed here. 

3. Title

User updates have to be made frequently (temporary workers, departmental updates, etc) and manual methods are costly and risky. If software licenses continue to be paid for after an employee leaves, it creates unnecessary cost for the employer. If access rights are not removed, it creates a security risk. Department or job title updates are often outdated in AD and Outlook, while the HR system has up-to-date information.

This use case provides an automated process for user creation and updates, including all unique user attributes and automated provisioning to relevant directories. Access rights are terminated when an employee leaves, and can be automatically updated based on the user information (if you have the automated rules use case).

Outcomes of this use case include cost savings from automation and optimized license management.

User lifecycle management comprises multiple capabilities and includes integration to a source system (typically the HR management system), from where a user's personal and employment data can be retrieved. 

User lifecycle management contains all automated processes: from on-boarding new people, to managing any changes during their employment, and the execution of all removal processes when their employment ends. 

On-boarding new joiners

When a new user's personal and employment information is added to the source system and Matrix42 IGA solution receives the information via integration, it will create the new user in IGA Identity Storage. Workflow will then start generating the required attributes and credentials for provisioning the information to the directory. Matrix42 IGA solution generates a unique ID for each user, but an employee number or social security number can also be used as a unique attribute for the user.  

Work periods

In Matrix42 IGA solution, user lifecycle management is a flexible process that allows users to have multiple work periods which can be consecutive or overlapping. The user's access rights, accounts, physical accesses, etc. can be related to a particular work period, meaning that they are available to the user for the duration of that work period. If one of the user's work periods ends, the access rights related to that work period are removed, but access rights relating to other work periods remain in place. 

Users must always have one primary work period. Information relating to the primary work period is provisioned to directories and used in the Person data card. If a directory accepts only one attribute (for example, the user's manager), that attribute will be provisioned from the Primary Work Period data card.

Primary work period calculation 

The user lifecycle management process contains ready-made logic for calculating a user's primary work period. If the user only has one active work period, that work period is always marked as primary. 

If user has several work periods, each employment type (permanent, temporary, hours-based, etc.) is assigned a priority number. If there are two or more of the same type of employment, Matrix42 IGA solution selects a primary work period based on work period validation dates.

Changes during employment

Multiple changes may occur in a user's personal and employment information during their employment period. The way Matrix42 IGA solution receives change information from the source system depends on the integration specifications. It may only receive change information relating to a specific user, or it may receive updated information for all active users and conduct a comparison so that all changes are detected. 

Based on the change information it receives, Matrix42 IGA solution generates the relevant new attributes and/or updates this information to the directories. An email notification about the user information changes is sent to all relevant parties. If user has manual access rights, the application admins are notified of the changes. 

If IGA Automated Rules are in use, any access rights that the user is granted automatically are updated and provisioned to the directories. 

Off-boarding leavers

When a user's employment is ending, Matrix42 IGA solution receives the relevant information from the source system via integration and the removal processes can begin. 

At 00:01 on the day after the user's employment terminates, all IGA Accounts are disabled. Based on time limit settings, email license groups are removed and all group memberships are removed. 

The user's IGA Accounts can be moved to another place in the directory, or removed permanently (based on time limit settings) with only audit information retained in Matrix42 IGA solution. 

In addition to its provisioning and data import capabilities, Matrix42 IGA solution has multiple different interfaces for integrations. Matrix42 also offers Integration as a Service (IaaS). 

Matrix42 Integration Service

Matrix42 Integration Service (EIS) is an Integration as a Service (IaaS) solution delivered from Matrix42's cloud. Matrix42 consultants manage the planning, development and monitoring of integrations. Both cloud and on-premises systems can be integrated with Matrix42 systems via EIS. EIS has a wide range of technical capabilities for retrieving information for handling: for example from APIs (REST/SOAP), disk (FTP/SFTP/local files), or databases (e.g. MySQL, PostgreSQL, MS SQL Server). Various filetypes can also be handled (e.g. CSV, JSON, XML). 

Secure connections are used for all integrations and the APIs published by the platform all require authentication. EIS includes multiple ready-made connectors for different applications.

In Matrix42 IGA solution implementations, EIS is used for example when integrating to HR management systems, other ticketing systems, Physical Access Rights applications, healthcare solutions, etc. 

Web API and Matrix42 Query Language (EQL)

Matrix42 Query Language (EQL) is used to query data from Matrix42 IGA solution. Web API can be used to integrate Matrix42 IGA solution with other systems; for example with your own integration platforms.

REST API

REST (representational state transfer) is a standard / architecture style. REST API is an integration interface for Matrix42 IGA solution, with read / write access to data (data cards).

Example integration options

Matrix42 provides flexible integration options. Here are three (3) examples of possible integration implementations. 

Example 1: Using Matrix42 Integration Service:  

Example 2: Using Matrix42 Integration Service and a customer's integration platform:

Example 3: Using a customer's integration platform:

Organizations across industries increasingly need to streamline re-certification of identities and their associated permissions, due to security threats and/or government guidelines. Traditionally this is managed using MS Excel, email or exports from AD, involving many hours of manual work and a high risk of errors.

IGA automates the re-certification process, generating approval requests for managers to accept or reject. This means that all access rights can be re-approved efficiently on a regular basis. The most critical permissions can be prioritized if required, such as admin access rights, database access or financial information access.

Outcomes of this use case include:

• A clear process, with all approvals in one place
• Improved security
• Cost savings from reduced manual work and elimination of human error

The IGA Re-certification data card is used to create re-certification requests, meaning either that a user's current access rights are reviewed and approved as a part of recurring re-certification request, or that a particular IGA Entitlement is individually re-certified.

In many organizations, users' personal information is scattered across multiple IT systems. Such organizations often need a single “system of truth” they can rely on to view user identities, access rights and related information.

IGA Identity Storage data cards create a single repository for all user identities. Each user has only one identity stored in IGA Identity Storage, with all of their accounts, work periods, access rights and relations to other entities (apps, etc). Any updates made in HR systems integrated with Matrix42 IGA solution will automatically update IGA Identity Storage. IGA admins can always view the current status of access rights for compliance purposes. 

Outcomes of this use case include:

• Improved regulatory compliance
• Cost savings from simplification of personal and sensitive data management
• Improved security due to reduced risk of error

All users can be found in IGA Identity Storage, whether they come from the source system, from another application, or from Matrix42 Self-Service Portal. 

All relations to the user can be viewed from the Identity Storage data card and all fields are automatically updated. If there is an exception during user creation or update, an IGA Admin Task is created to allow an IGA admin to manually intervene. For example, if the user's email address cannot be determined, an IGA Admin task is created to allow an IGA admin to add the email address manually. When the task is saved, the user creation or user update workflow proceeds to provisioning. 

Personal information

Employment and additional information

Generated attributes

All of these attributes are generated by Matrix42 IGA solution, but the required attributes depend on which directory is in use. 

Organizations sometimes need to audit user access to applications that handle confidential or sensitive data. If the organization does not have a reliable way of identifying high-risk users, it may resort to random, ad-hoc or manual selection methods, which may result in some high-risk users being overlooked.  

 

Matrix42 IGA solution can automatically detect applications that have multiple high-risk entitlements, or users who have access rights to multiple high-risk applications. 

The risk level calculation service allows IGA Admins or Entitlement/Application owners to view and manage risk levels. By selecting Risk Level for IGA Entitlements, the user's risk value is automatically calculated. The risk level can then be viewed from the user's IGA Identity Storage data card or from the Application data card. 

Outcomes of this use case include:

• Improved security
• Prevention of errors and gaps in risk audits

Risk level view in Application data card:

Risk level view in IGA Entitlement data card:

Sample view for audit users based on user risk level: 

Organizations often over-provision users with access to applications or systems that they do not need, leading to overspending on unused licenses. Organizations are also often paying for named licenses for accounts that have been deactivated.

Matrix42 IGA solution can help you identify and address these challenges with ready-made reports and views for IGA admins, available from day one of go-live. Additional reports can also be easily created. IGA admins can choose whether or not to make these reports available to other users. 

Matrix42 IGA solution provides multiple options for reporting and auditing current and historical information related to users and their access rights. 

Features that support the reporting and auditing of access rights include the ability to record and report over-provisioned users, orphaned accounts and other common issues surrounding many systems. When an audit is required, Matrix42 IGA solution can simplify and streamline the process in multiple ways. For example, it allows managers or auditors to view the information they need as a list or graph using the visual analyzer tool. 

Matrix42 IGA solution also includes several other options and features to simplify the auditing process even further:

1. Views

Matrix42 IGA solution contains ready-made views for all data cards. The IGA admin can sort, add and remove columns from the view. Modifications can be saved to the IGA admin's own personal view, making reports easily accessible whenever they are needed. Views can also be exported to MS Excel. 

Views can contain complex conditions that can be used for reporting. Different graphical views are available to aid analysis of the results. 

2. Dashboards 

Matrix42 IGA solution allows dashboards to be created, containing 1 - 9 different views or reports. 

IGA admins can drag and drop existing views to the dashboard. They can choose whether a dashboard is published to their own personal view or published to other users. 

3. Data cards

IGA data cards are used to report current status: for example of a user's access rights or group memberships.

IGA Identity Storage is used to report the current status of all relations to a user's identity. 

IGA Entitlement is used to report the current status of group memberships.

IGA Business Role is used to report the current status of business role memberships.

4. IGA Access Right records 

IGA Access Right Records are created each time there is change in a user's access rights, or if information relating to access rights is changed. 

IGA Access Right records are mainly used for auditing historical information. All of the reporting capabilities are available for historical reporting. 

 
Organizations need to be able to create new entitlements and update existing ones in an easy and efficient way, with flexible definition and management of approval chains, and assignment of application ownership. They also need to be able to audit any changes or updates to approval chains, entitlements or owner information.

Matrix42 IGA solution makes creating and auditing entitlements simple by providing managers and owners with an easy-to-use interface and traceable records for every change. 

In Matrix42 IGA solution, IGA Entitlement is a single access rights group with four possible types:

• Normal: for example, a security group or manually-provisioned group
• Physical: a group related to physical access rights
• Privileged: a group related to admin permissions
• Technical: for example, a service account

IGA Entitlement is the most important data card in Matrix42 IGA solution. It is also an important part of other processes that rely on information found and stored in IGA Entitlement data cards. 

An IGA Entitlement is a group that is either:

• Automatically read from the relevant directory via Matrix42 Provisioning Engine
• Automatically read from the application via integration
• Automatically created using IGA data import functionality
• Manually created by an IGA admin

The entitlement can be provisioned automatically to users or added manually by IGA admins (or other application admins) or it can be combination of these two options, which means that a group connection is made automatically but some manual tasks are also required. 

Attribute information

1. Entitlement information

The Entitlement information class allows an IGA admin to manage the general information relating to the entitlement. 

2. Directory-related information

When entitlement information is automatically received by Matrix42 IGA solution, any directory-related information is automatically fulfilled. Content can vary between directories, and you can define which information is read from the directory.

Directory-related information is also used when IGA Entitlements are read from an application via an integration (for example via integrations made using Matrix42 Integration Service).

Risk Calculation

Risk calculation is used to calculate a user's risk level based on their active access rights. High-risk users can be re-certified or audited more often, for example. 

Relations

The Relations class concerns information relating to other functions and their current relations to users. Relation information is shown only when there is information to be shown, so empty fields do not appear. 

3. Approval and Ownership information

An IGA Entitlement can have three (3) types of owner. Owners can only see information related to entitlements that they own. 

4. Self-Service Portal information


IGA Entitlements can be published to allow end-users to request access rights from Matrix42 Self-Service Portal. Alternatively, access rights can be provided via (for example) IGA Business Roles or IGA Automated Rules. 

IGA Entitlements can be published in default or ready-made request catalogs, or by creating custom catalogs as services in Matrix42 Self-Service Portal.

In many organizations, internal and external users have to request access rights individually, often choosing manually from among tens of apps, or even more in larger enterprises. 

The IGA business roles use case enables easier management and automation of groups of entitlements or access rights. Users can request a business role from Matrix42 Self-Service Portal, and will automatically gain all of the related access rights once the business role has been approved for them.

Outcomes of this use case include:

• Cost savings from reduced manual work
• Reduced security risks from avoiding human error

IGA business roles can contain IGA entitlements or sub-roles. They can be made available to users via Matrix42 Self-Service Portal request catalogs, or added to users using IGA Automated Rules. 

IGA business roles can be role-based or organization-based, or they can be created based on your own specific definitions. 

Attribute information

1. Business Role information

The Business Role class is where general information for the business role is defined.

2. Role content

The Role content class indicates which IGA Entitlements or Sub-roles are included in the business role.

A provisioning time must be indicated for any updates to Role content. When the provisioning time is reached, workflow will validate all changes and update them automatically for users who have the role activated at that moment. 

Approval and Ownership information

3. Matrix42 Self-Service Portal information

IGA Business Roles can be published to Matrix42 Self-Service Portal where they can be requested by end-users. Alternatively, business roles can be made available via (for example) IGA Automated Rules. 

IGA Business Roles can be made available in request catalogs by publishing these catalogs as services in Matrix42 Self-Service Portal. 

4. Relations

The Relations class concerns information related to other functions and their current relations to users. Relation information is shown only when there is information to be shown, so empty fields do not appear.  

Segregation of Duties (SoD) is called toxic combinations in Matrix42 IGA Solution. It is used to mitigate risks arising from too many IGA entitlements being added to one user simultaneously.

Segregation of Duties (SoD) is a basic building block of sustainable risk management and internal controls. The principle is based on distributing the critical functions of a key process among more than one responsible person or department. Without this separation of duties, the risks of fraud and error become far less manageable.  

An end-user can request access rights (and a manager can approve requests) that produce toxic combinations. But in Matrix42 IGA solution, such access rights are never added to the user. Instead, depending on your preferred procedure, a Security Officer or Manager (or another designated user) is notified of these attempts. 

An IGA toxic combination can either be:

1. Forbidden

This means that two or three (2-3) IGA Entitlements create a combination of access rights that may be authorized but needs to be monitored carefully. IGA admins are notified of the combination and an IGA Re-certification Request can be created to enable more frequent reviews. 

2. Denied

This means that two or three (2-3) IGA Entitlements have been requested that are not allowed to be active at the same time. If these entitlements were approved, it would create too high a risk. 

Attribute information

Only a minority of organizations automatically update a user’s access if the user's role changes. As a result, users often end up with many more access rights than they need for their day-to-day work.

Matrix42 IGA solution allows you to define rules based on information about organizational units, cost centers and job titles. For example, a rule can define which business roles / job titles get which access rights. The access rights that have been defined for a role are provided automatically when a user joins the organization in that role.

Outcomes from this use case include:

• Cost savings from manual task automation (users, managers, IT admins, project managers, etc) 
• Reduced security risks

IGA automated rules are used for automatically granting IGA entitlements or IGA business roles to users based on their contract information.

IGA automated rules are more commonly known as attribute-based-access-control (ABAC), role-based-access-control (RBAC), or organization-based-access-control (OrBAC). They all are covered under IGA automated rules. 

IGA automated rules are related to organizational data received automatically from source systems. In some cases, IGA admins manage organizational information manually in the relevant data cards. 

All of the information used for creating automated rules comes from the Organization, Title and Cost Center data cards. We highly recommend that you automatically update information to these data cards. 

Attribute information

Organizations often find that user information from HR systems and account information from AD or Azure AD do not match. Manually identifying these inconsistencies is difficult and costly, which means that many unused or orphan accounts go unidentified.

With this use case, Matrix42 IGA solution combines user and account information to automatically identify users whose HR and AD info do not match, and flags any mismatches in a report. The connection between user and account is only created following confirmation after the issue has been flagged.

Outcomes from this use case include:

• Improved security, because all accounts are owned by an identity defined in IGA
• Cost savings from identifying and removing unused licenses
  
   

The IGA Set Identifying Information data card is used to create matches between users found from Identity Storage data cards and user accounts found from IGA Account data cards. 

This use case runs continuously, but is particularly useful in go-live situations when data is read to Matrix42 IGA solution for the first time. After data has been read from the source system and directory, the workflow compares attributes set in the IGA Set Identifying Information data cards. It then validates based on automation level whether to make the match automatically or request manual intervention by an IGA admin. 

IGA admins can always see in the views and reports if there are new matches or if a match could not be made, resulting in orphan accounts or users in Matrix42 IGA Solution. Notifications can also be sent to security personnel if required. 

Attribute information

Reporting strength levels and orphan accounts

Matrix42 IGA solution contains several ready-made reports and views for IGA admins to use. IGA admins can also create additional reports and views to monitor strength levels and orphan accounts. 

Example 1: Identity storage strength level

Example 2: Active orphan accounts

Organizations often need to define different user groups with different credentials without coding. In many organizations where there is no IGA solution, the IT support team handles this manually in the organization's directory. Information about group attributes is therefore not available in digital format, causing potential security risks and errors.

Matrix42 IGA solution provides templates for two key activities:

1. User group creation: Create a group (e.g. Matrix42 consultants working on X project) that is pre-populated with the required attributes: password format, email account type, etc. When a user belonging to this group is created, the process of adding them to the group is automated, improving efficiency and security across the organization. The same process is followed across departments for different types of user groups.

2. IGA Account management: Provide functionality to allow IGA Admins to change password or sync information between the directory and Matrix42 IGA solution. 

 
IGA Set Account Information
 
The IGA Set Account Information data card is used to define different types of user that need to be created with different credentials or if multiple directories are connected. 

The IGA Set Account Information data card is used for reflecting directory or application user account information. There can be multiple IGA Set Account Information data cards, and they can vary between directories or user groups: for example internal or external users, privilege accounts, etc.  

IGA Account 

The IGA Account data card is used for reflecting directory or application user account information. It is also used for certain IGA Admin actions, such as changing the account password. An IGA Account is automatically created when a user account is read from the directory or when a new user creation also includes account creation. IGA Account relates to the Person and IGA Identity Storage data cards.  

Each application must have its own IGA Account, where IGA Entitlements are related. IGA Account is typically based on information received from the directory or from a source system such as an HR Management System. 

Admin roles need to manage manual requests, exceptions, notifications and other daily tasks in a simple and efficient manner. When full process automation is not applicable, organizations still need clear SLAs. 

IGA links processes to task management to ensure clear SLAs and approvals, and provides an always-on view of current tasks and issues relating to identities.

This use case allows organizations to conduct the necessary manual work when an IGA entitlement needs to be manually provisioned. If there is an exception (error) in provisioning which requires manual intervention, this is also managed as an admin task. It can be assigned to an IGA admin who could, for example, re-send a request for provisioning.

IGA Administration Task data cards are used to manage the different type of administrative tasks that are automatically generated to IGA admins. 

Matrix42 IGA solution generates an admin task whenever there is a request or exception in workflows, integrations or provisioning. The actions required of the IGA admins depend on the task category. All IGA Administration Tasks contain a description of the expected actions. 

1. Exception

An exception is created if the workflow cannot create the required attributes, or if some mandatory information is missing such that provisioning cannot be accomplished successfully. The IGA admin can add the missing information directly into the IGA Administration Task. Once the changes are saved, provisioning will re-start.

2. Data exception

Matrix42 IGA solution will create an IGA Administration Task if it finds that information read from the directory does not match, or if changes to the user's account information have been made directly in the directory. Only manual changes made to a user's account information are automatically validated. If the change relates to a user's group memberships, an approval request is generated to the manager. 

3. Integration tasks

Matrix42 IGA solution will notify IGA admins of all exceptions relating to integrations (for example to the HR solution) by creating an IGA Administration Task. 

4. Manual access rights requests

If a user requests an entitlement from Matrix42 Self-Service Portal where the Entitlement type is manual or combined, Matrix42 IGA solution will generate an IGA Administration Task. 

5. Re-certification requests

If a re-certification request is denied and automatic removal is not selected, Matrix42 IGA solution will generate a removal request as an IGA Administration Task. 

Attribute information

IGA admins need visibility of entitlements within the request catalog to ensure that users see the services they are intended to see. IGA admins also need to be able to expand or remove entitlements from the request catalog, and audit any changes to the system.

With this use case, Matrix42 IGA solution provides: 

• A single catalog for all access rights requests, which can be expanded across the organization
• Flexibility to limit availability based on end-user type relation (internal or external)
• Management of request catalog entitlements via an easy-to-use graphical interface
• Creation of records of all changes and alerts related to critical instances (e.g. removal of an entitlement)

With Matrix42 IGA solution, organizations can improve security and the end-user experience by limiting and updating their available entitlements. 

With the IGA Manage Request Catalog data card, IGA Admins can create new categories in the access rights request catalogs published in Matrix42 Self-Service Portal. 

Access rights request catalogs play a very important role by allowing end-users to request access rights via Matrix42 Self-Service Portal. They are used to categorize IGA Entitlements and IGA Business Roles, so that end-users can quickly find the access rights they are looking for. 

IGA Entitlements and IGA Business Role data cards contain the information that is published in Matrix42 Self-Service Portal. 

Example of IGA Request Catalog relationship to Matrix42 Self-Service Portal

Data Card information: 

For security purposes, organizations need to control physical access to premises, assets and keys. However, physical access must be easy to manage, otherwise problems can arise when users cannot gain access to facilities they need to carry out their work. 

This chapter describes how IGA Admins can manage physical access rights and their visibility in the request catalog. This functionality helps organizations to keep workers safe and protect the business from risks arising from unauthorized entry.

NOTE: This chapter is about IGA Admin functionality. For end-user functionality (request/remove physical access rights, change PIN code, report missing badge, etc.), please see the Matrix42 Self-Service Portal chapter. 

Physical access rights relate to access to facilities like buildings, doors and rooms. Permissions can be assigned automatically based on criteria like organizational unit, job title and training information. When a user's employment ends, physical access rights can be removed and any badges collected and destroyed. 

There are three ways to manage physical access rights in Matrix42 IGA solution: 

1. Via a directory connector (Matrix42 Provisioning Engine). If the physical access management solution is integrated to the directory, user accounts and groups can be provisioned in this way.

2. Via direct integration between Matrix42 IGA solution and the physical access management solution. However, file-based integration may not be suitable if the solution needs to work in real time, especially if a lot of changes need to be made to physical access rights during the working day. 

3.  Via manual provisioning. If directory-based provisioning or direct integration are not possible, physical access rights can be managed manually. This means that when a new access is requested (such as during onboarding or offboarding), the request is sent as an IGA Admin Task or via email to the admin user of the physical access management solution. 

In all three cases, if a physical access card or badge is required, selecting the IGA Entitlements provisioning type will allow the relevant notifications  to be combined and sent for new card/badge creation or removal.

The IGA Admin manages physical access rights using the IGA Account, IGA Entitlement and IGA Request Catalog data cards. Physical access rights can also be added to IGA Business Roles and assigned automatically using IGA Automated Rules. IGA Admins can create toxic combinations and enhance security by ensuring that users with physical access rights are re-certified more often using the IGA Re-certification data card. 

IGA Entitlement type: Physical

IGA Account type: Physical 

Organizations need to control elevated or privileged access rights and permissions for users and accounts. For example, every organization that uses Active Directory (AD) has domain admins who can carry out any task in AD and can potentially access any information in the organization. 

A process is needed to manage activities relating to higher-level accounts, such as requests and approvals, without the need for full-blown Privileged Access Management (PAM) capabilities such as recording or password vaulting. 

NOTE: This chapter is about IGA Admin functionality. For end-user functionality (request/remove privileged account/accesses, activate privilege accesses, etc.), please see the Matrix42 Self-Service Portal chapter.

Matrix42 IGA solution provides services for requesting privileged account/accesses. These include directory-related admin accesses as well as admin functionality for marking privilege accounts and accesses, and publishing them in the request catalog. These capabilities improve security by allowing privileged accesses to be revoked based on user lifecycle management and by allowing re-certification requests to be carried out frequently. 

There are three ways to manage privileged accesses in Matrix42 IGA solution:

1. Via a directory connector (Matrix42 Provisioning Engine). If privileged accesses and accounts are located in a directory, they can be managed in this way. Note that this may require Domain Admin-level accesses to a relevant service account, for example an account used for writing data to Active Directory. 

2.  Via direct integration between Matrix42 IGA Solution and the target system. Privileged accesses can be managed in this way if both the integration and the target system support it. 

3. Via manual provisioning. If direct integration or directory-based provisioning are not possible, privileged accesses can be managed manually.  This means that when new privileged account or access is requested (such as during onboarding or offboarding), the request is sent as an IGA Admin Task or via email to the admin users responsible for managing access to the target systems. 

The IGA Admin manages privileged accesses using the IGA Account, IGA Entitlement and IGA Request Catalog data cards. Privileged accesses can be also added to IGA Business Roles, and IGA Admins can enhance security by creating toxic combinations and/or using the IGA Recertification data card to ensure privileged accounts are re-certified more often. 

For security reasons, privileged accesses are never active unless a Manager has requested the privileged account and accesses for a subordinate, the necessary approvals have been given, and the user activates the relevant accesses from the Self-Service Portal. 

IGA Entitlement type: Privileged
 

IGA Account type: Privileged

Example IGA Re-certification request

This chapter describes how IGA Admins can manage technical accounts. These accounts are used for communications between applications; for example when one application needs to give another application permission to read and write data. Such accounts do not relate directly to users, but are still owned and managed by users. 

Technical accounts and accesses are managed separately from the user lifecycle management of the account owner. If the owner is to be offboarded, for example, account ownership must be transferred to another user so that the organization is always aware of who owns technical accesses and which application(s) they relate to. 

IGA Admins can manage technical accounts and accesses using the IGA Entitlement and IGA Account data cards. 

IGA Account type: Technical (Note that the relation is not to a person but to an application and an owner) 

In larger organizations, intranet access rights are often assigned to different organizational units (teams), which are created and managed as groups in AD. IT admins frequently have to manually create or update information relating to these organizational units. 

This chapter describes how IGA Admins can create, update and remove IGA Entitlements, and thus reduce the workload on IT admins. 

NOTE: This chapter is about functionality for IGA Admins. For information about functionality available to end-users, such as requesting or modifying entitlements, please see the Matrix42 Self-Service Portal chapter. 

There are four ways to manage the entitlements lifecycle in Matrix42 IGA Solution:

1. Automatically via a directory connector (Matrix42 Provisioning Engine). If groups are located in a directory, they can be created, updated and removed automatically.

2. Automatically via direct integration. If groups are located in an application that is integrated with Matrix42 IGA solution, and that application supports group creation, then updates and removals can be automated.

3. Manually. If automated methods are not possible, change requests can be sent as IGA Admin Tasks to the relevant application admins for manual implementation in the application.

4. Using IGA Data Import. This capability imports IGA Entitlements, and if automation is possible, the IGA Admin can start provisioning them to the relevant directory or application. 

The IGA Admin manages the IGA Entitlements lifecycle using IGA Entitlement data cards. 

The IGA Admin can fill in the required directory or application-related information when creating a new IGA Entitlement data card:

The IGA Admin can update existing IGA Entitlements by selecting "Update" in the Status field and entering the new information. IGA Entitlement and directory or application group are identified with a unique ID (such as ObjectGUID in AD). 

Matrix42 IGA solution is built on the Matrix42 Service Management platform. It can be installed in Matrix42's dedicated cloud or as a private cloud solution. 

Matrix42 IGA solution always contains Matrix42 Self-Service Portal, which allows end-users to make Identity and Access Management requests (and other types of request, if other Matrix42 solutions are also used). 

We will agree the solution architecture with you based on your specific requirements before deploying Matrix42 IGA solution to the Matrix42 Cloud environment. 

Matrix42 IGA solution uses several capabilities of the Matrix42 Service Management platform, which are common to all Matrix42 solutions. 

Workflow engine

Automation is an important business enabler. Matrix42 IGA solution employs an extremely powerful and versatile workflow engine to enable easy in-house process automation. The transit-map style design of our workflow engine allows organizations to model business processes quickly and easily. The workflow engine is completely integrated within our solution and helps organizations to easily design, implement and review process or approval chains. Matrix42 IGA solution has a range of pre-configured workflows, enabling it to be implemented quickly and easily. 

The script execution node allows python scrips to be added to a workflow. These scripts can manipulate values in a workflow template but not values in other templates. The script execution node can be used for more complex tasks such as generating random numbers, calculating the difference between times/dates, or other calculations.

Email notifications

The email notification node allows messages to be sent to a determined user. Messages can be sent in HTML or plain text format and include dynamically added values such as incident number, user name, or current status.

Matrix42 IGA solution contains a visual analyzer tool that is available to IGA admins and which can be opened from any data card that has relations. 

Visual analyzer is continuously available and an IGA admin can modify the view by choosing or removing data card relations, selecting extended views with more information, or moving boxes around the core. 

Visual analyzer can be used for activities like role mining, by giving IGA admins a clear view of all relations between data cards, applications, integrations, business roles, etc. 

Matrix42 Provisioning Engine is used for provisioning users, groups and other objects to the directory. 

Matrix42 Provisioning Engine can read data from any of the following: 

• Active Directory (AD)
• Azure AD
• OpenLDAP
• IBM LDAP
• FreeIPA LDAP
• 389 LDAP

 Matrix42 Provisioning Engine can write data to any of the following: 

• Active Directory (AD)
• Azure AD
• OpenLDAP
• IBM LDAP

More information about Matrix42 Provisioning Engine is available here. 

For Matrix42 IGA solutions own access management Matrix42 uses Matrix42 Secure Access component. 

It supports following authentication methods:

• User Federation
• ADFS
• Azure SSO
• SAML 2.0
• OpenID
• Local users

For strong authentication Matrix42 provides:

• Two-Factor Authentication (2FA)
• Bank ID identification, through our partner Signicat
• One-time Password (OTP), through our partner Signicat

Read more about:

Matrix42 Secure Access