Skip to main content
Version: Cloud

Identity lifecycle management

The Identity Lifecycle Management processes enables you to onboard, change, and offboard identities such as employees or contractors. This process is known as the joiner-mover-leaver process. Triggering any of those processes results in identities being updated in regard to your company's organizational structures.

Also, roles and assignment policies determine which access rights should be granted or revoked.

Onboard identity​

Initial join​

The process of onboarding an identity entails the creation of a new user in Omada Identity through the Initial join process. The Initial join process creates a new identity in Omada Identity, whereby Omada Identity is not the source of the identity, but instead it's a Human Resource management (HR) or HR-management-like system.

The process can also include the onboarding of a contractor, as well as the request of a technical identity.

During the Initial join process, and when a new identity is created, the master data system for identities stores a data record.

The new identity, which is made up of a unique username, is then imported and processed in Omada Identity so that access rights can be requested by the same identity, or by the manager of that identity. An approval task is then created to confirm the onboarding.

Optionally, an approval task can be created for the user's primary responsible, for example, a manager or administrator.

This allows the user to request supplementary roles or resources that can be relevant for the new identity.

info

Typically, Omada Identity imports data from the authoritative source once a day, and this can be configured.

Pre-conditions​

  • All master data must be loaded into Omada Identity before starting the Initial Join process.
  • The system's resource type contains the attribute Initial password.
  • The governance must be defined, especially if there are restrictions, for example, who can apply for access rights and on behalf of whom.
  • There must be one data record per person.
  • New data records have been loaded by the system before the ID is activated and is ready to be used.
  • HR data records that can provide entry and exit data, for example, when an employee joins or leaves an organization.

Process flow​

  1. An identity record is created in an authoritative source, for example, an HR management system and is then created and imported into Omada Identity.

  2. The Onboard employee workflow is executed.

  3. Omada Identity reads the data record and processes it according to predefined assignment policies.

warning

If mandatory attributes are missing, the system throws data import errors.

Post-conditions​

  • The new identity and user are created in Omada Identity.
  • The new identity receives an email with their initial password.
  • If appropriate Assignment policies are predefined, the new identity has basic access rights.
  • A user is set to inactive in the system until they have reached the Valid from date, while the user is set to active after the Valid from date is reached.
  • A user can now use their Omada Identity portal page.
  • The user’s manager can now see the new ID in their data and processes.
Best practices, considerations & recommendations

  • Validity periods can be enforced by Omada Identity based on the resource or identity attributes (for example, an external user can only get access for a certain number of days). Hence these limitations must be defined within the company rules and outside the dimension of Omada Identity.

  • A UID can be generated by the identity manager or imported from an authoritative source.

    note

    It's considered best practice not to reuse UIDs, as they're the basis for maintaining matching rules, historical records of changes, and more.

  • When an identity record is deleted from the Identity Manager, the organization should consider the amount of time that an identity record is saved for.

    note

    It's considered best practice that an identity record be saved for at least 5 years.

  • Generate a UID that's independent of identity data, for example, the UID should not be based on a name or identity category. This ensures the same username can be used in case the identity changes their name or converts from an external to an internal user.

  • When onboarding a new system, make sure to add the attribute property Initial password to the system's resource type to provide automatically an initial password to new joiners.

Onboard contractor​

The goal of the Onboard contractor process is to create and establish ownership of a new identity from an authoritative source.

The Onboard contractor process is a manual process that can be triggered by Managers and their delegates with suitable rights, when a new contractor is hired. The onboarding manager can then request access rights for the onboarded contractor.

Then, the identity with suitable rights begins the manual process from their homepage and fills out a form.

Optionally, the identity chooses to apply for access rights, and then the identity submits the request and the post-processing of the request begins.

If Omada detects similar identities with the same Master data, the process creator can choose to create a new contractor or modify an existing one.

note

If a manager onboarding the contractor is not the owner of the selected context, a new context request is launched and assigned to the context owners. The owners must approve the context request before the context assignment is created. Until the context assignment is active, it isn't possible to request access for the contractor in the selected context.

Process flow​

  1. From the homepage, an identity with suitable rights manually triggers the Onboard contractor process.

  2. The identity fills out a form with various properties outlining personal data (Master data).

  3. The identity then submits the form and Omada Identity checks for conflicts or duplicates. If an identity with similar Master Data already exists, for example with a similar first or last name, or email, then the user has the option to:

    • Create a new identity
    • Update an existing identity
    • Terminate the process

  4. The identity chooses to apply for access rights (not mandatory).

  5. The identity submits a request.

  6. Post-processing begins.

Post-conditions​

  • The new identity and user are created in Omada Identity.
  • The new identity has basic access rights if appropriate Assignment policies are predefined.
  • A user is set to inactive in the system until they have reached the Valid from date, while the user is set to active after the Valid from date is reached.
  • A user can use their portal page.
  • The user’s manager can now see the new ID in their data and processes.
  • Ownership of contractors onboarded via the Onboard contractor process are not imported to the Data Warehouse.
Exceptions

The process cannot be submitted if the selected date in the Valid to field is later than 180 days, starting from today.

Best practices, considerations & recommendations
  • Ensure there is a legal contract in place before onboarding a contractor.
  • From a risk assessment point of view, ensure that there is an internal policy regulating the management of contractors.

Request technical identity​

The Request technical identity process is triggered when a non-personal account is requested. Typically, these accounts are necessary in every IT department for administrative tasks in database management or systems management.

By consequence, this type of account, which must have a real identity as an owner, has powerful access rights and must be carefully managed.

note

The ownership of a technical identity cannot be delegated.

Pre-conditions​

The system or application must have an owner defined.

Process flow​

  1. A system owner starts the Request technical identity process and selects the system that the technical identity belongs to.
  2. The system owner enters the required information, such as validity, name, and more.
  3. The system owner submits the process. The identity ID is automatically generated.

Post-conditions​

  • New Technical identity is created in Omada Identity in the organization unit Technical identities.
  • The requesting identity is set as the Identity owner.
Best practices, considerations & recommendations
  • Ensure ownership of the technical identity is transferred when the identity owner transfers or is terminated.
  • Decide whether each account shall have its own technical identity, or if a technical identity can have multiple accounts.

Change identity​

The next layer of onboarding an identity is to be able to change or modify the identity when necessary. These processes include a transfer of identity and a change in Master data.

note

The process of prolonging an end date of an identity’s validity is not an OOTB process.

Intra-organizational transfer​

The goal of the Intra-organizational transfer process is to transfer identities that are currently associated with the organization to a new department within the same company.

A person changes from one Organizational Unit (OU) to another unit within a company. All policy resources belonging to the old organizational unit are immediately removed and assignments belonging to the new OU are added.

Firstly, the old manager(s) and then the new manager(s) receive a work item, where they can confirm the transfer and if necessary, or apply a grace period for removed assignments.

Pre-conditions​

The change of an OU must be part of the HR data.

Process flow​

  1. An identity changes position or department in the same organizational structure through a change in an authoritative source (such as an HR system for employees).

    info

    The process is triggered by a change in Master data.

  2. Alternatively, the identity data for all identities where Omada Identity is the authoritative source is updated directly in Omada Identity.

  3. The identity data is then imported into Omada Identity.

  4. A task is then assigned to the old responsible for the old department, to re-certify the direct access rights (not previously set by a rule) that the identity is currently assigned to. This allows some or all the directly-assigned access rights to be transferred to the new position.

  5. Another task is then assigned to the new responsible for the department, to recertify the direct access rights (not previously set by a rule) that the identity is currently assigned to. This allows some or all the directly-assigned access rights to be transferred to the new position. The new manager can review and change the decision made by the former manager.

  6. All assignments from the old context that have not been transferred are bound to expire, either immediately or after a grace period.

    info

    The grace period is defined by a setting on the context type. The organization can choose how long the grace period will last using this setting. By default, the grace period is not set (that is, the value is set to 0 days).

  7. Rules controlling the assignment of roles and resources (assignment policies) are re-applied based on the new identity attributes.

  8. Access rights are calculated for the identity and access is provisioned according to system configuration.

  9. Manual cleanup of the identity.

Post-conditions​

  • The identity is created in the new OU.
  • New indirect assignments for the relevant ID are provisioned.
  • Certification of old direct assignments is finished, including provisioning or deprovisioning.
  • Administrative cleanup is performed.
Best practices, considerations & recommendations

Company policies concerning access rights in relation to transfers need to be followed, for example, grace periods or decommissioning of access rights.

Master data change​

The goal of the Master data change process is for Master Data to be updated after it's modified.

Usually, Omada Identity reads identity data from an authoritative source system such as an HR-Management System.

The Master data change process takes place when the authoritative source system shows modifications to the data records.

A user can change their data records through a Data update request, which must be approved by the identity’s manager. When the system detects a change in data records, Omada Identity reads the modified data and updates it in Omada Identity according to the predefined data-mapping rules.

Any modification to identities’ Master data is then automatically propagated to connected systems based on previously defined provisioning rules.

Pre-conditions​

  • The definition of attributes whereby Omada Identity is the authoritative source.
  • Each identity in Omada Identity must have a Manager.

Process flow​

  1. The relevant identity triggers the Maintain my data process and modifies Master Data.

    info

    The process is triggered by a change in Master data.

  2. The manager of the relevant identity can Approve or Reject the request.

Post-conditions​

  • Identity Master data is updated.
  • Target system(s) are updated.
Best practices, considerations & recommendations
  • It's not recommended that you change a user’s UID, even if this is based on the identity name and the possibility that it can change. It's also possible to change user accounts and display names, however, the UID is the basis for maintaining matching rules, historical records of changes, and more.
  • The application of good Master data governance is important to avoid unexpected consequences of changes to access profiles. Unexpected consequences or errors can occur due to changes in Master Data.
  • To avoid these unexpected consequences or errors, only well documented and high-quality data fields in an HR system should be used. This also helps to imply certain behavior in the Identity Manager.

Offboard identity​

The offboarding of identities typically takes place when an employee leaves the organization, and it's carried out through the Termination process.

Termination​

In Omada Identity, a Termination process can be triggered to resolve an employee’s ID and other related issues in a compliant way.

The Termination process, also known as the Leaver process, covers the immediate or planned permanent off-boarding of an identity and subsequent deprovisioning of its related user account and access rights.

This process is triggered when the Valid to date in the identity record of the HR system or Omada Identity has been reached, or when there is a missing data set, or if the identity record is no longer delivered by the source system.

In either scenario, and when the process is voluntarily or involuntarily triggered, the identity is terminated, all its accounts are disabled, and accesses revoked.

The account is then deleted after a post-validity setting that you can predefine.

At this point, the Transfer ownership process begins. However, as the process is asynchronous, it does not occur at the same time that an account is deleted.

Pre-conditions​

  • All Master Data must be loaded into Omada Identity before starting the Leaver process.

  • Termination data is provided by HR data records.

    note

    Termination data is always based on the Valid to date of an Identity.

    If the identity record is not delivered in the data feed anymore, then the Valid to date is assumed to be the date when the record was first not delivered from the source system.

Process flow​

  1. The Valid to date or value in the identity record of the HR system, or Omada Identity or a missing data set triggers the process in Omada Identity.

  2. Identity status is set to Terminated.

  3. A new calculation of the identity is performed.

  4. The Transfer ownership process is triggered.

Post-conditions​

  • The relevant identity is terminated.
  • Accounts are disabled, and access rights are revoked.
  • Accounts are deleted after a configurable post-validity period.
  • Open tasks must be manually resolved.
  • Ownerships are resolved by following the Transfer ownership process.

Anonymization of objects​

In order to comply with the EU General Data Protection Regulation or sanitize sensitive customer data, Omada Identity is supplied with possibility to anonymize all or selected objects that meet specified criteria. The data objects that can be anonymized are Identity, Account, Resource, and more.

The Anonymization of objects process can be executed on request or according to a schedule on the basis of the editable attribute filters.

Anonymization is performed according to the following principles:

  • Both the current and all the historical object versions are anonymized.
  • Names are anonymized and numbers are appended to them, which makes it possible to distinguish between anonymized objects.
  • Mandatory attributes are overwritten with an anonymization value.
  • Attributes that don't hold any sensitive data needed and are required for compliance purposes are preserved.
  • Optional attributes are deleted.
  • Object references are preserved.

The anonymization mechanism can be executed within the Omada Identity Enterprise Server by going to Setup > Administration > Connectivity > Import profiles.

Anonymization process​

In case of an identity’s request or after a set time, it might be necessary that a manager or Operation Administrator anonymize data object for a selected or all identities – active or expired. When this happens, all specified data objects are anonymized and cannot be restored.

Pre-conditions​

  • Identity’s request or Set time has passed since identity expiration.

Process flow​

  1. An identity requests to anonymize its data or Set time passes since identity expiration.

  2. The process starts automatically on timer or a manager or Operation Administrator starts the anonymization process by using the appropriate menu item in Omada Identity.

  3. All or selected identities’ data objects are set to anonymized.

  4. When an identity’s data are anonymized, they cannot be reverted to the previous state or restored.

Post-conditions​

Data are anonymized (and cannot be restored).

Best practices, considerations & recommendations
  • Ensure that the company/organization has a formal written policy for the Anonymization of Objects process.
  • A company/organization should be able to receive, response to, and fulfill identities’ request for their data anonymization, for example, fulfill the GDPR’s right to be forgotten.