IGA Administration
This article describes tasks, functionalities and responsibilities for IGA admins, in order to be able manage and audit identities and access rights. This article does not describe configuration instructions, instead all actions are made from admin/agent UI.
IGA admin is a new role to organizations who are implementing their first IGA solution. It is important to understand that administration work will need at least one to two persons in after the implementation has been completed. When said, it is equally important to knowledge that needed allocation for IGA admin work is highest right after solution has been taken into use and it gradually stabilizes into daily routines and allows time to be used also to another tasks.
IGA admin is different role than IGA configuration admin, and difference between these two is that the other one can access to configuration. Customer can decide if these roles are assigned to one person or if there is a need to keep them separate.
First Tasks
When IGA solution is installed, it works exactly as described in the use cases before customer specific configuration is started. Use cases related to IGA admin work are working out-of-the-box, which means that after data read has been tested in test environment, it is important to get data into production as soon as possible, since that will enable IGA admin to be able start first tasks and use ready-made reports to ensure data quality and fulfill needed information for work period and account management.
First Time Data Read
It is important to separate meaning of the first data reads compared to continuous data reads.
First data read is needed for ensuring that mappings and relations are established correctly and enable functionalities for IGA admins to start validating data quality and start building automation in the next phase.
Continuous data read is usually scheduled (like for example when reading directory data) and depending which if and what type of HR integration is implemented, data reads can vary a lot.
For the first data read customer needs to provide,
| Data | Description | Type |
| Accounts & groups (entitlements) |
Customer needs to deliver details for test and production directory connection(s). Scheduling is agreed together with customer.
Directory accounts are read to IGA Account data cards and groups are read to IGA Entitlement data cards. Cost center, organizational units and title data cards are generated to IGA solution based on all cost centers, organizational units and titles related to users. IGA Access Right Records are generated based on group-membership connections. |
Scheduled data read using native connector |
| Application list |
Is needed for IGA admin to able start fulfilling entitlement information, since each access right needs to relate some application/service/database etc.
Usually this is one-time import and after that application list maintained in IGA solution. It is possible to read application list with native connectors in case customer is storing it in another application. |
One-time import |
| HR-file (test users) |
This is required when HR integration is in the scope of the IGA delivery.
User related data is read to IGA Work Period data cards, and cost center, organizational units and title data cards are generated to IGA solution based on all cost centers, organizational units and titles related to users.
File is read to test environment.
Even if integration to HR solution is implemented with some other option than file-based integration, for the first data read customer needs to provide file with test users, and attributes needs to be consistent with production file. |
One-time import for first data read |
| HR-file (real users) |
This is required when HR integration is in the scope of the IGA delivery.
User related data is read to IGA Work Period data cards, and cost center, organizational units and title data cards are generated to IGA solution based on all cost centers, organizational units and titles related to users.
File is read to production environment.
Even if integration to HR solution is implemented with some other option than file-based integration, for the first data read customer needs to provide file with test users, and attributes needs to be consistent with production file. |
One-time import for first time data read |
Validate data quality
Data quality is base for all IGA use cases, and if data is not up to date it is impossible to build sustainable and reliable automation for any IGA use case.
IGA solution contains tools for validating data quality, and that is the most important and very first step in the IGA solution, but it is also important part of daily actions in case for example IGA solution cannot finalize processes because of missing/wrong information.
When data read happens, provisioning towards directory/directories is disabled. Provisioning can be started only when data quality has been ensured.
What IGA admin needs to do?
This task is related to data used in the organization, but as a example IGA admin needs to validate,
- Organizational related data is correct (organizational units, cost centers, titles etc.). Data cards are generated either based on data read from directory and/or HR solution.
- There is only one data card per organizational unit, cost center and title
- In case there are several, IGA admin needs to clean data, so that it is matching real organizational data.
- Persons and identities are related to correct organizational information
- There is only valid data
- There is only one data card per organizational unit, cost center and title
- Accounts are related to correct persons and identities
- Work periods related to identities, persons and accounts.
- IGA Access right records are generated correctly based on group-memberships connections in the directory
- In case there are quality issues with data read from HR, it needs to be fixed in the source system and re-run data read to IGA solution
How long this tasks will take time from IGA admin?
It is entirely depended on customers current status for data quality and information available in HR solution and/or directories how much time need to spend improving the data quality. Therefore, it is recommended to reserve also time from HR specialist to improve data, especially when information is received from the HR solution.
Recommendation is to reserve at least two (2) work-days for IGA admin to analyze data, but in case it is already recognized that data quality is low and will require lot of improvements, recommendation is to reserve five (5) to eight (8) work-days.
Work period and account management settings
Work period and account management information is mandatory to define into IGA solution, and IGA admin can easily change or create new set of rules to different user types.
Commonly these settings are defined at the beginning of IGA delivery, but in case for example there are changes in customers organization or need to grant more birth right etc. which means that occasionally IGA admin needs to also maintain these settings.
-
Work period management
- Contains settings example for
- Receiving users personal and employment related data.
- Settings for several work periods & accounts
- These settings are rarely changed, but in case for example there is new user type, customer needs to define new set of rules for the user type.
- Contains settings example for
-
Account management
- This contains settings for delivering (provisioning) user accounts and access rights (group-membership connections) to the directory/directories, like for example what kind of email address is generated for different user types and what birth rights are granted etc.
Build and Maintain
Common assumption is that when production usage is started, every process and use case is working and automation is running in full speed, but with IGA solution production usage starts with providing the tools to start building and gradually increasing the level of automation. What this means that, instead of doing role management in Excel's, it is done in IGA solution and after roles are build IGA admin can grant them by building automated rules or publish business roles and access rights to Self-Service for end-users to be able request them.
Building phase is biggest work for IGA admins, but further work is done needed IGA admin work decreases to maintenance level.
At the beginning IGA solution provides tools for IGA admins, and gradually when they are finishing tasks automation level increases and more services in Self-Service becomes available to end-users.
Building & maintaining automation
IGA admin has different tools to increase automation level, but it is important that building is made in correct order to ensure that needed data for each functionality is available.
| Use case | Building | Maintenance | Time needed |
| Manage entitlements | Everything in IGA solution is related to entitlements, which are reflecting one access read from the directory/directories (group), manual entitlements created by IGA admin or any other application access. Biggest mass usually comes from the directory groups, and IGA admin needs to fulfill information what cannot be read from the directory, like for example give friendly name & description. |
IGA admin work is needed when,
This task can be delegated to entitlement or application owner. |
When production usage stars, recommendation is to reserve at least 4 work-days, which will provide good start for IGA admins to continue fulfilling entitlement information. Total needed time is depend on customer current status for access right management, and as a guideline this will need weekly time from IGA admins, at least for 4 to 6 months. |
| Manage business roles |
Are collection of entitlements and those can be granted automatically to users by using automated rules or those can be published to Self-Service for end-users to be able request/remove them.
IGA admin can start building business roles immediately when solution is in production use, but it is recommended that entitlements has enough information and data quality is ensured before building business roles. |
IGA admin work is need when,
This task can be delegated to entitlement or application owner. |
Building one (1) business role takes few minutes, and provisioning time is depended on how much access rights are granted/removed. |
| Manage automated rules |
Automated rules are used for granting and removing entitlements and business roles automatically based on users employment information. Rule type can be continuous rule or one-time rule.
When new rules are created, or existing ones are updated or removed, IGA admin can preview provisioning changes, before actual provisioning is started.
|
IGA admin work is needed when,
Usually this task is not delegated to owners, whose access rights are involved in the rule. |
Building one (1) automated rules takes few minutes, and provisioning time is depended on how much access rights are granted/removed. |
| Manage request catalog |
Is visible to end-users and is guiding them to find and request correct access rights from Self-Service
When building request catalog it is important to involve end-users (users and managers) in to the planning process, since end-users are the ones using it.
This might take several iterations and IGA admin might need to change categorization based on end-user feedback. |
IGA admin work is needed when,
IGA admin or owner can define in which categories access right or business roles are visible from data cards related to these items, but IGA admin manages entire catalog and categories. |
Creating one new category takes few minutes and after that entitlements and business roles can be published into the category. |
Daily Actions
Daily actions does not mean that the task would appear every day, instead it means that there might be tasks which need IGA admin to interference in the process. Daily tasks are depended on customer settings and use cases enabled in IGA solution.
Instructions for daily actions
Below are listed and described functionalities and tasks, which are needed IGA admin to perform, as soon as they appear or when needed.
Daily actions are categorized in three (3) category, and if the scenario for the task applies to customer use cases, it is recommended to review these tasks daily.
Problem solving, these tasks are happening when there are issues with workflows, logic or provisioning.
Admin actions are depended on customer settings like for example if manual interference is needed during user creation or in case there are manual access right requests, reporting / auditing needs etc.
Data exceptions are situations when IGA solution is working correctly, but it cannot finalize the processes because issues with data like missing manager information etc.
| Task/ action | Description | Recurrence |
| Simulate data before provisioning |
This task is valid for user lifecycle management use cases, and it is recommended to set on (at least for a while) when HR integration is taken into use and after data quality has been ensured it can be switched off.
|
Admin action |
| Users with same name |
This is valid for user lifecycle management use cases, when customer requires that in name sake cases, both users will get prefix or suffix into unique attributes like email address.
|
Admin action |
| Unique attributes cannot be determent automatically for account management |
This applies in user lifecycle management use cases, where unique directory related attributes cannot be automatically generated and IGA admin needs to manually interfere in the process (like for example email address generation runs out of options).
|
Problem solving |
| Change primary work period |
This applies in user lifecycle management use cases, where user can have multiple work periods.
|
Admin action |
| Change primary account information |
This applies in account management use cases, where user can have multiple accounts.
|
Admin action |
| Re-run failed provisioning for user creation or update. |
This applies when user lifecycle management use cases are used.
|
Problem solving |
| Re-run failed service request for requesting or removing an entitlement |
This applies when provisioning fails during access right request/removal made from Self-Service.
Adding and removing group memberships happens on IGA Service request, if group membership provisioning is not successful (like for example there are connection, certificate, credential issues etc.), workflow will stop and create IGA Administration task data card.
|
Problem solving |
| Re-run failed IGA access right record |
This applies to several use cases, and IGA admin might need to do this when,
|
Problem management |
| Reporting and auditing | See own chapter for auditing and reporting. |
Admin action |
| Manual access right request |
When provisioning type is set to manual or combined in entitlement settings, and manual request to is selected to be team and IGA admin team is selected as team.
|
Admin action |
| Missing manager from access right requests/removals |
This applies in request / remove access rights use cases, when manager information is missing from requests requiring manager approval.
|
Data exception |
| Account management settings are missing |
This happens when IGA set account data card is missing and user information cannot be determent or provisioned to directory/directories.
|
Problem solving |
| User found from directory, but not from IGA |
This happens during user lifecycle management use cases, but it is part of governance use cases, especially for reporting user creations made off the process.
This situation happens only when, during user creation user account with same employee ID is found from the directory.
|
Data exception |
| Departing user information is not matching between IGA and directory |
This happens during user lifecycle management in departing user use case, and it is also part of governance use cases, since it indicates of situation where user account is active in the directory, when based on information IGA solution, user should be disabled.
|
Data exception |
| When disabled fails or moving to OU (departing user) |
This is related to user lifecycle management, especially to departing user use case, when customers directory is using OU-structure (like for example Active Directory AD).
|
Problem solving |
Reporting and auditing
There are 70-100 ready-made reports, views or dashboards for IGA admins, and needs for reporting and auditing varies on based on maturity level of IGA solution, like for example how long it has been used or in what phase implementation is ongoing.
IGA admin can edit, remove, re-organize, rename etc. ready-made reports, views and dashboards or IGA admin can easily create new reports, views and dashboards and save them for own usage or publish them to other users.
- After first data reads IGA admin has ready-made reports, views and dashboards for reviewing received data and ensuring data quality.
- When building and maintaining automation IGA admin will need reports like relations between business roles (role mining), request catalogs, automated rules, titles, cost centers etc.
- Daily administration tasks, are needed when doing admin actions or solving problems and data exceptions.
- Statistics reports will need some time to collect enough information for reporting like for example most used services, most requested access rights etc.
- Governance reports varies according to customer auditing requirements, and for example re-certification reports and security related actions are visible in Governance reports.
- Extended access right management reports contain information for example physical access rights, privilege access right management etc.
-
Review data reports contains information:
- What type of user, employment, account etc. related data has been received to IGA solution.
- It is mandatory for IGA admin to review all these reports, when data is received for the first time to IGA solution.
- In case the data is not valid or up to date, IGA admin needs to make changes to the data.
- In weekly/monthly basis, it is recommended to review at least reports for orphan accounts and other security related reports (or move them to, for example, Daily administration reports).
- Review HR and/or directory data
- Analyze data before provisioning reports are needed: when IGA admin is simulating received data before it is provisioned to directory/directories.
-
Role mining reports are used for creating business roles and automated rules. IGA admin can review, for example:
- Users with same title, cost center or organizational unit.
- Accounts with same entitlement.
-
Build request catalog reports are supporting IGA admin to build access right request catalog to Self-Service, for example:
- Entitlements missing mandatory information.
- Entitlements published to Self-Service.
- Entitlements related to applications.
-
Daily administration is required to be monitored continuously when IGA solution is in production use:
- Requests waiting for provisioning.
- Published entitlements missing approver information.
- Daily provisioning success rate.
- Account actions (password changes, etc.).
-
Auditing reports are used for searching detailed information about users and their access rights, for example:
- Who had access right X active in 1.1-31.12.2024.
- Who approved request X.
- User and access right history.
-
Statistics reports are useful after IGA solution has been used for a while and there is data what can be reported:
- All time provisioning success rate.
- Most used services in Self-Service.
- All user creations, updates, departing users (%).
-
Governance reports are used for example ensuring that there aren't any malicious activity and to manage re-certifications, etc.
- Requests, requested and approved by same user.
- Requests, different approver that requested one.
- Accounts not created by IGA.
- All IGA admin actions.
Governance
Tasks related to governance are usually recurring in a monthly or yearly bases, but those are always related to customers policy's and security requirements.
It is common that also for example customers security officer has accesses to IGA solution, and can report and audit needed identity and access right information and/or can start re-certification requests.
Governance is part of each IGA use case and process, but there are different functionalities to ensure that for example compliance requirements are fulfilled.
- Re-certification
- Toxic combinations
- Risk level calculation and review of high-risk users and accesses
- Audit according to customer organization requirements
- Create new reports
- Report to stakeholders
- Fulfill auditing requirements
Develop
Keep up how your IGA solution is providing automation into organizations processes and improve it based on findings, keep list of backlog items in your IGA solution and ensure that changes in the organization are noticed also in IGA processes.
It is important to give feedback about the product, comment and like other users improvement ides and follow-up product related version upgrades, which will bring new features into your IGA solution!
Keep up with backlog and stakeholders
It is important to recognize changes which have affect to IGA solution, its configuration or automation, because those changes might launch huge amount of provisionings towards directory/directories or change configuration in a way that provisioning fails.
Keep up with backlog
In the delivery phase, Efecte delivery management -tool (EDM) is used for delivery tasks, test cases, test findings and also for further development ideas, this is highly useful for collecting backlog item for IGA development needs. The tool is installed in customers IGA test environment, and it does not have any extra costs (it is also good for storing test cases etc. when new features/functionalities are tested).
- IGA admin
- Creates new delivery item, which type is further development
- Prioritizes items
- Allocates new item to IGA configuration admin (can also be Efecte consultant)
- IGA configuration admin reviews and adds work estimation to the item
- Bigger items might need also project manager reviews
- IGA admin discusses with stakeholders
- If item is approved to be implemented, IGA admin schedules changes with needed participants and changes item status to done.
- If item is declined, IGA admin changes the item status to Cancelled (not needed/removed).
- IGA admin can use Kanban or any other views for reporting backlog items and prioritization.
It is important to implement and test all changes first in the test environment, especially if they are causing changes in configuration or it generates lot of provisionings towards directory/directories.
Keep up with stakeholders
Step 1 is to recognize all stakeholders and establish recurring meetings where changes are reviewed, affects estimated and schedule agreed. Commonly needed stakeholders are,
HR specialists, are needed when HR integration is implemented
Recommendation is to have recurring meetings before organizational changes, usually this is three (3) to four (4) times a year.
- Changes in organizational structure (new organization units, removing old units etc.) might cause a lot of provisionings towards the directory and in some case these provisionings are not necessary valid.
- New cost center, organization unit or title (if automated rules need to grant accesses)
- Ending of any organizational information will also have affect to automated rules, if those are granting accesses based on the removed information
- Review planned changes together with HR specialists and
- List into the backlog all changes affecting to IGA solution
- Reserve needed resources to implement changes
- Always reserve IGA admin to be available during and after changes related to HR solution
Simulate changes before provisioning
It is highly recommended to set on setting for reviewing data before provisioning (from IGA set account information data card, remember to do this to all user types coming from HR solution), with this setting workflow will receive information from HR solution, but before provisioning IGA admin reviews that all changes are correct and valid before continuing to provisioning.
Directory specialists,
Are often also IGA admins and responsible for all changes happening in the directory, which can have affect to IGA solution and its automation.
Recommendation is to have recurring meetings with directory specialist at least once (1) a month and include directory specialist in the meetings with HR specialists.
Most common changes in the directory, causing provisioning errors
- New organizational units (OU), applies to directories using OU structure.
- IGA admin validates if IGA set account information data cards need to be updated or new ones created.
- IGA configuration admin confirms that new OU's are read from the directory and technical user has permissions to write in to the new OU.
- New user account attributes
- IGA admin validates that new attributes are read to correct attributes in IGA account data cards
- IGA configuration admin confirms that new attributes are included in the connector mappings for reading (scheduled-tasks) and writing (event-tasks) data.
- New group attributes
- IGA admin validates that new attributes are read to correct attributes in IGA entitlement data cards
- IGA configuration admin confirms that new attributes are included in the connector mappings for reading (scheduled-tasks) and writing (event-tasks) data.
- Changes is certificates, secret keys etc.
- IGA configuration admin can update certificates, secret keys etc. from the connector settings
- Changes in technical user account (which IGA solution uses)
- All changes to the service account, which IGA solution is using for reading and writing data to/from the directory, needs to be discussed with IGA admin to prevent any major incidents happening, like if for example some reason technical user account (service account) would be removed from the directory, all provisionings would end-up in errors
Owners
Recommendation is to have recurring meetings with all owners on monthly or at least quarterly bases.
There are different type of owners who might need to be informed about changes happening in HR solution or directory/directories, since those might change for example need approval to change automation rules.
Owner tasks are depended on how responsibilities are agreed between IGA admin, security officer and owners in customers organization. Below are listed task examples for different owners but like said, these all could be IGA admin responsibilities.
- Application owners are responsible to
- Maintain information related to the application, if for example application name or technical details/dependencies are changing.
- Inform stakeholders about changes in the application
- Report according to organization auditing requirements
- Entitlement owners are responsible to
- Maintain information related to entitlements which owner owns like for example approver information, visibility in request catalog, name, descriptions etc.
- Investigate if changes in the application will have affect to IGA solution
- Add items to backlog and prioritize
- Re-certificate entitlements (which owner owns)
- Report according to organization auditing requirements
- Business role owners are responsible to
- Maintain information related to business roles which owner owns like for example approver information, visibility in request catalog, name, descriptions etc.
- Investigate if HR changes will have affect to business role content or audience
- Re-certificate business roles (which owner owns)
- Report according to organization auditing requirements
Security Officer
Security officer often owns IGA solution and all its processes. Usually security officer is responsible to define auditing requirements for daily/weekly/monthly/quarterly/yearly reporting and needed actions for example if malicious activities are detected.
Re-certification and toxic combinations might be either IGA admin or security officer or one of the owners responsibility, this is entirely depended how responsibilities are divided between security officer, IGA admin and owners.
New product features and functionalities
New version is released 2-3 times per a year and it is automatically installed into customers environments according to release communication (customer is notified before version upgrade happens in test or production). After the upgrade its good to do basic validation that everything works and in case there are issues after upgrades, please contact servicedesk@efecte.com.
Remember to follow-up,
Release notes - technical details about improvements and new functionalities in IGA solution, platform, Self-Service, connectors etc.
Community - which contains high-level description of released items and future roadmap items. Community is also correct place to suggest new product features or review what other customers has requested.
Table of Contents