We are currently looking into using Applications in ISC to help organize our larger sources into smaller chunks. I’ve created an Application for AD and added the appropriate Access Profiles. However, since Apps only look at single sources, I cannot add the SSO group required from Okta.
I was hoping I could use Role Definitions to help automate the SSO group based on Application membership, but that doesn’t seem to be an option. The only alternative I see is to base the Role definition on each individual entitlement that’s a part of the Application which isn’t very efficient and will change often.
Do y’all have any suggestions on how to automate a group assignment from another source based on Application membership?
In SailPoint Identity Security Cloud (ISC), Role assignment criteria cannot directly evaluate “Application membership.” Attempting to map a Role to every individual entitlement within an Application creates a fragile, high-maintenance setup that breaks whenever the application’s underlying entitlements change.
Three standard, scalable architectural patterns solve this problem:
Option 1: Convert the Request Item to a Multi-Source Role (Recommended)
In ISC, Applications and Access Profiles are single-source centric, but Roles are multi-source aggregators.
Instead of exposing the single-source AD Application to users for requests, wrap the access into a requestable Role:
Create an Access Profile for the AD access.
Create an Access Profile for the Okta SSO Group.
Create a Role (e.g., [App Name] User Access):
Add both the AD Access Profile and the Okta Access Profile under Manage Access.
Enable the Role for Access Requests.
Result: When a user requests the Role, ISC automatically provisions both the AD entitlements and the Okta SSO group in a single request and workflow.
Option 2: Automate via SailPoint Workflows
If the AD Application must remain the requestable entity, use SailPoint Workflows to trigger the Okta group assignment automatically behind the scenes.
Trigger: Set the workflow trigger to Access Request Decision (or Provisioning Completed).
Filter: Filter for the specific AD Access Profile / Application being granted.
Action: Add a Manage Access step (or an HTTP Request step targeting the v3/access-requests API) to grant the Okta Access Profile / Entitlement to the requesting identity.
Why this works: It completely decouples Okta management from the AD request, eliminating the need to maintain entitlement lists in Role criteria.
Option 3: Role Criteria via a Single “Anchor” Entitlement
If a Role must auto-assign the Okta group based on existing AD access, do not select every entitlement in the Application. Instead, identify a single “Anchor” entitlement that every user of that Application is guaranteed to receive (such as a core AD security group or account attribute).
Create a Role containing only the Okta SSO Group Access Profile.
Result: Once the Application provisions the anchor AD group to the user, ISC identity processing detects it, fulfills the Role criteria, and automatically provisions the Okta SSO group.
Summary Recommendation
For new setups: Use Option 1 (Multi-Source Role). It is the cleanest native ISC design pattern for bundling access across multiple sources.
If keeping the App request model: Use Option 2 (Workflows) for clean event-driven automation, or Option 3 (Anchor Entitlement) if you prefer identity processing to drive assignment.
Option 1 means we can’t use the Applications tab in Request Center which is one of the main reasons we like the App functionality. We already use Roles to assign AD and Okta groups, but in its current state, that means we would be unable to use Applications.
Option 2 would cause workflow bloat and we’d quickly run out.
Option 3 may work. I originally thought about this with existing AD Groups, but if I created a generic group instead and add that one to the AP’s, perhaps I could anchor off that one. I’ll look into this..this might work.
Hello Michael. Yeah, there is no way to point Role criteria directly at an Application. Role Standard Criteria supports Identity Attribute, Account Attribute, or Entitlement (role assignment). For access requests, an Access Application groups a source’s access profiles in the Request Center, while Roles can bundle access across multiple sources (app config).
For what you are after, I would lean on the anchor idea only if you already have an AD group that everyone getting this access actually receives. If you do, it is pretty clean: create a Role containing the Okta access profile and set the Standard Criteria to that AD entitlement. When the identity is next analyzed and meets the criterion, the Role assignment is applied and the Okta access can be provisioned.
The important part is that the anchor must genuinely be common to everyone in that population. Simply creating a marker group, or associating an access profile containing it with the Application, does not grant it to everyone. Access profiles under an Application remain individually requestable.
If there is no shared AD entitlement to use as the anchor, a workflow is another option that keeps the Application request experience intact. You could use Access Request Decision, scope it to the specific AD access profile and only proceed when that request is approved, then use Manage Access to add the Okta access profile to requestedFor (triggers, actions).
Access Request Decision reflects the access-request decision, not confirmation that AD provisioning completed successfully. Manage Access also submits a separate access change, so if the Okta access profile has its own approval configured, that approval process will still apply.
@mcalder Applications in ISC are primarily a cataloging layer and aren’t directly usable as role criteria. A common approach is to create a Role that contains both the AD access and the Okta SSO group, then assign that role based on identity attributes, lifecycle states, or access criteria.
If you need dynamic automation based on Application access, consider:
Using Access Request workflows to automatically add the Okta group when the Application is requested.
Creating a custom workflow/event trigger that monitors access changes and provisions the Okta entitlement.
Using Role criteria based on stable identity attributes rather than individual entitlements where possible.
Currently, there isn’t a native way to assign an entitlement from one source directly based on Application membership in another source.