Okta has just released a separation of duties feature into Okta Identity Governance. This article provides a brief introduction to the feature.
Introduction
Separation of Duties (or Segregation of Duties, or more commonly SoD) has been a standard control for identity governance for a quarter of a century. The concept is that a user should not have conflicting access unless there has been some governance applied to ensure it’s a valid business need and recorded.
Whilst it may be between applications (e.g. I can access the HR app used by business unit A, but not the one used by business unit B) it comes up more in application entitlements (often application transactions). For example, if I can raise a purchase order I should not be able to approve purchase orders.
This implies visibility into application-level access, which is what Entitlements Management in Okta Identity Governance provides. Being able to see entitlements in an app means being able to set rules around toxic combinations of those entitlements.
We will explore this new feature across the three main use cases – access requests, access certification and reporting. For this article we will use a trivial example – a user cannot have both of a set of Microsoft Office365 licenses. The article assumes you’re familiar with Okta Identity Governance and Entitlement Management.
Configuring SoD Rules
SoD rules are configured within each applications’ Governance settings. At this stage the SoD rules are between entitlements within an application as that’s the most needed use case, but this may be expanded in the future.
The rules are a simple combination of sets of conflicting entitlements – if a user has any one of (or all of) set A, they should not have any one of (or all of) set B. In the example shown below a user can have either of the MS365 E5 AAD Premium 1 or Premium 2 licenses but not both.
There can be multiple rules defined for an application.
The default behaviour for access requests is to block the user getting the new entitlement in conflict. However this behaviour can be set in the access request settings.
The Allow requests with custom settings option will permit selection of a specific flow to be run in the case of a SoD violation. Perhaps you want a different process of approval for SoD violations.
With a rule in place, we can test an Access Request.
Requesting Access with SoD Checks
In this environment there are multiple entitlement bundles defined, including one for each of the AAD Premium licenses.
When a user who has one of the licenses (say P1) requests the other, (P2) they are presented with the conflict details and cannot continue.
If we had changed the access request setting to allow the conflict, we would see the following. The user is warned, but can still request access.
This is for user access requests. The administrator can still add conflicting entitlements to the user. For the sake of this article, the admin has added the second entitlement so the user has both AAD Premium P1 and P2 licenses.
Recertifying Access with SoD Violations
The SoD checking has also been added to the Access Certification mechanism.
When running a Resource campaign with entitlements for this application, the user is highlighted with an SOD CONFLICT warning. Expanding either row with the warning will show the SoD conflict details.
If the campaign has been set to action a Revoke decision, any of the conflicting entitlements could be removed by clicking the Revoke button.
Reporting with SoD
Finally some of the reporting capabilities have been extended to cover SoD. Any access request allowed with a SoD violation will indicate so on the Past Access Requests (Conditions) report. You need to add the Conflict Name column to the report.
The report will then show any conflicts (you need to scroll right to find the column).
This additional data will be included in the CSV Export.
The System Log events show additional detail if SoD rules have been evaluated and violations allowed.
Conclusion
Separation of Duties is a fundamental IGA control for some customers. Okta has implemented SoD by leveraging the Entitlements Management capability in Okta Identity Governance. This article has provided a brief introduction to this new feature, looking at configuration of SoD rules, access request with SoD checking, access certification with SoD evaluation, and reporting.
IAMSE