Unleashing Precision: Enhancing Salesforce User Access Reviews with Custom Okta Entitlements Management

Introduction

In the ever-evolving realm of user access and security, the marriage of Okta and Salesforce presents a powerful synergy. While Okta’s out-of-the-box (OOTB) connector for Salesforce Governance is undoubtedly a valuable asset, it falls short when it comes to the nuance of fine-grained access certification. Picture this common scenario: reviewing a Profile or Permission Set for Salesforce, yet lacking the crucial context of specific IT or Business-sensitive Salesforce permissions granted to a user.

In this blog post, I uncover a custom workflow that transcends this limitation of the standard Okta-Salesforce Governance connector. Developed to address the gap in fine-grained access certification, this workflow leverages SOQL (Salesforce Object Query Language) queries to extract intricate details from Salesforce. The result? A tailored Okta Entitlements Management system that goes beyond the surface, providing reviewers with a comprehensive understanding of the IT or Business-sensitive permissions encapsulated within Profiles and Permission Sets.

I am excited to share how this custom integration empowers organizations to elevate their User Access Reviews (UAR). By intertwining Salesforce’s inherent capabilities with the precision of Okta Entitlements Management, you gain unparalleled insights during the review process. No longer confined to the confines of Profiles and Permission Sets, you can confidently make informed decisions, armed with the contextual knowledge of permissions inherited by each user.

Join me on this journey as we explore the intricacies of this custom workflow, unveiling precision, context, and confidence in Salesforce User Access Reviews.

Background – Salesforce out-of-the-box (OOTB) connector

In the intricate tapestry of Salesforce user access, the linchpins are undeniably the Profiles and Permission Sets. These two entities wield immense power, governing the realm of permissions with a precision that defines what a user can create, read, edit, and delete (CRED) across various Salesforce objects and settings. From the granular control of user settings to the sweeping authority over app settings, Apex class access, Visualforce page access, and beyond, Profiles and Permission Sets intricately shape the Salesforce experience.

Yet, despite the pivotal role of Profiles and Permission Sets, the out-of-the-box Okta Salesforce governance connector, while revealing the assigned names of these entities, falls short in aggregating and delivering comprehensive insights into the exact permissions inherited. This gap, which we address in this blog, prompts the need for a custom approach that goes beyond nomenclature, unlocking the granular details that fuel informed decision-making during User Access Reviews.

Let’s take a look at at an example, below is the screenshot of System Administrator Profile in Salesforce highlighting (some of the many) various administrative permissions this Profile grants to the assigned user:

The next screenshot shows an active User Access Review (UAR) campaign in Okta; while the data aggregated with the Salesforce OOTB Governance connector; showing our user having access to the System Administrator Profile but it does not let me as reviewer know what permissions they inherit as being a member of this Profile.

Salesforce Profile Cloning Problem

User Access Certification with the OOTB connector for Salesforce brings to light a nuanced challenge—profile cloning. While Salesforce offers the flexibility of profile cloning, this seemingly innocuous feature can sow the seeds of confusion and potential security risks.

In the realm of User Access Reviews (UAR) within Okta, the out-of-the-box connector dutifully aggregates data, presenting an active snapshot of user access. However, this picture can be deceiving, as illustrated in the image below. It indicates that access is granted through a profile named “End User Profile.” However, here lies the catch—this profile is an exact clone of the venerable “System Administrator” Profile.

This revelation introduces a significant problem. Imagine a reviewer assessing access solely based on profile names; in this case, the “End User Profile” might appear innocuous. However, beneath the surface lies a potentially perilous replication of the mighty “System Administrator” Profile. Without the contextual understanding of the cloned nature of these profiles, reviewers may inadvertently greenlight access, oblivious to the inherent risks.

Crafting the Seamless Solution with Okta Workflows: Navigating the Complexity

In the realm of Okta Workflows, possibilities are boundless. With a toolkit that spans across diverse functionalities, encompassing more than 10+ complex workflows, attempting to encapsulate the details within the confines of this blog would only breed confusion. To steer clear of this potential maze, I present to you a representational diagram that serves as a roadmap, guiding you through the intricate flow of these workflows. You can always download the Workflow export from the download button in the beginning of this article.

Before immersing ourselves in the nitty-gritty, let’s address key elements crucial for deciphering the workflows. This foundational understanding will pave the way for a comprehensive exploration of our solution.

1. Identifying Key Salesforce Permissions for UAR: Simplifying Complexity
   
   When it comes to User Access Reviews (UAR) within Salesforce, the potential scope of permissions is vast and intricate. To streamline our approach and enhance clarity, we narrow our focus to three pivotal permissions: Author Apex, Customize Application and Modify All Data. Let’s assume these permissions hold paramount importance, identified as IT-sensitive and crucial under compliance mandates, demanding meticulous certification.
   
   Our goal is straightforward: if any user is assigned any of these three specific permissions—whether through a Permission Set or a Profile—we aim to include them in the UAR.
   
2. Salesforce Object Query Language (SOQL)
   
   Salesforce Object Query Language (SOQL) is a query language used to search and retrieve data from Salesforce databases. It is specifically designed for querying Salesforce data and is similar in syntax to SQL (Structured Query Language), which is used for querying and manipulating data in relational databases. SOQL allows you to query Salesforce objects, which are essentially database tables, to retrieve specific information.

Now, lets deep dive into our Workflow! This workflow has 2 major components, let’s look into each one of them.

Part – 1: Create Salesforce Sensitive Permissions as Entitlement in Custom Okta Application

1. First step is to create a custom application in Okta 
2. Then enable Okta Governance Engine for the application under general application settings
3. For the newly created application create entitlements for our identified sensitive Salesforce permissions
4. For all the entitlements created store the entitlement IDs in a workflow table as we will be using them later when creating Okta entitlement bundles

Your setup should resemble the visual representation depicted in the image below:

Part – 2: Query Salesforce with SOQL and create Okta Entitlement Bundles for each Profile and Assign Bundles to Okta Users

1. Query Salesforce with SOQL to get the Profiles which have our 3 identified sensitive permissions, below is the query used:
   
   Select Assignee.Name, Assignee.email, PermissionSet.label, PermissionSet.Name, PermissionSet.profile.Name, PermissionSet.PermissionsModifyAllData, PermissionSet.PermissionsCustomizeApplication, PermissionSet.PermissionsAuthorApex
FROM PERMISSIONSETASSIGNMENT
WHERE permissionsetid in (
SELECT ID
FROM Permissionset
WHERE (PermissionsModifyAllData= true OR
PermissionsAuthorApex= true OR
PermissionsCustomizeApplication= true ))
and Assignee.IsActive = true
ORDER by  PermissionSet.profile.Name, Assignee.Name
   
   Following is one of the JSON objects returned:
   
2. Next, we process all the objects returned as a list from Salesforce and structure them so we can create Okta Entitlement Bundles for each Profile 
3. Call the Okta’s Entitlement Bundles API to create the Entitlement Bundles 
   
   Your setup should now resemble the visual representation depicted in the image below:
   
   
   
4. Reading the objects returned by Salesforce you would now search the user in Okta and get Okta’ User ID
5. Lastly, you would assign the user equivalent Okta Entitlement Bundles as returned by Salesforce as Profiles, this is done via. Okta OIG Grants APIs

Finally … time to launch another Salesforce UAR Campaign

In the campaign below, assuming the role of the reviewer, I am now equipped with an enriched perspective. Beyond merely identifying the Salesforce Profile as “System Administrator,” I also gain visibility into the specific Salesforce sensitive permissions (the 3 permissions we identified early on) assigned to this System Profile. This newfound context empowers me, as a reviewer, to make more informed and confident certification decisions.



This enhancement proves pivotal in elevating the rigor of security reviews, particularly for a critical enterprise application like Salesforce. The ability to discern and comprehend the granular details of permissions associated with a profile significantly augments the depth and precision of the certification process, contributing to an overall bolstered security posture.

Solving the Profile Clone Problem in Salesforce UAR

This resolution also addresses the persistent challenge posed by Salesforce cloned Profiles in User Access Reviews (UAR). As previously outlined in the blog, the “End User Profile” is identified as a clone of the “System Administrator” Profile. With the newfound capability in the UAR, my reliance on the profile name alone is no longer the sole determinant.

By having access to additional context, specifically the presence of Salesforce-identified sensitive permissions within the Profile, I am now empowered to make more informed decisions during the review process. In the case of the “End User Profile,” where these sensitive permissions are identified, I can judiciously assess whether the user should retain such access. This refined approach mitigates the risk associated with cloned Profiles, fostering a more secure and contextually aware user access governance model.

Conclusions and Next Steps

Expanding on this holistic approach, consider the prospect of building additional workflows for remediation purposes. In scenarios where access revocations are warranted at the conclusion of a campaign, you can seamlessly invoke these revocations as event hooks within Okta Workflows. By doing so, you unlock the capability to call Salesforce APIs, effecting the necessary remediation actions to curtail a user’s access tied to specific Profiles or Permission Sets automatically without any admin intervention.

Given the bundled model architecture in play, explore the integration of Access Request and Approvals within Okta. This introduces the potential for users to request access to designated bundles, such as the Salesforce Administrator bundle, directly through Okta. Before provisioning this access, Okta can facilitate a robust approval process, ensuring appropriate authorization. Once approvals are secured, another Okta Workflow can be triggered to provision the requested access to the user in alignment with the approved access.

In essence, the versatility of Okta Workflows opens up a realm of possibilities, providing a comprehensive solution that not only identifies and assesses access but also actively manages and remediates access-related issues. The bundled architecture, coupled with Access Request and Approvals, establishes a dynamic and responsive user access governance model, truly making the world your oyster within the Okta ecosystem.