Okta Identity Governance and/or Service Now – Architectural Patterns

Most organisations have some ITSM or service request tool, and ServiceNow is the most common. So it’s understandable that any conversation about Okta Identity Governance, particularly access requests, will involve comparison with ServiceNow or integration patterns for both products. How do you approach an access request solution? Which product is going to meet your needs the best? What are the implications of one over the other, or do you need to think about an integrated approach?

This article looks at the different architectural patterns available for Okta Identity Governance, for ServiceNow and for both working together.

Introduction

Identity management, or what is the “A” in IGA, has been around for a quarter of a century. Over that time the “Holy Grail” has been 100% role-based entitlement, tied some source of truth (like HR) with end-to-end lifecycle automation. But that isn’t practical for most organisations, so there has always been a need for a mix of role-based and request-based entitlement.

Access request mechanisms have been a key feature of identity management (or IGA) systems. Any access request mechanism will have a standard set of capabilities:

• A request interface – somewhere users can go to request access. This has traditionally been a web page (from an identity management tool or ITSM tool). But more recently we’ve seen the move to using chat interfaces like Slack and Microsoft Teams.
• An access catalog – similar to having a service catalog in an ITSM tool, an access (or app) catalog represents the (app) accesses a user can request.
• An access control mechanism – so you can control who can see/request what accesses.
• An approval flow mechanism – a means to build workflows associated with access requests, so someone (such as a manager or application owner) must review and approve an access request. This needs to be flexible as there are often requirements for different types of approval flows for different access requests.
• An audit trail – to prove to the auditor that there was a process followed for granting access via the request mechanism.

With the emergence of ITSM products, like ServiceNow, it’s become common to include access requests with service requests.

So, which product should you choose to address your access request needs? Or do you need to think about an integrated approach?

This article is looking at Okta Identity Governance (OIG) and ServiceNow, comparing the Access Request capabilities of each and how they can be integrated.

Architectural Patterns

There are five basic patterns we can consider as per the following figure.

The patterns are:

• A. OIG Access Requests provides the entire access request flow and updates Okta with access changes (no integration with ServiceNow),
• B. ServiceNow provides the entire access request flow and updates Okta with access changes (no integration with OIG),
• C. OIG Access Requests logs a ticket directly in ServiceNow as part of the access request flow (which could be used to drive further activity)
• D. Okta Workflows creates a request in ServiceNow (possibly triggered by an Access Request from OIG)
• E. ServiceNow triggers an access request flow in OIG Access Requests via APIs or by using Workflows to listen for new tickets in ServiceNow and then use APIs to raise requests in OIG

We will explore each in the following sections.

Pattern A – OIG Access Request Only

This pattern involves only OIG Access Requests and Okta. Users, groups and applications are sync’d from Okta into Access Requests. They are used to build request types that are exposed through the various user interfaces as the request catalog. Users, based on role, can request access, have it reviewed and approved, and access changes are applied into Okta.

We won’t explore OIG Access Requests in detail here. It does address the key access request capabilities listed above, but there are some features to highlight (which will become relevant in the comparisons):

• It provides an easy-to-use interface for developing request types (approval flows) that doesn’t require any coding
• It provides three different channels for access requests, a WebUI, Slack and Microsoft Teams, and the data collection form is based on the flow, not baked into each channel.
• Users and user grouping for request visibility and approvals, is based off Okta users and groups
• Auditing is via the common Okta System Log
• Okta Workflows can be used to extend access request use cases
• The functionality and integrations are included in the Okta Identity Governance licensing

We have a number of articles covering OIG Access Requests features and use cases here. See https://iamse.blog/identity-governance-and-administration-iga/oig-access-requests/. You can also refer to the product documentation at https://help.okta.com/oie/en-us/Content/Topics/identity-governance/access-requests/ar-overview.htm.

Pattern B – ServiceNow Only

ServiceNow is a platform that supports integration with many products for many different service management use cases, not just access requests. It has an integration framework that is leveraged for Okta integration (note that we are talking about integration with Okta Workforce Identity Cloud, or WIC, not OIG Access Requests).

The component labeled ‘SNow Okta “module”‘ could be one or more integrations available on the ServiceNow store (https://store.servicenow.com). These modules provide varying levels of integration into the Okta platform. Whilst there are currently (Dec 22) eight Okta integrations in the store, there are only three that directly relate to access request integration into Okta:

• Okta Identity Cloud API Access is free and provides basic access to Okta orgs and APIs. It is a prerequisite application offering Connection and Data abstraction for additional Okta Identity Cloud applications. It consists of script libraries to allow ServiceNow applications to communicate with Okta at the API level.

• Okta Orchestration Activity Pack is free but requires a ServiceNow Orchestration license (paid) and Okta Identity Cloud API Access (free). It exposes a toolkit of pre-configured Activities that place the power of the Okta platform at the disposal of a ServiceNow architect. It is used to extend the platform for onboarding, role management, self-service request and approval, etc. to Okta’s application and identity layer. It can perform user management and group membership management, but not application assignment.

• Okta Spoke is a licensed component (“Use of this product requires a license for either Integration Hub Professional or Software Asset Management”). It provides actions to easily automate Okta user, password, group, group membership, application, application access, and logs management. It covers the user and group management functions but not all of the application assignment functions (e.g. no assign user to app). There is an Access Management Automation module that builds on top of Okta Spoke to automate many of the request actions.

These integrations represent a spectrum of cost and functionality. The first integration is free but would require a lot of work to implement access request approval flows integrated with Okta. The other two integrations provide a higher level of functionality, meaning a lot less effort (and skills) to build approval flows, but come with licensing costs. They also only work at the user and group level – if you wanted to include application assignment, you would need to build this.

ServiceNow provides its web user interface for requesting access. There is certainly a benefit in using the one interface for all service requests, keeping it simple for business users. ServiceNow does have integrations with Slack and Microsoft Teams. However the Slack integration requires building Slack workflows to present forms and the Microsoft Teams interface will strip data out of the chat and doesn’t use forms at all. Both could be used, but would require significant development effort to emulate the data entry forms used in the web user interface.

ServiceNow has its own logging mechanism. Also, any activity against Okta (like adding a user to a group) would be logged in the Okta system log. If you wanted a consolidated audit trail, you would need to plumb the different log stores into a SIEM.

Pattern C – OIG Access Request Calling ServiceNow Directly

This is the first of the integrated patterns, where a ServiceNow ticket is created directly from an OIG Access Request flow.

It uses the standard integration built into OIG Access Requests. More details on the integration can be found here: https://iamse.blog/2022/07/06/integrating-servicenow-with-oig-access-requests/.

This integration is useful when you want to raise the request, have it approved and provisioned into Okta in OIG Access Requests, but need to log the request history in ServiceNow. The pattern could be used to trigger a flow in ServiceNow for other activity, but there is no feedback loop back into OIG to wait for completion. This is often used when ServiceNow is considered the record of all service requests and reporting is performed there.

Pattern D – Okta Workflows Calling ServiceNow

The second integrated pattern involves using Okta Workflows to log a request in ServiceNow.

It is using the standard ServiceNow connector in Okta Workflows to create a request (or incident) in ServiceNow. It could be triggered off any change in Okta, including a request run through OIG Access Requests. An example of this integration can be found here: https://iamse.blog/2022/12/16/logging-a-servicenow-request-via-workflows-from-oig-access-requests/.

This pattern is very useful when you want to use ServiceNow to drive provisioning to external systems not managed by Okta. OIG Access Requests would be used to raise and approve the request, then handoff to Okta Workflows (via a new System Log event with a rich set of information about the request) which raises the request in ServiceNow. Okta Workflows could also listen for updates to the ticket and update Okta as needed.

Pattern E – ServiceNow Calling OIG Access Requests

The final integration pattern is for ServiceNow initiating a request in OIG Access Requests.

There are two approaches that could be used:

1. Within SerivceNow the Okta Identity Cloud API Access module is leveraged to make an API call into OIG access requests to raise a request. Note this is theoretical and I’m not aware of it having been implemented.
2. An Okta Workflow uses the ServiceNow connector to listen for a new ticket being created, then uses the OIG API to raise a request in OIG Access Requests.

Both could achieve the aim of raising a request in OIG Access Requests in response to a ticket in ServiceNow, however the Workflows approach would be much simpler to implement.

This approach is common when organisations want to use ServiceNow as the master service catalog but don’t have the means for direct integration with Okta.

Considerations for Which Pattern to Use

Now that we have explored the different patterns with OIG Access Requests and/or ServiceNow we can look at the considerations when deciding which pattern to use.

OIG or ServiceNow

If you don’t have ServiceNow, then you could compare the effort to implement either solution to address the key areas (UI, catalog, access control, flows, and audit). In most cases OIG Access Requests will be a lot easier and cheaper to setup and use. To achieve the same level of functionality in ServiceNow would require additional modules and development/configuration effort.

But what about if you already have ServiceNow in use? It certainly makes sense to stick with the one user experience for your business users rather than throwing another user interface at them. How much work would be required to achieve access requests into Okta? This will depend on which of the ServiceNow Okta integration modules are used and how much development/integration effort is required. If no ServiceNow Okta modules are used, there is a variety of options that all involve cost (licensing and/or development effort). It may be that implementing OIG Access Request with ServiceNow is significantly cheaper than beefing up ServiceNow to talk to Okta.

What about the user interface? As mentioned, having the one experience is optimal for business users. But businesses are moving to chat tools like Slack and Microsoft Teams, and having access requests integrated with these tools makes life easier for business users (and makes a more efficient access request mechanism as you don’t have the asynchronous delays of email-based request systems). OIG provides Slack/Microsoft Teams integration with no extra development effort, whereas to use either with ServiceNow will require some development (potentially needing specialist skills).

Finally you need to think about the security of the system – how do you control access to requests, control who can approve requests and where the audit log goes? With OIG this is all centralised within the Okta platform – the same grouping applied to SaaS SSO access or MFA policies can be applied to access requests. The access request audit trail is centralised in the Okta System Log. If you run access requests through ServiceNow you may need manage access policy and audit trails in multiple products making auditing more complex.

OIG With ServiceNow

You may need to look at an integrated solution, rather than one product or the other. You need to consider: where do you need to initiate an access request, where do you need to approve it and where do you need to fulfil it.

You may decide you need a chat interface or a simple way to build and present request flows, so initiating in OIG Access Requests makes sense. If you need to update access in Okta but log the request history in ServiceNow, then using the direct OIG Access Request ServiceNow integration (pattern C) is appropriate. But if you need to fulfil via ServiceNow (perhaps for provisioning to systems outside of Okta) then leveraging the new System Log events and Okta Workflows with the ServiceNow connector is more appropriate (pattern D).

You may need to initiate all requests in ServiceNow as it represents the master service catalog and the user experience all business users are familiar with, but don’t want to implement the direct Okta integration described in pattern B. In this case you could raise an access request in OIG Access Requests, either directly or via Okta Workflows, and then perform approval and fulfilment there. The Okta Workflows approach is simpler to implement and would be recommended.

Conclusion

This article has explored Access Requests with Okta Identity Governance (OIG) and ServiceNow and the integrated patterns between them.

As with any business problem, you should look at the current state and business drivers for change and decide on a solution based on that. It may be that you could choose to only use OIG or ServiceNow for an access requests implementation with Okta. In most cases, it will be easier to implement access requests using OIG, but this will depend on your environment.

If you do need to look at an integrated solution involving both OIG and Service now, there are different patterns to support different use cases. You should explore your requirements and weigh up the different patterns to see what works best.