Conquering User Provisioning with Okta Workflows
I just got back from Okta's SKO this week and one of the major technical focuses was on the new Okta Workflows engine which is currently in EAP (early adopters program). Workflows is a new component of the Okta Advanced Identity Lifecycle Management (ILM) offering that enables organizations to perform complex logic triggered by joiner, mover and leaver events such as the creation of a new user, an employee transferring a different department, a user being added to a group or being terminate in an HR system. There are many more events than this but this gives you a flavor. When these events are triggered, Okta workflow can perform any number of actions such as sending an email, assigning a personal folder in a file management solution like Box or SharePoint (among others), and assigning the user to a Slack channel. Okta workflows follows an event-based model:
"When this happens" -> "If this" -> "Do This" -> "Do That"
[Event] [Function] [Action] [Action]
From Okta's Website:
The workflows interface is a very friendly drag and drop UI (I wish I could show it) that allows Okta engineers and administrators to easily string together the workflow steps using out of the box connectors for many popular applications and cloud platforms as well as the ability to call other ReST-based services. Workflows can be triggered by scheduled events, internal Okta events or even events in other applications such as a new Jira issue or a new AWS Lambda event. Okta Workflows includes OOTB connectors for many popular cloud platforms such as Office 365, G Suite, Github and many others. At the time of this post there are 32 named connectors and I expect that there will be many more by GA.
In every identity management project there are tricky requirements that we receive from customers that go beyond the traditional use cases. For example, when an employee is disabled in Okta, the system should disable their accounts, terminate any existing Okta and Slack sessions, forward email to the user's manager, remove the user's Office 365 license and send an email to the help desk distribution list. Custom requirements such as these in most IGA solutions require custom development either in a workflow or rules engine or through external PowerShell scripts. The Okta Workflows engine provides a very powerful interface to implement and maintain these complex workflows without having to write a ton of code which is difficult to maintain.
What's not in the Workflows engine is any capability to pause for human activity, such as gathering an approval from a manager or application owner or generating a manual event such as a ServiceNow ticket that pauses the process until the ticket is closed. As mentioned above the Okta Workflows engine will be available to any organization that owns the Advanced Lifecycle Management component which is Okta's workforce identity management solution. This capability isn't being included (at least initially) in Okta's Customer IAM offering as well.
Comments