Discovery
When you first connect Trelica to Okta, Trelica will read in data about the applications configured in Okta, and users associated with those applications.
Trelica also processes the Okta system log to find out when users logged in to applications through Okta. The first run will pull data from the past 90 days, and this history will then continue to build over time.
Onboarding
Trelica can create users in Okta as part of an onboarding workflow, but this may not be necessary. Before building a provisioning workflow you should think through how Okta currently works with other applications in your IT landscape.
HR system → Okta
Your HR system may already be connected with Okta, which may also be provisioning to another Identity Provider such as Google Workspace.
In this configuration, the simplest initial solution is for Trelica to connect to Okta as it requires minimal changes. Trelica will read user data from Okta on a daily basis.
The Trelica / Okta relationship is shown both ways, as you could also use an Okta webhook to notify Trelica when a new user is added to Okta, although this is more relevant for time-sensitive processes like offboarding.
You can also consider a situation where users are staged in Okta prior to their start date, and then a Trelica onboarding workflow activates the Okta user account at a specific time. This has the benefit that Okta can manage existing SCIM provisioning, but Trelica can coordinate other tasks.
For this to be effective Trelica will need to know the employee's start date, and ideally timezone. Trelica will read these from custom fields in Okta.
By default, Trelica checks the following field names:
Location | location |
Timezone | timezone |
Personal email | personalEmail |
Line manager |
manager , managerEmail , managerId
|
Start date |
hireDate , startDate , employee_start_date
|
Termination date |
termDate , terminationDate , future_termination_date
|
Additional fields can be configured by contacting support@trelica.com.
Another variant of this approach is to have Trelica create accounts in Google:
This works well if Okta is not managing much of the Google account and onboarding process, and where users are using separate credentials to log in to Google (i.e. they are not using Okta SSO to log in to Google).
HR system → Trelica
If your HR system is not currently synchronizing with Okta, or if Okta is only getting very limited information, it might be worth considering having Trelica connect with your HR tool and then drive provisioning to Okta and Google.
This is particularly helpful if Trelica's HR integration can get start and termination dates and Okta can't.
Offboarding
Depending on how your HR system, Trelica and Okta are connected the initiator for offboarding will vary.
If your HR system automatically deactivates an Okta account on a certain date
In this situation we recommend using an Okta webhook to trigger the Trelica workflow when a user is suspended in Okta.
If you want to differentiate between a human and a sychronization process triggering the action then you can add an input field for the Okta actor, and check for system@okta.com:
If your HR system sets the termination date in Okta, or if Trelica is connected to your HR system
Typically when Okta pulls the data from an HR system, then you wil get a termination date which can be stored in an Okta profile field. It is then up to you to initiate offboarding at the right moment.
By passing the date to Trelica, you can then have Trelica initiates offboarding based on this date. Trelica can run workflows for an employee based at a specific local time, which is very helpful when you want to offboard at 6pm local time, regardless of where an employee is based.
Offboarding
If the user isn't already deactivated in Okta then we recommend that the first thing you add to a Trelica offboarding workflow for Okta is a Deactivate user step.
Deactivating the user in Okta will remove all the user's associations with apps and initate any SCIM deactivation configured in Okta for the respective apps.
Trelica also has a Reset password and recovery question action and a Revoke all active Okta sessions for a user action which can be useful.
You can add an explicit Remove user from groups action to a Trelica workflow if you want to force Okta to remove group memberships.
After you have performed these actions you should consider using an Offboard person from apps step which will apply Trelica's offboarding policy for applications the user has access to.
Deactivation from Trelica
If the user isn't deactivated in Okta, Trelica will try to remove assignments in Okta itself. This process involves converting any Group assignments the user may have into Individual assignments, and then deleting the Individual assignments.
The benefit of this approach is that the user isn't removed from groups (in case this has side-effects), but their access to the application is removed, and consequently Okta runs any configured SCIM actions.
Bear in mind that if you reactivate the user they will regain their Okta group membership, but won’t have access to the app as the assignment was converted and removed. The solution is to restore the assignment in the Okta UI:
This process is also applied for deprovisioning actions carried out by Trelica workflows where Trelica has a direct integration configured, and the user is linked to Okta, or if you use the Remove user from app workflow action to explicitly remove a user from an Okta app.
Access requests
If Okta is configured to create users in an application via SCIM, then you will see an Okta provisions in (app) button in the provisioning section of the Access level.
You can then select whether Trelica will assign directly to an Okta app, or whether assignment should be via an Okta group (where the group is configured to provision that app).
Comments
0 comments
Please sign in to leave a comment.