If you’re here, you probably know what Okta is. But if you don’t, we won’t hold it against you (promise!). Okta offers an IAM (Identity Access Management) solution, enabling you to centrally and securely manage your users’ identities and access to the resources they need to access.
Okta is like the bouncer of the VIP lounge, which will check that you’re on the list before letting you in, except that you may be asked for more proof of identity than just a password. And if what you present isn’t recognized, you’ll get a Gandalf-like response.
More info over here : Workforce Identity Cloud/Okta
Today, I’m going to tell you about one of the features of Okta’s Workforce Identity Cloud solution, and not the least: workflows.
Workflows? What’s that?
Okta’s workflows are a low-code feature that lets you automate and chain actions, which can affect different targets (users, groups, applications external or integrated into your Okta organization, etc.).
To execute workflows, you’ll need one or more connections.
Connections
These are connections to the workflows’ target applications, which will manage authorization flows to guarantee the correct execution of requests.
To act on an Okta tenant (not necessarily your own!), you’ll need to enter the target tenant’s client id and client secret, which will use the client credentials flow for actions.
For other applications, you can use OAuth 2.0, Basic or even Custom flows.
A workflow always starts with a trigger event, which can be :
1° Internal to your organization (holding) — a few examples :
- adding a user to a group
- assigning an application to a user or group
- updating the value of a user profile attribute
- a trigger scheduled every day at a specific time
2° An event in a third-party application — here a few examples:
- a received mail in Gmail
- a created issue in Jira
- a new channel in Slack
- a new entry in Salesforce
There are many possible trigger events, and I haven’t even mentioned web hooks or API endpoint calls yet.
Once the trigger has been configured, you can chain actions together, each represented by a card, some of which may return data (user profile, for example), representing the API calls that will be made.
The data retrieved can then be linked as variables to be used on other cards, the most common example being a user’s ID.
A very simple instance
In the Okta admin console, each time a user is added to a group, we want the value of the “isMemberOfGroup” attribute in the user’s profile to change to “true”.
The trigger is the “User Added to Group” card, and the next two cards are the actions that follow: we read the user’s profile based on his ID (optional step, put here to illustrate the sequence), then we perform a partial update of the user’s profile, setting the value of the “isMemberOfGroup” attribute to “True”.
The connected applications
In the same way as the Okta Integration Network (OIN), the catalog of third-party applications for which connectors to Okta already exist and are available, some applications have connectors in their workflows.
Action cards let you easily program the task to be carried out in this case: for example, with Gmail, send an e-mail whose content and recipient(s) you define, or add a user to a GitHub organization.
“And if the application we want to act on isn’t already referenced, what do we do?” you might ask. Well, there’s always the option of carrying out operations via API calls to your target, the “API Connector” cards.
Here’s a concrete example of what we’ve recently done for a customer: each time a new employee is onboarded, we’re going to store a temporary password in the 1Password safe of the new employee’s manager. Since 1Password doesn’t have an established connector, we’ll make a POST API call to the manager’s safe and send him a JSON object containing the password.
Execution history
To conclude this introduction to workflows, I need to tell you about the history, which you can choose to save or not.
In any case, it’s very useful to keep this data, especially during the workflow construction phase, as each execution will bring you card by card of the resulting data: in the event of an error, you’ll know precisely where and why an action didn’t work as planned.
Key points to remember:
- Workflows automate action sequences via API calls to your Okta tenant or third-party applications.
- Triggering can be programmed at a given frequency, or respond to a specific event, or even depend on a web hook.
- Connectors are available for certain applications, offering certain actions in the form of cards.
- For other third-party applications, you can always use custom API call cards, where you define the endpoint to be reached, the method, the headers and the authorization flow.
- You can save the entire execution history of a worfklow.
- Save time and productivity, with fewer repetitive tasks for your staff.
The points covered here are not exhaustive, as I haven’t mentioned all the function cards, which provide a host of additional functionalities: data processing and modification (text, object, JSON), branching operations with if/else, for example, etc…
I’ll come back to these additional functions in more detail in the next article.
More info: Discover Okta Workflows
Point Base is an Okta partner company, our services:
- Consulting
- Training
- Implementation
- Software development
We now also work with Perimeter 81 and Sysdig
Don’t hesitate to follow Point Base’s LinkedIn page.
Do you have any questions? Contact us, we’ll be delighted to answer them.
One thought on “Introduction to OKTA Workflows: nothing is impossible (almost)!”