IGA Use Cases: Visibility and Reports

Last modified 08 Feb 2024 16:58 +01:00
Table of Contents
This page is a work in progress.

The IGA system should provide useful IGA information from the data. Especially for external customers (auditors / security officers / business).

The IGA reporting is designed in detail here. The pages are not yet synchronized and not all use-cases are covered. This is work in progress.

1. Reporting technology

1.1. Analyze reports in database

Scenario

User wants to utilize known analytical tool for analysis of prepared reports. He wants to analyze the data in the reports and potentially combine the data or enhance it with additional data from outside.

He does not want to repeat each time operation of importing new report from csv file. Just want to have environment prepared and refresh it with the data from new report.

Actors

Reports are configured by IGA engineer or IGA administrator - he can be called as report designer for this use-case.

Typical user of the report for such analysis is Role manager or IGA administrator/IGA engineer from internal IGA team. From external environment, the Security officer or IT Auditor are the users for this scenario.

Motivation

All data shall be exportable to csv or created into a reporting database (tables / materialized views) - where the data may be analyzed.

The reporting database is useful solution for preparing pre-computed information out of the data in IGA solution. Authorized users then can use their analytical tools to obtain results they know and need in efficient and repeatable way. They can avoid daily repeating preparation of data from csv files.

Working with reports require computing power too. Having the reports saved in independent database will save resources for provisioning and self-service operations and avoid affecting overall midpoint performance.

User Story

  • Report designer configures the report to provide results to reporting database - e.g. by creating table or refreshing materialized view for the report.

    • He defines whether all data to be replaced or new data will be added (e.g. new csv file or added rows to reporting results)

    • He can schedule it to run in specified times.

    • He defines access to the report data.

  • User configures his analytical tool to connect to reporting database and open the report results.

  • User perform analysis of the report to get information out of data in the report. If necessary, enhances the report data with additional computation. Saves the configuration.

  • Next time, the user, just opens the analytical tool and refreshes it with the actual data. No load from csv, no data preparation is needed.

Note: Analytical tools may start with Excel connected to the reporting database via ODBC, or it can be any other BI tool - just depends on user needs and options.

1.2. Scheduled reports

Scenario

  • Report user doesn’t want to wait for preparation of the report.

  • Report user need to have reports from the same time each day to have comparable results.

  • Report user needs to have consistent reports from each day (week) for analysing trends over time.

  • Multiple users are using the same report - it is better use one report than building individual report for each user.

Actors

Report user could be Role manager, Security manager, any business manager or IGA administrator. Any user, that should have access to reports. Report designer is typically IGA engineer or IGA administrator.

Motivation

Computing of report results may take time and resources - especially in large environments. User does not want to wait to the report to be finished.

Users often prefer to have data from specific time over last minute data - e.g. when comparing results of reports over time.

If reports are used by multiple users, then the preparing reports for all of them can significantly save system resources over running the report for each user.

On the other hand, scheduling and precomputing all reports even when these are not used could waste the resources. The IGA engineer / IGA administrator should decide which reports to schedule and when.

User Story

  • The report designer configures new or existing report to be run in specified times - via UI during report configuration.

1.3. Option to run SQL in reports

Scenario

An report designer needs to prepare report that is not supported by actual midpoint capabilities, or is being performed over large sets of data and could not be computed in acceptable time.

Actors

Report designer is typically skilled IGA engineer.

Motivation

For some specific reports and specific environments it would be usefull if an report designer can design a report just as a SQL select over the internal midpoint structures.

Such reports may not be using standard midpoint design (collection), but bypassing internal processing of midpoint structures may increase speed of report generation and move some reports over large data sets from impossible to possible area.

Such type of report generation should relate only for "normal reports", not import reports. No data modification may be allowed on database level below midpoint’s referential integrity checks.

User Story

This situation may be solved in 2 different way - within midpoint, or via external SQL query.

Using midpoint methods, the report designer prepares new report definition and configures the query not via collection, but using SQL query. The report is set up to perform output to database (see use-case Analyze reports in database).

If the report is configured via external SQL query (e.g. preparing materialized view or table in reporting database), then the query may be scheduled to run in specified time. The configuration is performed outside midPoint.

In both cases, the report results are the same - the table or materialized view in reporting database. End users are using their analytical tools to analyze the report data.

2. Visibility of single objects

UI should also display the details of individual objects in business language. Following use-cases should be implemented:

2.1. Role content - in business readable form

Scenario

  • Helpdesk operator wants to know what the specific application role does. What objects it is managing. e.g. He needs to verify that the role manages specific group in LDAP, or whether the role provides access to the application he thinks.

  • Application engineer wants to review the roles that are managing access to "his" application. He just want to open the role and check "what the role does".

Actors

Application engineers, helpdesk operators, security officers, auditors, …​ - the "technical users".

Motivation

Display the role definition to application engineers, helpdesk operators, security officers, auditors, …​ - the "technical users" who have knowledge about identity management, provisioning, roles or technology infrastructure, but don’t know specific midpoint terminology.

Provide the role configuration for fast review.

User story

  • Technical user opens the role in UI, switches e.g. in "business summary tab", and can see the configuration of the role in easily readable form.

    • Application role can have the configuration display divided to "business attributes" visible to end users and its technical configuration that is available to the "technical users".

Example for displaying the content and functionality of the roles to business users can be found in definition of application role and business role.

Inducements of services may have defined relations. These relations represent business description of the access in the service (application or application resource).
The relation of the inducement should be visible too. This is missing: MID-8034, but in business display it may be displayed in different way.

2.2. User’s history - in business readable form.

Scenario

IGA administrator or Helpdesk operator is troubleshooting some issue with an user. He is looking for information what happened to the user and when. He needs to get fast overview what happened to the user directly from the view.

The fast overview saves time because the admin does not need to open each delta one-by-one.

Actors

IGA administrators, helpdesk operators. Sometimes even user himself.

Motivation

We have user’s history, but it is hard to get information out of it. From the view we can see just that the user was created or updated in particular time + channel and outcome of the operation. Each event must be opened and reviewed to see what happened to the user. This is inconvenient and time-consuming particularly if there were many modify operations on the user.

Operator needs to get better information what happened in each operation directly from the view.

User Story

  • Operator opens the user history, selects the time constraints, and can see each event enhanced with its business description. The history view contains additional columns for:

    • operation - e.g. Created / Modified / Disabled / Enabled / New assignment(s) / Assignment(s) removed / Assignment(s) modified

    • attributes - it would be nice if we can see list of attributes that were updated (this must be handled carefully - maybe just list 3-4 and if more was updated, then just display "multiple attributes were updated"). The same should be displayed for assignments.

      Operational attributes should not be included here, or included on request/checkbox.

    • attribute values (optional ?) - this needs to be carefully considered - not to blow out the view by large amount of data - the view must still stay readable. Detail data are still in deltas.

    • assignments - here names of assignments that were added or removed or updated. Constrains are the same as with attributes (not to display too many - view must stay to be readable).

  • Reader can search in the history - somehow easily. It would be ideal, if the user could be able to find when particular attribute was changed to/from particular value using AXIOM and the same for assignments.

    Of course, this level will require advanced users, but when the operator or admin knows the query, he can be very efficient.

This may require some global definiton of priority user attributes that will be displayed in the view.

2.3. What is the access of the user ?

Scenario

IGA user wants to see where (to which application) the particular user has access. IGA user may try to check whether the particular user has access to particular applications. For better understanding he needs also the information why the user has the particular access.

Actors

Anybody who need to see access of the particular user. It may be the end-user himself, the user’s manager, IGA or helpdesk operator, security officer, …​

Motivation

Users of IGA solution need business view of the particular user access.

This should be the basic description of the user access - displayed both in flat (user → applications) and in hierarchy with more structure for better analysis.

This is the subset of the report "who has access to what and why" - limited to the particular user. It should be visible directly from UI.

As there may be hundreds of roles and applications assigned (directly or indirectly) the functionality to easily review and search or filter the displayed data in UI is needed for good user experience.

User Story

User can display his access in view the form of:

  • User access

  • User access by application

  • All direct and indirect assignments

Structure and details to all these views are described in Displaying user access.

2.4. Who has access to the application and why ?

Scenario

Application owner wants to know who has access to his application. For the users he would like to know by which roles it was assigned - what is their level of access.

Security officer analysing application access needs to see users.

Actors

Application owner or engineer, security officer during investigation of some security incident. IGA operator supporting application engineers while some app reconfiguration.

Motivation

This is the opposite direction as in the previous use-case. We need to list users and roles on the application object. Just this is not enough. For better analysis, IGA user should know also why each user has the application. The why means by which application role the application (service) was assigned.

User Story

IGA user opens the application object, and can list users that have this application (service) assigned. This view can display just users. Additional view should display also relation user → application role to identify also level of access for the user.

Also he can see the list of application roles that enable access to this application. This list may be just list of application roles related to the application.

As in previous use-case, the view should be searchable to find users directly from the view.

2.5. What is assigned by this role ?

Scenario

IGA user opens the business role and wants to know all roles and applications that will be assigned by assignment of this business role. Not only "directly" but also "indirectly".

This information should be displayed in UI. Something like "All direct/indirect inducements".

Motivation

This is partial display of role hierarchy (use-case hierarchy of roles - the role model) just for the one opened role. It is top-down traversal through role inducements.

As services may be induced in the roles too, the same information should be provided also for services.

It should be configurable what role archetypes will be displayed for different types of users. E.g. metaroles will not be displayed for end-users.

2.6. Where is this role included ?

Scenario

IGA administrator or role manager wants to know all (business) roles where the specified (application) role is included as an inducement. E.g. while decommissioning or modification of an application role, he wants to know what roles will be affected by the role removal ro modification.

Motivation

Finding all business roles that contains specified application role is useful in some role or application maintenance tasks. This information should be displayed in UI.

This is partial display of role hierarchy (use-case hierarchy of roles - the role model) just for the one opened role. It is bottom-up traversal through role inducements.

As also services may be induced in the roles, the same information should be provided also for services.

3. Big picture over assignments

IGA users need to have good overview of the data in the system. This overview is provided by reports.

3.1. Who has access to what and why ? / Main IGA report (assignments report)

The basic information that IGA environment should provide is to show who has access to what. And what is the reason that this access is assigned. This information should be provided in the form of report.

In this report the IGA user may see all assignments (direct+indirect) of defined set of users. All together with application access specification and possible with some constrains. It is report version of the use-case What is the access of the user.

This main IGA report is described in this page.

3.2. Who are the high risk / privileged users ?

This use-case needs more detail work. Will be developer later.
Scenario

Security officer or auditor wants to list privileged users od identify users whose access represent high risk (their access is very broad or are having access to .

Actors

Role manager, security officer or auditor - the actors who should involve risk of users (risk of their access).

Motivation

In risk based security approach, the security officers define and implement security controls adequately to the risk. If the roles can quantitatively set the risk of individual roles, then midPoint can calculate overall access risk of the user and can provide such users to the IGA user.

If the role can qualitatively explain that the access defined is privileged, then midPoint can calculate overall value of the user - whether he is privileged or not privileged.

User Story

IGA user can filter users based on the risk value computed by algorithm (e.g. just sum) of the risk of all roles the user has assigned - directly or indirectly.

The list of privileged users can be provided by report or just by selection in the users view.

3.3. Compare roles / orgs

IGA user (e.g. application engineer, IGA operator, role manager, helpdesk operator) wants to compare content of two or multiple roles and correct them accordingly.

The display of two roles in UI is useful during role cleanup procedures, or troubleshooting of some operational issue.

The report of multiple roles can be universally used while role configuration or data cleanup.

User Story

For the 2 roles comparison, the IGA user can display the roles side-by-side, or in two browser tabs and compare them. The display of the roles may be in business readable form or in actual display in UI.

If the IGA user wants to compare multiple roles, then the report may be provided with displaying the attributes, as well with assignments, entitlements and role members. The IGA user can select whether he wants to compare just attributes or additionally assignments, inducements or members of the roles in the report.

For the comparison report, the report user should define the roles to compare and what components of the roles to compare. Then the report should display the components of the role. Each column represents one element, each line represents role - or, when comparing assignments, inducements or role membership - each line represents one assignment.

In comparing assignments, inducements or role membership - only one such role component may be defined to avoid cartesian product of the lines.

The same solution should be implemented for comparison of orgs.

4. Big picture over roles

4.1. Role identification in each line of the report

When all assignments, inducements or role members are reported, then each assignment, inducement or role member should be in individual line of the report. The line should contain identification of the role.

This report configuration allows easier data analysis.

Motivation

Data in reports are often source for further analysis.

Old way of providing reports is that report should be well-defined before, then prepared in source system and provided in the form nice for view and reading by end-user. Often in pdf format. The reports are easy to read in small data sets. But are very difficult to read in large data sets and are not designed for further processing.

In typical organization the specification of reports in advance, configuration and communication with IGA operators (or even engineers) takes time and resources. Especially for ad-hoc reports.

For many cases, better way is having standard report available in the form that is suitable for additional data analysis, the report user can run default report, import it to his analytical tool and perform the data analysis. This way reduces/removes specification of the report and enable easier analysis of the data with tools that the end-user

Of course, the data may be provided only to authorized users.

Example

As an example, security officer needs all application assignments of people from specific department and analyses their access to identify excessive user access while investigating a fraud. Having all accesses and performing the analysis and filtering them ad hoc according the traces, investigation.

Original format - one line per user. All assignments in one line.

User Assignment

Adam Smith

App A:User
App B:Editor
App C:Administrator

Buster Blake

App B:Editor
App C:Editor

Clark Cooper

App C:Administrator
App A:User
App X:User
App B:Editor

Proposed report format - easy to process in analytical tools.

User Assignment

Adam Smith

App A:User

Adam Smith

App B:Editor

Adam Smith

App C:Administrator

Buster Blake

App B:Editor

Buster Blake

App C:Editor

Clark Cooper

App C:Administrator

Clark Cooper

App A:User

Clark Cooper

App X:User

Clark Cooper

App B:Editor

When such security officer wants to identify the roles that have 3 users in common it is easy to process the second report in the analytical tool and perform selection.

4.2. Hierarchy of roles - the role model

This use-case is displaing of the role hierarchy described here.

Role manager needs to see roles in hierarchy of roles based on inducements. To understand the structure and whole role model.

For particular roles he needs answers to following questions:

  • What is assigned by the role ? - Show role and all descendants (roles and services in inducements)

  • Where is the role included ? - Show roles and orgs, where is this role induced (with inducements to this particular role)

  • What application can be accessed by the role ?

Structuring of the roles from top level business roles, through application roles to detail metaroles is useful for Role manager for analysis of the role structure and organization. It is also useful for auditors or security officers for review of access that particular role or list of roles can provide.

This report should display the roles starting from top level business roles and including all (or specified number) levels of inducements.

Technically, it is hard to display role model in full structure and with good readability, because there may be thousands of roles and each role may contain dozens or even hundreds of inducements. Also, the roles may be duplicated in the role model display. It is natural as one application role may be included in multiple business roles.

To improve readability, the report user should be able to scope the report by specifying:

  • object types - e.g. display only roles or orgs. If orgs are included, then the assignment rules may be displayed.

  • archetypes - e.g. display only business roles (to have just structure of the business roles), or excluding metaroles out of reporting scope.

  • set of roles for analysis - only these roles will be analyzed. Recursively. Here he should define whether all descendants or all ancestors should be displayed.

  • maximum displayed level of the role structure - user may specify to displat only first or first two levels of role hierarchy.

As an example, the role model may be displayed in following structure.

Also, some additional information may be displayed for each role - role archetype, owner, count of members, …​

To provide whole structure of roles may be quite expensive operation in UI. Therefore, the report is a good option for this use-case. But, if only one role should be analyzed, then the UI may provide the information as well. The what is assigned by this role and where is this role included use-cases describe this situation.

MidPoint can already display role catalog by org tree. It is useful in some situation, but this catalog does not display the structure of the roles according the inducements.

4.3. Roles in organization units

Additionaly to the role model, the display of all organization units (orgs) that have roles induced should be helpful. It displays list of Role assignment rules - what roles are assigned to members of the organizational units.

Therefore, this should be displayed in individual view/report and not to mixed together with the role mode.

4.4. What accounts are created by roles? / What entitlements are managed by roles?

Scenario

A user wants to know on what resources are accounts created by assignment of the role. Or what roles are creating accounts on specific resources.

Actors

IGA administrator, Role manager

Motivation

The information may be needed during some troubleshooting or during analysis of roles. Examples:

  • IGA administrator is troubleshooting some issue with accounts on some resources and wants minimize the scope to specific roles acting with the resource

  • Role manager wants to organize the roles and identify overlapping roles (the roles that perform the same operations).

User Story

The users should run a report listing all (or specified set of) roles and collecting information of accounts and entitlements that are managed by the roles. The user then analyzes the report by his own means.

4.5. Identification of loops in role structure

There is possibility to define loops in role structure. Direct (Role A→ Role B → Role A) or indirect (Role A → Role B → Role C → Role A).

Such design is a logical error in role structure. Midpoint can handle it internally, but it is useful to identify such loops to correct the model.

This role design error may generate an infinite loop in displaying role structures or some other operations.

5. Other big picture views and reports

5.1. Comparison of role assignments (what should be) and actual representation on managed objects (what is)

This comparison should show the discrepancies among (specific) attributes or assignments of the users and their actual representation. It should not be automatically resolved - the discrepancies should be displayed in report.

The scope of the comparison may be defined by the resource, set of users or set of roles. It may be implemented as the "reconciliation report" for resources.

If possible, this report be designed to resolve the missing feature of Differential resources.

Business reason of this report

  1. In some environments the IGA solution may not be able to manage all systems (resources), these resources are to be managed manually. This report defines scope of work to review and correct the discrepancies.

  2. Automatic reconciliation and removal of the data may generate business issues. The report can provide details for preparation what will be changed and who will be affected for support staff.

5.2. What objects we are (not) managing on the particular resource

IGA user should see the set of objects that are managed or not managed on the resource - to define the scope IGA. This relates to users as well as entitlements.

Example

On LDAP system, the IGA system is managing all users except 5 listed and is managing membership of 100 listed groups out of 1000 group in the LDAP. The report should provide such information with lists of managed/ not managed objects.

Was this page helpful?
YES NO
Thanks for your feedback