Perfect IGA architecture - continued

Continuing on my previous short story:

In very low practical terms, I will here follow an import of Identity data from a HR source, to the IGA Identity repository, and add a ton of different use cases to it.

Import

The following data is imported from a HR system

employeeID: E0000123
Firstname: John
Surname: Doe
ManagerID: E0000122
DepartmentID: 12345-5555-69898-3216
Costcenter: 123450000
Manager: False
DirectReports: []
JobFunction: Secretary
LocationCountryCode: DK
LocationCountryName: Denmark
LocationOffice: Copenhagen        

Usecase 1: New Identity, no deviations.

The HR system connector, imports this into the HR system endpoint database. First it matches on the unique key of the HR system: employeeID. There is no match. The imported data is created as an endpoint account.

The IGA policies recognizes import of a new account from that specified enpoint, and now matches against the following policies:

Does Account have a managerID? Yes. 
  Is managerID found in the endpoint account database matching on managers employeeID? Yes.
    Is manager active/not offboarded? Yes.
      Proceed.
Does account have a DepartmentID? Yes.
  Is DepartmentID found in list of known/agreed departments? Yes.
    Proceed.
Does account have a Jobfunction? Yes.
  Is Jobfunction in list of out-of-scope jobfunctions? No.
    Proceed.
Create Identity Object IF no Blocks.
  Copy values from account to new Identity object.         

No Deviations to expected HR format, syntax and policies for Identity data was discovered. Identity Created automatically.

Usecase 2: New Identity, unknown departmentID.

The HR system connector, imports this into the HR system endpoint database. First it matches on the unique key of the HR system: employeeID. There is no match. The imported data is created as an endpoint account.

The IGA policies recognizes import of a new account from that specified enpoint, and now matches against the following policies:

Does Account have a manager? Yes. 
  Is manager found in the endpoint account database matching on managers employeeID? Yes.
    Is manager active/not offboarded? Yes.
      Proceed.
Does account have a DepartmentID? Yes.
  Is DepartmentID found in list of known/agreed DepartmentIDs? No.
    Block.
  Trigger action for deviation according to policies. Eg: Certification of DepartmentID value at HR.
Does account have a Jobfunction? Yes.
  Is Jobfunction in list of out-of-scope jobfunctions? No.
    Proceed.
Do NOT create Identity until no Block exists.         

Deviation to Identity polices discovered. The DepartmentID is unknown/not listed or not found as a department in the policy scope. Most likely it is either a department out of scope of the IGA system, or a new department created with same name as another by mistake, and then in the onboarding choosen by mistake.

As there is birthrights associated with DepartmentID's, then it needs to be stopped from onboarding, or risk getting wrong birthrights, or none at all. By blocking it and notifying HR (who is the source of the deviation) already at this stage, it is corrected at the source and at the instance who owns the deviation. the certification will ensure that the Identity can be created by HR either correct Department, or forces the value from HR, with clear notification that the user will not work and HR needs to take action if it is intended that the user needs to be able to login at any system. They take action by following the agreed process for onboarding new departments, which ensures that the IT organisation can create roles and birthrights. Or they accept that the Identity will never be able to login to IT systems.

Usecase 3: Change to existing Identity. No deviation.

The HR system connector, imports this into the HR system endpoint database. First it matches on the unique key of the HR system: employeeID. There is a match. The existing endpoint account is updated with the imported data.

The IGA policies recognizes update of a new account from that specified enpoint, and now matches against the following policies:

DepartmentID changed? No
  Proceed.
ManagerID changed? No.
  Proceed.
Jobfunction changed? No.
  Proceed.
Copy updated values from account to existing Identity IF no blocks.         

The imported change from HR is changes to HR attributes which has no policies. If a name is changed, it does not directly have an impact on birthrights and the breach to policies it may cause, is not harmfull to prevent, rather than to fix post the Identity update.

Usecase 4: Change to existing Identity. Mover. No deviation.

The HR system connector, imports this into the HR system endpoint database. First it matches on the unique key of the HR system: employeeID. There is a match. The existing endpoint account is updated with the imported data.

The IGA policies recognizes update of a new account from that specified enpoint, and now matches against the following policies:

DepartmentID changed? Yes.
  Is DepartmentID found in list of known/agreed DepartmentIDs? yes.
  Mark as mover.
  Proceed.
ManagerID changed? yes.
  Is manager found in the endpoint account database matching on managers employeeID? Yes.
    Is manager active/not offboarded? Yes.
      Start certification of current birthrights if Marked as mover. Old manager and new manager to certify. 
      Proceed.
Jobfunction changed? No.
  Proceed.
Copy updated values from account to existing Identity IF no blocks.         

Standard mover from one department to a new department. The new department is a known department with already defined birthrights. The mover process dictates that before removing the birthrights from the old department, it needs to be reviewed and approved by both former and new manager. usually there is a transition of former tasks to another employee, also expanding into the new time of role. So the Identity needs - for a period of time - to have the same access rights as before the move, as well as the access right fitting the new role.

Usecase 4: Change to existing Identity. Mover. Deviation.

The HR system connector, imports this into the HR system endpoint database. First it matches on the unique key of the HR system: employeeID. There is a match. The existing endpoint account is updated with the imported data.

The IGA policies recognizes update of a new account from that specified enpoint, and now matches against the following policies:

DepartmentID changed? Yes.
  Is DepartmentID found in list of known/agreed DepartmentIDs? No.
  Mark as mover.
  Block.
  Trigger action for deviation according to policies. Eg: Certification of DepartmentID value at HR.
  Notify IGA admins. 
ManagerID changed? yes.
  Is manager found in the endpoint account database matching on managers employeeID? Yes.
    Is manager active/not offboarded? Yes.
      Start certification of current birthrights if Marked as mover. Old manager and new manager to certify. 
      Proceed.
Jobfunction changed? No.
  Proceed.
DO NOT update Identity IF any blocks.         

Standard mover from one department to a new department. The new department is an known department without already defined birthrights. Because there is no birthrights associated with the new department, the Identity risks loosing all access rights to all systems in the organisation. If HR approves the certification, the new manager will have to certify the current access rights, and will be notified that the Identity is about to be stripped from all access.

Typically when HR prepares organizational changes, they creates the new organizational structure in the HR system beforehand. Sometimes they moves the employees around to their new departments. If you have read some of my previous articles, you will know that making agreements with HR to never do this without the IGA team is prepared beforehand, is not really a good solution, as they by laws, are prevented from notifying anyone beforehand, if those employees are affected by organisational changes as well (even if just their department is moved are they themselves is moved to another department). This will have the consequence that if NOT having this filtering and intelligence and instead fully automated change of department and manager, all people in the organisation will be stripped for all their access rights, and none of them can produce anything. This is a serious risk and harm for your business, so jsut trusting HR completely, is both right, and it is wrong. HR is subject to governance of Identity policies as well. And what is the ONE system in ALL the organisation to govern those policies? IGA.

Principal

For anything which is related to Identity policies, needs to be subject to governance controls. This covers everything including HR processes and data. There is no such thing as a golden source that we trusts blindly. HR is the golden source of who is in the organisation, and also how it legally fits. However the HR system may not always reflect the current truth. Usually it can be documented with history and future plans, which might be in emails for the few need-to-know individuals. So HR systems are authoritive, but not gods. This labels HR system as subjects to Identity Governance on the same level as any other endpoint. If the IGA vendor cannot support the above, it is not a true IGA. It can be a very advanced IAG, and have many IGA features, but it is not full covering IGA.