# Application Visibility User Help > Application Visibility User Help # Application Visibility User Help # SailPoint Application Visibility Application Visibility provides visibility into the applications that are running in your environment. This includes commercial business applications like Salesforce and Workday, applications developed in house, and unsanctioned applications, often referred to as shadow IT applications. To get started, you must configure your Identity Provider and connect to Application Visibility to provide visibility into SaaS usage and risk in your organization. - [Microsoft Entra ID](https://documentation.sailpoint.com/saam/help/idp/entra_idp.html) - [Okta](https://documentation.sailpoint.com/saam/help/idp/okta_idp.html) - [Other IdP](https://documentation.sailpoint.com/saam/help/idp/other_idp.html) Next, you must deploy the [browser extension](https://documentation.sailpoint.com/saam/help/browser_extension/index.html) in your environment to discover user-related activities. Notes - The browser extension does not distinguish between a user’s personal activities and business activities, and will capture personal activities conducted using any browser in which the extension is deployed. It is your responsibility to ensure that the collection and use of personal activity data complies with applicable law and contract terms. Please contact your legal department with any questions. - All privacy-related features can be managed and optionally disabled. Refer to [Configuring Privacy Controls](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html) for additional information. Once you have connected to your Identity Provider and deployed the browser extension, you can view inventories of the applications, user accounts, and accounts in your environment discovered by the Application Visibility browser extension and [IdP connector](https://documentation.sailpoint.com/saam/help/idp/index.html). ## User Levels and Permissions To administer Application Visibility, users must be assigned the Org Admin user level. For read-only access, users must be assigned either the Cert Admin, Helpdesk Admin, or Report Admin user level. For more information about these user levels and their permissions, refer to [User Level Access Matrix](https://documentation.sailpoint.com/saas/help/common/users/user_level_matrix.html). - **Global Administrator** - Has full access to the admin console and can configure and manage all aspects of the product. Can also configure system configurations and define privacy controls. - **Read-only Administrator** - Has limited access to the admin console. They can retrieve and view data, but cannot make modifications or deletions. ## Accessing Application Visibility The method to access the Application Visibility portal depends on your tenant region. Choose your next step based on the URL provided in your initial connectivity instructions **To access the Application Visibility portal:** 1. Open a browser and enter `https://app.us-east4.savvy.security/`. 1. Enter your admin credentials. The Application Visibility portal is displayed. **To access the Application Visibility portal:** 1. Open a browser and enter `https://app.savvy.security/`. 1. Enter your admin credentials. The Application Visibility portal is displayed. # Managing Custom Applications The Application Visibility [browser extension](https://documentation.sailpoint.com/saam/help/browser_extension/index.html) can detect accounts associated with any application, whether public SaaS platforms or private, internal systems. Inventory entries for private applications are created automatically based on their apex domain (the highest-level domain name without any subdomains). For example, the apex domain of portal.hr.example.com is example.com. You can define a custom application to provide a clear, human-readable name and manage it as part of your SaaS inventory. In some cases, you may want to define multiple custom applications, each corresponding to different subdomains or URL paths, especially for on-premises or self-hosted environments. By default, the **Custom apps** tab is displayed listing discovered and manually created custom applications. The **Overwritten apps** tab displays applications that have been edited, such as adding or removing URLs. The view can be searched by application name or part name. To edit a custom application, select **Actions** **> Edit**. To delete a custom application, select **Actions** **> Delete**. Once a custom application is defined: - The [SaaS inventory](https://documentation.sailpoint.com/saam/help/inventory/saas.html) will automatically rebuild to include the new entries. - Future [activity logs](https://documentation.sailpoint.com/saam/help/data_analytics.html#activity-logs) detected under the defined URLs will be attributed to the custom application. Note The default Custom apps view updates automatically within 24 hours. To verify inventory changes immediately, switch the [SaaS inventory view](https://documentation.sailpoint.com/saam/help/inventory/saas.html) to **Live**. **To create a custom application:** 1. Go to **Settings > Custom apps**. 1. Select **New App**. 1. In the **App Name** field, enter a unique name. 1. In the **URLs** field, enter URLs for domains, subdomains, or paths. 1. Select the **Reputation** dropdown, and select the risk that applies to this application. 1. Select the **Category** dropdown and select the or the category of the application. 1. Select **Save**. # Viewing Data Analytics Application Visibility analytics are a flexible method for admins to log, query, and visualize data insights for security teams to track priority risks for their organization. The Application Visibility platform provides aggregated data in both [streaming log](#activity-logs) and [visualized dashboard](#creating-visualizations) representations. All data represented in Application Visibility is sourced from a centralized audit log and presented in either a visualization or streaming log format. ## Activity Logs When a user views a website in their browser, the [browser extension](https://documentation.sailpoint.com/saam/help/browser_extension/index.html) records metadata of the activity such as browser version and URL of the website, and stores it as an event in the activity log. Logs can be filtered based upon the web category of user event. Log web filters include: - **All** - All audit logs associated with a Application Visibility tenant. - **Identity** - Identity specific user events that displays typed usernames, login methods, application URLs, and identity risks. - **GenAI** -- User events that show Generative AI specific applications, users, and any data activity associated with it. - **Data** - Data-specific user events around user download/upload events, applications/URLs used, and filenames. - **OAuth** - Authorization specific user events that show whenever user's perform authorization-level events and scopes associated from a provider such as Microsoft, Google, etc. [Log queries](#building-a-basic-log-query) can be created to further filter the activity log, and you can create a [visualization](#creating-visualizations) to show a graphical representation of the log data. Select the **Grid** / **Visualization** toggle to switch between view types: - **Grid View** - The default tabular view displaying detailed application and account metrics. - **Visualization Mode** - Keeps the same underlying query but allows you to create visualization charts and visual summaries based on SaaS attributes, usage, or risk indicators. Select the Export data as CSV icon to export the grid view as a CSV file for further analysis and reporting. Selecting a log entry opens the detail panel with detailed contextual information. **To view an activity log:** 1. Select **Logs** from the left hand pane. 1. Select **Web** and choose the desired web filter tab. 1. Select an entry to view the events metadata. ## Building a Basic Log Query Basic log queries can be created by selecting the filter dropdowns to refine your search criteria. **To build a basic log query:** 1. Select **Logs** from the left hand pane. 1. Select **Web** and choose the desired web filter tab. 1. Select the filter dropdowns to refine your search. - **Last 7 days** - select the desired time frame for the logs to be evaluated within. - **Department** - select the desired department. - **Log Level** - select the desired log level. 1. Select **More Filters** to further filter based upon specific domains, users, risky actions, and applications. The log results are displayed based upon your selected log query. To save your query, select the Database icon next to the search box, and select **Save as new query**. ## Building Advanced Log Queries Custom log queries can be created using the log search box. Log queries for specific use cases can be built using [predefined search query syntax's](#search-query-syntax) and combined with AND, OR, NOT, AND NOT, and TO operators. **To build an advanced log query:** 1. Select **Logs** from the left hand pane. 1. Select **Web** and choose the desired web filter tab. 1. Enter the required syntax into the search box. 1. Select the Database icon next to the Log search box, and select **Save as new query**. Once the advanced log query has been saved, you can [create a visualization](https://documentation.sailpoint.com/saam/help/data_analytics.html#creating-visualizations) to view a graphical representation of the log data. The table below shows example advanced queries for common use cases. | **Category** | **Use Case** | **Syntax Example** | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | App-Based Log Query | Parse out for all logs associated with Microsoft apps, excluding SharePoint. | `app:Microsoft AND NOT app:"Microsoft Sharepoint"` | | Risk-Based Log Query | Users entering weak corporate credentials. **NOTE**: Password strength is determined by a [zxcvbn password strength evaluator](https://github.com/dropbox/zxcvbn). | `action.keyword:"Risky Sign-in" AND password_strength:{1 TO 3} AND is_business:true` The syntax example surfaces whenever a user has performed a Risky Login action (`action.keyword`), has a very weak, weak, or medium password (`password_strength:{1 TO 3}`), and only looks for corporate credentials with a corporate username (`is_business:true`). | | Reused Passwords Query | Surface corporate credential reuse where Application Visibility has a medium or high confidence level of this risk. | `action.keyword:"Risky Sign-in" AND is_business:true AND reused_passwords:* AND NOT risk_confidence:RISK_CONFIDENCE_LOW` This syntax example surfaces corporate credential reuse (`action.keyword,is_business,reused_password:*`filters) and prioritizes more accurate confidence of credential reuse (`risk_confidence`). Note that in this query a wildcard character is used next to the `reused_passwords` attribute to cover all applications that a user re-uses their password against. Additionally, this query uses a series of `AND` operators to connect the query as well as an `AND NOT` operator to remove all logs that have a low confidence associated with password reuse. | Note Use syntax `app:[app name]` when searching for applications in logs, and `app_name:[app name]` when searching the SaaS Inventory and Accounts Inventory. ## Viewing a Specific User's Session You can view the user details for a specific event. This allows an administrator to trace the URL path the user followed to get to the logged event. This can be helpful when tracing context on how a user navigated and logged into an application. **To follow a specific user's session:** 1. Select **Logs** from the left hand pane. 1. Select **Web** and choose the desired web filter tab. 1. Right-click on the desired log and select **Follow Session**. 1. Select **X** next to Session to return to the previous log view. ### Search Query Syntax The table below shows commonly used search query syntax's that can be constructed within the search box. These can be combined using AND, OR, NOT, and AND NOT operators. These operators must be capitalized within the format of a search query. The following is an example advanced search query that combines multiple attributes: `action.keyword:sign-in AND NOT login_method:("Enterprise single sign-on", "Auto detected") AND is_business:true AND NOT app:{{list.IdP}}` | Query Attribute | Description | Values | Examples | | ------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | `app` (when searching logs) `app_name` (when searching inventory’s) | Application Name tied to a Application Visibility Log event. This can be presented as the direct application name, a partial name with a wildcard, or referencing a [list](https://documentation.sailpoint.com/saam/help/lists.html) using brackets. | Any Application Name or List value `Google` `{{list.idp-apps}}` | `app:Dropbox` `app:Microsoft*` `app:{{list.idp-apps}}` | | `app_labels` | Application category associated with application log events. | Any application category value `"Cloud Storage"` `"Project Management"` `"File Sharing"` | `app_labels:"Cloud Storage"` `app_labels:"Cloud Storage" OR app_labels:"File Sharing"` | | `action.keyword` | Action a user is performing on a Application Visibility Log event. | `Browse` `Sign-in` `"Risky Sign-in"` `"Credentials Submitted"` `Download` `Upload` `Share` `"Authorization Success"` | `action.keyword:Browse` `action.keyword:"Credentials Submitted"` | | `user` | A username identifying which user is associated with a login event. This is the user that the Application Visibility extension has authenticated. | `paul.bunyan` | `user:paul.bunyan` | | `session_user` | The account’s username. The value a user enters into a login form on a web page, or retrieved through SSO. | `paul.bunyan@company.com` `paul*` `admin` | `session_user:"paul.bunyan@company.com"` `session_user:paul*` | | `profile_user` | The username associated with the end user's browser profile. This is not a commonly-used log filter attribute. | `paul.bunyan@gmail.com` | `profile_user:"paul.bunyan@gmail.com"` | | `url` | URLs associated with Application Visibility log events. | `[www.bing.com](http://www.bing.com/)` `*google.com` `mail.google.com/u/0` | `url:[www.bing.com](http://www.bing.com/)` `url:*google.com` `url:"mail.google.com/u/0"` | | `domain` | Domains associated with Application Visibility log events. | `bing.com` `*microsoft.com` | `domain:bing.com` `domain:*microsoft.com` | | `is_business` | A boolean value that determines if a username is within the corporate domain. If this is set to true it will only display log query events for usernames that match the list of business domains. i.e. if the domain of company.com is in the list of business domains, all users with a username of [user@company.com](mailto:user@company.com) will display. Setting this to false will remove all business accounts from this. | `true` `false` | `is_business:true` `is_business:false` | | `login_method` | Attribute that determines how a user authenticated into an application. | `"Login form"` `"Enterprise single sign-on"` `"Consumer single sign-on"` `"Auto detected"` | `login_method:"Login form"` `login_method:("Enterprise single sign-on", "Auto detected")` | | `permissions` | Scope associated with Permissions allowed with a user's authorization event. | Any OIDC scope associated with an authorization event `openid` `profile` `offline_access` | `permissions:offline_access` | | `credential_risk_types` | Attribute that determines what type of risky sign-in associated with a Application Visibility login event. | `Reused` `Weak` `Compromised` `"Shared account"` `"No pwd manager"` `"No MFA"` `"Contains keyword"` | `credential_risk_types:Weak` `credential_risk_types:Reused AND NOT credential_risk_types:"No pwd manager"` | | `password_compromised` | A boolean value determining if a user's credentials are compromised. | `true` `false` | `password_compromised:true` `password_compromised:false` | | `password_contains_keyword` | A boolean value determining if a user's credentials contain a value populated within the password-substrings list. | `true` `false` | `password_contains_keyword:true` `password_contains_keyword:false` | | `password_strength` | Numerical Attribute from 0-6 that represents password strength as outlined against the [zxcvbn password strength evaluator](https://github.com/dropbox/zxcvbn). Use brackets and a TO operator to define a range of values. 0: Single Sign-On 1: Very Weak 2: Weak 3: Medium 4: Strong 5: Very Strong | `0` `{1 TO 5}` | `password_strength:0` `password_strength:{1 TO 5}` | | `reused_passwords` | Application name where Reused Password occurs. Set this to a wildcard value to query all apps with password reuse.Query this on a per-app basis to query around which apps specifically are having a reused credential risk. | `*` `Microsoft*` `Google` | `reused_passwords:*` `reused_passwords:Microsoft*` `NOT reused_passwords:Google` | | `risk_confidence` | Confidence of the Application Visibility platform around Risk level. | `RISK_CONFIDENCE_LOW` `RISK_CONFIDENCE_MEDIUM` `RISK_CONFIDENCE_HIGH` | `risk_confidence:RISK_CONFIDENCE_HIGH` `NOT risk_confidence:RISK_CONFIDENCE_LOW` | | `download_file_type` | Type of file performed via a file download event. Wildcard and NOT logic are available to perform against this log attribute query. | `pdf` `*ml` `html` | `download_file_type:pdf` `download_file_type:*ml` `NOT download_file_type:html` | | `upload_file_type` | Type of file performed via a file upload event. Wildcard and NOT logic are available to perform against this log attribute query. | `pdf` `*ml` `html` | `upload_file_type:pdf` `upload_file_type:*ml` `NOT upload_file_type:html` | | `clipboard_data_size` | The file size of the pasted string. | `25 bytes` | `clipboard_data_size:>25` | | `clipboard_sensitive_keywords` | The detected sensitive keyword(s). | `acquisition` `forecast` | `clipboard_sensitive_keywords: acquisition, forecast` | ## Creating Visualizations Visualizations are a way to create a graphical representation of log data that the Application Visibility platform has captured. There are two methods of constructing visualizations: - **Visualization Preview** - A temporary visualization of log data for a quick visualization of streaming log data. - **Visualization Library** - A more permanent graphical view of log data. This can be shared with other admins and be used within Dashboards. **To create a visualization preview from the log menu:** 1. Select the visualization icon  from the top right. 1. Select **Visualization type** from the left pane. 1. Select the type of visualization. Options include Bar, Counter, Donut, Line, Pie, and Table. 1. Additional fields are displayed based upon the selected visualization type. 1. Configure the additional fields that are required. You can break down data on a per slice, axis, or row/column basis depending on the visualization type selected. **To create a table of apps visualization from the visualization library:** 1. Go to  **Settings > Visualization Library**. 1. Select **+ New visualization**. 1. In the New visualization window choose **Web visualization** and select **Create**. 1. Select the type of vitalization. Option include Bar, Counter, Donut, Line, Pie, and Table. 1. Additional fields are displayed based upon the selected visualization type. 1. Configure the additional fields that are required. 1. Select **Save** in the top right corner of the visualization editor. 1. Enter a name. 1. Select **Save** to save the visualization. ## Viewing Dashboards Application Visibility comes with out-of-the-box dashboards, providing visibility into SaaS usage, security posture, and identity hygiene across your organization. Each dashboard presents interactive widgets, trend charts, and data. Use quick filters to refine the visualization data by department and time frame. **To view an out-of-the-box dashboard:** 1. Go to **Dashboards**. 1. Select the desired dashboard tab from the dashboard ribbon. To view the underlying data for a visualization, select **Actions** **> Show data**. ### SaaS Sprawl Dashboard The SaaS Sprawl dashboard provides an overview of your organization’s SaaS footprint and helps identify unmanaged or high-risk applications that warrant review. A summary of all known SaaS applications are shown where employees have at least one account authenticated with corporate credentials. Applications represented here exclude unmapped domains and focus on SaaS platforms and custom apps discovered through the [browser extension](https://documentation.sailpoint.com/saam/help/browser_extension/index.html) and [IdP connector](https://documentation.sailpoint.com/saam/help/idp/index.html). Key insights include: - Total SaaS apps and total discovered accounts across the environment. - SSO adoption rate, highlighting the percentage of SaaS applications accessed through SSO versus direct login. - A ranked list of applications recommended for onboarding prioritized by risk score, suggesting which apps should be onboarded to your IdP for centralized access control. - Recently adopted SaaS applications, helping you track emerging SaaS usage trends or newly introduced services. ### SSO Bypass Dashboard The SSO Bypass dashboard highlights SSO coverage gaps, focusing on applications that were onboarded to your IdP but still allow local (non-SSO) logins. This helps ensure that once applications are integrated with your IdP, employees are consistently authenticating through managed SSO and not bypassing it through direct credentials. In order to reach this goal you will need to work with the relevant application owners on blocking local access to their apps, where applicable. In some cases, local access is limited to specific tenants or instances of an application. To investigate such cases, use the [Activity Logs](https://documentation.sailpoint.com/saam/help/data_analytics.html#activity-logs) to drill down into user and tenant level details. ### Gen AI Dashboard The Gen AI dashboard focuses on Generative AI usage across your organization, categorized by tool type, helping you understand how Gen AI is adopted across your organization and assess its security implications. Key insights include: - The total number of Gen AI applications in use. - The number of users interacting with Gen AI tools. - File uploads to Gen AI services, helping detect potential data exfiltration. - Categorized usage breakdowns, including: - Text generation tools, such as ChatGPT. - Code AI tools. - Note-taking or summarization AI tools. - Risky AI apps, where data handling or privacy posture requires special attention. ### IdP Security Dashboard The IdP Security dashboard focuses on gaps and weaknesses within your IdP configuration, helping you maintain strong identity governance. The dashboard provides a quick compliance overview and helps identify remediations to strengthen identity security posture. Key insights include: - Inactive accounts that remain enabled in the IdP. - Weak MFA enforcement or inconsistent MFA enrollment. - Administrative accounts that do not comply with internal security policies, for example those not following a password rotation policy. # Managing Departments Departments allow admins to create groups of users based upon business area, which can be used to filter [dashboards](https://documentation.sailpoint.com/saam/help/data_analytics.html#viewing-dashboards) and [logs](https://documentation.sailpoint.com/saam/help/data_analytics.html#activity-logs). Departments do not affect policy scoping or any configuration within Application Visibility. **To create a department:** 1. Go to **General settings > Target** groups. 1. Select **New department**. 1. On the New department window, complete the following: - In the **Name** field, enter a name to identify the department. - (Optional) In the **Description** field, enter a description for the department. 1. Select **Create**. 1. On the **Departments** page, select the newly created list item. 1. On the list details page, select **Add users**. 1. On the Add users or groups window, complete the following: - Select **Users** to add users from your IdP. - Select **Groups** to add groups from your IdP. 1. Select **Add**. The department is available to be selected in the Departments filter on [dashboards](https://documentation.sailpoint.com/saam/help/data_analytics.html#viewing-dashboards) and [logs](https://documentation.sailpoint.com/saam/help/data_analytics.html#activity-logs). # Managing Lists Lists allow admins to create reusable sets of values such as domains, applications, or identifiers, that can be used in [global allow lists](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#managing-global-allowlist) and [search queries](https://documentation.sailpoint.com/saam/help/data_analytics.html#building-advanced-log-queries) for log analysis. Lists enable admins to: - Update and manage values in a single place within Application Visibility. - Reduce repetitive entry and human error. - Define policy conditions once and apply them across multiple controls. **To create a list:** 1. Go to **General settings > Lists**. 1. Select **+ New > List**. 1. In the **Choose list type** window, select the desired list type. 1. Select **Next**. 1. On the New list window, complete the following: - In the **Name** field, enter a name to identify the list. - (Optional) In the **Description** field, enter a description for the list. 1. Select **Create**. 1. On the **Lists** page, select the newly created list item. 1. On the list details page, select **Add items**. 1. Add the desired items and select **Add**. The list is available to be used in [global allow lists](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#managing-global-allowlist) and [search queries](https://documentation.sailpoint.com/saam/help/data_analytics.html#building-advanced-log-queries). # Managing Target Groups Target Groups allow admins to control which users and areas of your organization Application Visibility discovery and enforcement actions apply to. This removes the need to create and maintain new groups in your IdP provider, such as Okta and Microsoft Entra ID. Once defined, the target group can be used for policy scoping in [Discovery settings](https://documentation.sailpoint.com/saam/help/settings/security_settings.html#configuring-discovery-settings). A Target Group can include: - Individual users - Existing IdP groups - Any combination of the above **To create a target group:** 1. Go to **General settings > Target groups**. 1. Select **New target group**. 1. On the New target group window, complete the following: - In the **Name** field, enter a name to identify the target group. - (Optional) In the **Description** field, enter a description for the target group. 1. Select **Create**. 1. On the **Target Groups** page, select the newly created list item. 1. On the list details page, select **Add users**. 1. On the Add to target group window, select the **Search for group names** field and complete the following: - Select **Users** to add users from your IdP. - Select **Group** to add groups from your IdP. 1. Select **Add**. The target group is available to be used in [Discovery settings](https://documentation.sailpoint.com/saam/help/settings/security_settings.html#configuring-discovery-settings). # Browser Extension The Application Visibility browser extension provides visibility and supports governance processes across both managed and unmanaged SaaS environments. It operates in the browser to detect, correlate, and enhance governance of certain identity-related activities, without requiring any end-user configuration or interaction. Note The browser extension must be deployed in a currently-supported browser. Contact your Customer Success Manager for more information. ## Deployment and Operation Deployment is supported by any MDM solution, including Intune, Jamf, and Workspace ONE (to be provided by the customer). Once deployed, the browser extension installs and begins operation. It is recommended to deploy the browser extension in a locked state, preventing end users from [disabling it](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html). For cases requiring flexibility, the browser extension supports temporary pause functionality, governed by role-based policy controls. If disabled or temporarily suspended, the browser extension will not operate as described in this documentation. The browser extension automatically authenticates using the logged-in user’s corporate identity, ensuring continuous correlation to the employee’s IdP account. **Deployment Steps** 1. **Identify Scope** - Identify a pilot group, full deployment group, and which browsers will be targeted. 1. **Scope Target Devices** - Create groups in InTune and Jamf to specify which devices will receive the Application Visibility deployment package. 1. **Device Management Configuration** - Follow the deployment guide for your desired management tool, device type, and browser. 1. **Validate Deployment** - View the Application Visibility admin portal to verify that browser extensions are reporting back to the portal. | | | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Intune | [Chrome for Windows](https://documentation.sailpoint.com/saam/help/browser_extension/deployment/intune_chrome_win.html)         [Edge for Windows](https://documentation.sailpoint.com/saam/help/browser_extension/deployment/intune_edge_win.html)         [Chrome for Mac](https://documentation.sailpoint.com/saam/help/browser_extension/deployment/intune_chrome_mac.html) | | Microsoft SCCM | [Chrome for Windows](https://documentation.sailpoint.com/saam/help/browser_extension/deployment/sccm_chrome_win.html)         [Edge for Windows](https://documentation.sailpoint.com/saam/help/browser_extension/deployment/sccm_edge_win.html) | | Group Policy (GPO) | [Chrome for Windows](https://documentation.sailpoint.com/saam/help/browser_extension/deployment/gpo_chrome_win.html)         [Edge for Windows](https://documentation.sailpoint.com/saam/help/browser_extension/deployment/gpo_edge_win.html) | | Jumpcloud | [Chrome for Windows](https://documentation.sailpoint.com/saam/help/browser_extension/deployment/jumpcloud_chrome.html)         [Chrome for Mac](https://documentation.sailpoint.com/saam/help/browser_extension/deployment/jumpcloud_chrome.html) | | Jamf Pro | [Chrome for Mac](https://documentation.sailpoint.com/saam/help/browser_extension/deployment/jamfpro_chrome_mac.html)                 [Edge for Mac](https://documentation.sailpoint.com/saam/help/browser_extension/deployment/jamfpro_edge_mac.html) | | Chrome Enterprise | [Chrome Enterprise](https://documentation.sailpoint.com/saam/help/browser_extension/deployment/chrome_enterprise.html) | | Workspace ONE UEM | [Chrome for Mac](https://documentation.sailpoint.com/saam/help/browser_extension/deployment/workspace_chrome_mac.html) | | Powershell template | [Chrome](https://docs.savvy.security/chrome.ps1)         [Edge](https://docs.savvy.security/edge.ps1) | | Powershell (Self Signed) | [Chrome](https://docs.savvy.security/chrome_signed.ps1)         [Edge](https://docs.savvy.security/edge_signed.ps1)         [Certificate](https://docs.savvy.security/savvy_cs.cer) | ## Intelligent Sign-In Detection Using a generic sign-in detection algorithm, the browser extension recognizes authentication events across any web application. This includes commercial business applications such as Salesforce and Workday, applications accessed for personal, non-work purposes, applications developed in house, and unsanctioned applications, often referred to as shadow IT applications. For each login event, the browser extension: - Detects the username used during authentication. - Evaluates password complexity. - Checks whether the password has appeared in any known breach databases. ## Correlation and Identity Context Because users are always authenticated against the enterprise IdP, the browser extension inherently correlates all discovered accounts and credentials back to the verified corporate identity. This enables Application Visibility to map the full relationship between a user’s primary identity and every account they access across the SaaS environment. ## Activity and Metadata Logging The browser extension records detailed activity logs with contextual metadata. Logged events include: - Browsing session initiation. - File uploads and downloads. - Credential submissions and sign-ins. - Clipboard paste and print operations. This telemetry can be aggregated and analyzed at the browsing-session level, providing security and compliance insights without capturing private content. ## Privacy and Control Admins can define allowlists and bypass rules for specific websites to preserve user privacy. Password complexity and keyword checks are performed entirely on the client side, while compromised and reused passwords are validated using a cryptographically hashed version of the password that is designed to ensure that no plaintext credentials are exposed. All privacy-related features can be managed and optionally disabled. Refer to [Configuring Privacy Controls](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html) for additional information. Important The browser extension does not differentiate between personal applications and business applications, or between a user’s personal activities and business activities. It will capture the same details for personal activities conducted using any browser in which the extension is deployed. Customers are responsible for ensuring that the collection and use of personal activity data complies with applicable law and contract terms, which may include obtaining consent and/or notifying users about potential personal data collection and processing. Please contact your legal department with any questions. # Managing Extensions Application Visibility allows you to control the rollout of browser extension versions by providing stable and the latest browser extension builds. You can [assign specific users or groups](#defining-deployed-extension-builds) the latest build to facilitate testing in a controlled, localized manner. Details of each installed browser extension can be viewed on the **Extensions > Extension management** tab. ## Defining Deployed Extension Builds Application Visibility provides two browser extension builds available for deploying to endpoints: - **Stable Extension** - The recommended version used across the organization. - **Latest Extension** - The newest build intended for controlled rollout for early-adopter testing. By default, all users receive the stable extension. Organizations may optionally assign specific users or groups to receive the latest extension, enabling targeted exposure of new functionality. Details of the current stable and latest browser extension, including version, build and release date can be viewed on the **Extensions > Versions** tab. Updated browser extension versions are deployed to the endpoint through your MDM solution. **To define users to receive the latest extension version:** 1. Go to **Extensions > Versions** tab. 1. In the Latest Extension section, select **Edit users**. 1. From the **Select users or groups** box, select a user or group: - Select **Users** to add users from your IdP. - Select **Groups** to add groups from your IdP. 1. Select **Done**. Application Visibility will push the latest extension version to selected users through your MDM solution. ## Managing Extension Versions The extensions table displays all installed instances of the browser extension. This view can be searched by user. Use this information to determine the version of browser extension deployed to a user, the build, and when communication was last transmitted to Application Visibility. Use quick filters to refine users listed in the table by status, browser and [department](https://documentation.sailpoint.com/saam/help/departments.html). Select the Export data as CSV icon to export the grid view as a CSV file for further analysis and reporting. To temporarily stop the browser extension for all users, select **Pause extensions**. To restart the browser extension for all users select **Unpause extensions > Unpause all**. # Deploying Using Chrome Enterprise 1. [Log into the Application Visibility admin console](https://documentation.sailpoint.com/saam/help/index.html#accessing-application-visibility). 1. Select **Extensions > Deployment** tab. 1. Select the **Managed deployment** tile. 1. On the **Managed deployment** page, copy the following values which will be used later in the deployment: - In the **Extension URL** field, copy the value `https://extension.savvy.security/update.xml`. - In the **Extension ID** field, copy the value `ckdibgmbbhmafmjpjmknleccgcddanan`. 1. Log into the Google admin console at `https://admin.google.com/`. 1. On the left panel go to **Devices > Chrome > Apps & Extensions > Users & Browsers**. 1. Select the relevant Organizational Unit or Group for the deployment, and complete the following: - On the bottom right select the yellow **+** button. - Select **Add Chrome app or extension by ID**. 1. On the **Add Chrome app or extension ID** page, complete the following: - In the **Extension ID** field, enter the value copied from the Application Visibility admin console. - Select **From a custom URL**, and enter the **Extension URL** value copied from the Application Visibility admin console. 1. Select **Save**. 1. Select the **Users & Browser** tab, and select the extension. 1. Change **Installation Policy** to the desired value. Important It is recommended to select **Force Install**, forcing the extension to be deployed automatically. If the **Allow Install** value is selected, users will need to install the extension manually. 1. Select **Save** on the top right. # Deploying Using Group Policy (GPO) for Chrome on Windows 1. [Log into the Application Visibility admin console](https://documentation.sailpoint.com/saam/help/index.html#accessing-application-visibility). 1. Select **Extensions > Deployment** tab. 1. Select the **Managed deployment** tile. 1. On the **Managed deployment** page, copy the following values which will be used later in the deployment: - In the **Extension URL** field, copy the value `https://extension.savvy.security/update.xml`. - In the **Extension ID** field, copy the value `ckdibgmbbhmafmjpjmknleccgcddanan`. 1. Log into the Windows domain controller device. 1. Download the [Google Administrative Templates](https://dl.google.com/dl/edgedl/chrome/policy/policy_templates.zip) to your domain controller. 1. Extract the `windows\admx\google.admx` XML-based administrative template admx file into `C:\Windows\PolicyDefinitions`. 1. Extract the `windows\admx\chrome.admx` XML-based administrative template admx file into `C:\Windows\PolicyDefinitions`. 1. Extract the `windows\admx\en-US\google.adml` admx file into `C:\Windows\PolicyDefinitions\en-US`. 1. Extract the `windows\admx\en-US\chrome.adml` admx file into `C:\Windows\PolicyDefinitions\en-US`. 1. Open the **Group Policy Management Editor**. 1. Create a new GPO policy, or select an existing policy. 1. Right-click your **GPO** and select **Edit**. 1. On the left panel, go to **Computer > User configuration > Policies > Administrative templates > Google > Google Chrome > Extensions**. 1. On the right panel, select **Configure the list of force-installed extensions**, right-click and select **Edit**. 1. On the **Configure the list of force-installed extensions** window, complete the following: - Select **Enabled**. - Select **Show**. - In the **Extension/App IDs and update URLs to be silently installed** field enter `ckdibgmbbhmafmjpjmknleccgcddanan;https://extension.savvy.security/update.xml`. 1. Select **From a custom URL**, and enter the **Extension URL** value copied from the Application Visibility admin console. 1. Select **OK**. # Deploying Using Group Policy (GPO) for Edge on Windows 1. Download and install the [Microsoft Edge GPO Policy Templates](https://learn.microsoft.com/en-us/DeployEdge/configure-microsoft-edge). 1. Log into the Windows domain controller device. 1. Open the **Group Policy Management Editor**. 1. Create a new GPO policy, or select an existing policy. 1. Go to **Computer Configuration > Policies > Administrative Templates > Microsoft Edge > Extensions**. 1. Select **Control which extensions are install silently**, and select **Enabled**. 1. Under **Options**, select **Show**. 1. In the **Show Contents** window, complete the following: - In the **Value** field, enter the value `ckdibgmbbhmafmjpjmknleccgcddanan;https://extension.savvy.security/update.xml`. - Select **OK**. 1. Select **OK**. 1. Verify that Edge is now managed on endpoints: - Open Microsoft Edge on a managed target endpoint. - Go to `edge://extensions` and verify that the extension is installed and enabled. # Deploying Using Microsoft Intune for Chrome on Mac OS 1. Go to `https://endpoint.microsoft.com/#home`. 1. Go to **Endpoint Manager > Devices > Configuration Profiles**. 1. Select **+ Create Profile**. 1. On the **Create a profile** page, complete the following: - In the **Platform** dropdown, select **macOS**. - In the **Profile Type** dropdown, select **Templates**. - In the **Template name** dropdown, select **Preference file**. 1. Select **Create**. 1. On the **Basics** tab, complete the following: - In the **Name** field, enter a name to identify the profile. - In the **Description** field, enter a description for the profile. 1. Select **Next**. 1. On the **Configuration settings** tab, complete the following: - In the **Preference domain name** field, enter **com.google.chrome**. - In the **Property list file** field, upload the following plist file: ```py ExtensionInstallForcelist ckdibgmbbhmafmjpjmknleccgcddanan; https://extension.savvy.security/update.x ml update_url https://extension.savvy.security/update.xml ``` 1. Select **Next**. 1. On the **Assignments** tab, assign any desired target users and groups and select **Next**. 1. On the **Review + create** tab, select **Create**. 1. Wait for new policy to propagate, or perform a manual synchronization. 1. Once propagated, verify that Chrome is now managed on endpoints: - Re-open Chrome on a managed target endpoint. - Select the three dots icon on the top right. The bottom entry should read “Managed by” followed by your organization name. - Open a new tab and browse to `chrome://policy`. - Verify under **Chrome Policies** you can see the **ExtensionInstallForcelistDesc** policy name with the following value: `ckdibgmbbhmafmjpjmknleccgcddanan;https://extension.savvy.security/update.xml`. # Deploying Using Microsoft Intune for Chrome on Windows 1. Go to `https://intune.microsoft.com/`. 1. Go to **Endpoint Manager > Devices > Configuration policies**. 1. Select **Create > New Policy**. 1. On the **Create a profile** page, complete the following: - In the **Platform** dropdown, select **Windows 10 and later**. - In the **Profile Type** dropdown, select **Templates**. - In the **Template name** dropdown, select **Administrative templates**. 1. Select **Create**. 1. On the **Basics** tab, complete the following: - In the **Name** field, enter a name to identify the profile. - In the **Description** field, enter a description for the profile. 1. Select **Next**. 1. On the **Configuration settings** tab, select **Configure the list of force-installed apps and extensions configuration**. Verify the path is `\Google\Google Chrome\Extensions`. 1. In the right hand panel, complete the following: - Under **Supported on: Microsoft Windows 7 or later** select **Enabled**. - In the **Extension/App IDs and update URLs to be silently installed** field enter `ckdibgmbbhmafmjpjmknleccgcddanan;https://extension.savvy.security/update.xml`. 1. Select **OK**. 1. Select **Next**. 1. On the **Scopes tags** tab, add any desired scope tags and select **Next**. 1. On the **Assignments** tab, assign any desired target users and groups and select **Next**. 1. On the **Review + create** tab, select **Create**. 1. Wait for new policy to propagate, or perform a manual synchronization. 1. Once propagated, verify that Chrome is now managed on endpoints: - Re-open Chrome on a managed target endpoint. - Select the three dots icon on the top right. The bottom entry should read “Managed by” followed by your organization name. - Open a new tab and browse to `chrome://policy`. - Verify under **Chrome Policies** you can see the **ExtensionInstallForcelistDesc** policy name with the following value: `ckdibgmbbhmafmjpjmknleccgcddanan;https://extension.savvy.security/update.xml`. # Deploying Using Microsoft Intune for Edge on Windows 1. Go to `https://intune.microsoft.com/`. 1. Go to **Endpoint Manager > Devices > Configuration Profiles**. 1. Select **+ Create Profile**. 1. On the **Create a profile** page, complete the following: - In the **Platform** dropdown, select **Windows 10 and later**. - In the **Profile Type** dropdown, select **Settings catalog**. 1. Select **Create**. 1. On the **Basics** tab, complete the following: - In the **Name** field, enter a name to identify the profile. - In the **Description** field, enter a description for the profile. 1. Select **Next**. 1. On the **Configuration settings** tab, complete the following: - Select **+ Add Settings**. - In the **Settings picker** pane, complete the following: - In the **Category** field, select **Microsoft Edge\\Extensions**. - In the **Setting name** field, select **Control which extensions are installed silently**. - Select **Close**. - In the **Control which extensions are installed silently** field select **Enabled**. - In the **Extension/App IDs and update URLs to be silently installed (Device)** field enter `ckdibgmbbhmafmjpjmknleccgcddanan;https://extension.savvy.security/update.xml`. 1. Select **Next**. 1. On the **Scopes tags** tab, add any desired scope tags and select **Next**. 1. On the **Assignments** tab, assign any desired target users and groups and select **Next**. 1. On the **Review + create** tab, select **Create**. 1. Wait for new policy to propagate, or perform a manual synchronization. 1. Once propagated, verify that Edge is now managed on endpoints: - Re-open Edge on a managed target endpoint. - Browse to `edge://policy`. - Verify under **Policies** you can see the **ExtensionInstallForcelistDesc** policy name with the following value: `ckdibgmbbhmafmjpjmknleccgcddanan;https://extension.savvy.security/update.xml`. - Browse to `edge://extensions`. - On the top of the screen, verify that the message “Your browser is managed by your organization” is shown. - In the **Installed extensions**, verify that **Savvy** is listed. # Deploying Using Jamf Pro for Chrome on Mac OS 1. In Jamf Pro, select **Computers**. 1. On the left panel, select **Configuration Profiles**. 1. Select **+ New**. 1. On the new profile, complete the following: - In the **Name** field, enter a name to identify the profile. - In the **Category** dropdown, select a category. - In the **Level** field, select **Computer Level**. 1. On the left panel, select **Custom Settings**. 1. In the **Preference Domain** field, enter **com.google.chrome**. 1. In the **Property list file** field, upload the following plist file: ```py ExtensionInstallForcelist ckdibgmbbhmafmjpjmknleccgcddanan;https://extension.savvy.security/update.xml ExtensionSettings ckdibgmbbhmafmjpjmknleccgcddanan installation_mode force_installed force_pinned update_url https://extension.savvy.security/update.xml ``` 1. Select **Save**. # Deploying Using Jamf Pro for Edge on Mac OS 1. In Jamf Pro, select **Computers**. 1. On the left panel, select **Configuration Profiles**. 1. Select **+ New**. 1. On the new profile, complete the following: - In the **Name** field, enter a name to identify the profile. - In the **Category** dropdown, select a category. - In the **Level** field, select **Computer Level**. 1. On the left panel, select **Custom Settings**. 1. In the **Preference Domain** field, enter **com.microsoft.Edge**. Note Ensure 'Edge' is entered with an uppercase 'E'. 1. In the **Property list file** field, upload the following plist file: ```py ExtensionInstallForcelist ckdibgmbbhmafmjpjmknleccgcddanan;https://extension.savvy.security/update.xml ExtensionSettings ckdibgmbbhmafmjpjmknleccgcddanan installation_mode force_installed force_pinned update_url https://extension.savvy.security/update.xml ``` 1. Select **Save**. # Deploying Using Jumpcloud for Chrome on Mac OS and Windows 1. Log into the Jumpcloud admin portal at `https://console.jumpcloud.com/login/admin`. 1. On the left panel, select **Policy Management**. 1. Select the **+** button. 1. Select **Chrome Browser Force-Installed** policy, and select **configure**. 1. In the **Additional Chrome Browser Extensions** tile, complete the following: - Select **add extension ID**. - In the empty field, enter `eocjfoecmhaiedpjghfoponibjkehifb`. 1. Select **Save**. # Deploying Using Microsoft SCCM for Chrome on Windows 1. Open the SCCM console on your administrative workstation. 1. Go to **Assets and Compliance > Compliance Settings > Configuration Items**. 1. Select **Create Configuration Item**. 1. In the **Name** field, enter a name to identify the configuration item. 1. Select **Next**. 1. Select the desired platforms for which this configuration will apply. 1. Select **Next**. 1. Select **New** to create a new setting. 1. In the **New Settings** window, complete the following: - In the **Name** field, enter **ExtensionInstallForcelist**. - In the **Description** field, enter **Application Visibility Browser Extension**. - In the **Key Name** field, enter `Software\Policies\Google\Chrome\ExtensionInstallForcelist`. - In the **Value Name** field, enter **1**. Note This number must be unique. If you have added other extensions, this number should be incremented accordingly. 1. Select **OK**. 1. Select the **Compliance Rules** tab, and select **New**. 1. In the **Create** window, complete the following: - In the **Name** field, enter **Application Visibility Security Extension Compliance Rule**. - In the **Description** field, enter **Application Visibility Browser Extension**. - In the **the following values:** field, enter the value `ckdibgmbbhmafmjpjmknleccgcddanan;https://extension.savvy.security/update.xml`. - Select **Remediate noncompliant rules when supported**. - Select **Report noncompliance if this setting instance is not found**. 1. Select **OK** to close the window. 1. Select **OK** to create the new compliance rule. 1. Select **Assets and Compliance > Compliance Settings > Configuration Baselines**. 1. Select **Create Configuration Baseline**. 1. In the **Name** field, enter a name to identify the configuration baseline. 1. Select **Add > Configuration Item**. 1. Select the **Application Visibility Browser Extension Configuration Item**, and select **OK**. 1. Select **OK** to complete the new configuration baseline. 1. Deploy the configuration baseline containing the **Application Visibility Browser Extension Configuration Item** and complete the following: - Select **Remediate noncompliant rules when supported**. - In the **Schedule** section, set the schedule to the desired value. Note Group policies update, by default, every 90 minutes. If this is replacing a GPO, consider lowering the policies update interval. 1. Select **OK**. 1. Once SCCM has updated its policies, verify that Chrome is now managed on endpoints: - Open a Chrome and browse to `chrome://policy`. - Verify under **Chrome Policies** you can see the **ExtensionInstallForcelistDesc** policy name with the following value: `ckdibgmbbhmafmjpjmknleccgcddanan;https://extension.savvy.security/update.xml`. # Deploying Using Microsoft SCCM for Edge on Windows 1. Open the SCCM console on your administrative workstation. 1. Go to **Assets and Compliance > Compliance Settings > Configuration Items**. 1. Select **Create Configuration Item**. 1. In the **Name** field, enter a name to identify the configuration item. 1. Select **Next**. 1. Select the desired platforms for which this configuration will apply. 1. Select **Next**. 1. Select **New** to create a new setting. 1. In the **New Settings** window, complete the following: - In the **Name** field, enter **ExtensionInstallForcelist**. - In the **Description** field, enter **Application Visibility Browser Extension**. - In the **Key Name** field, enter `SOFTWARE\Policies\Microsoft\Edge\ExtensionInstallForcelist`. - In the **Value Name** field, enter **1**. Note This number must be unique. If you have added other extensions, this number should be incremented accordingly. 1. Select **OK**. 1. Select the **Compliance Rules** tab, and select **New**. 1. In the **Create** window, complete the following: - In the **Name** field, enter **Application Visibility Security Extension Compliance Rule**. - In the **Description** field, enter **Application Visibility Browser Extension**. - In the **the following values:** field, enter the value `ckdibgmbbhmafmjpjmknleccgcddanan;https://extension.savvy.security/update.xml`. - Select **Remediate noncompliant rules when supported**. - Select **Report noncompliance if this setting instance is not found**. 1. Select **OK** to close the window. 1. Select **OK** to create the new compliance rule. 1. Select **Assets and Compliance > Compliance Settings > Configuration Baselines**. 1. Select **Create Configuration Baseline**. 1. In the **Name** field, enter a name to identify the configuration baseline. 1. Select **Add > Configuration Item**. 1. Select the **Application Visibility Browser Extension Configuration Item**, and select **OK**. 1. Select **OK** to complete the new configuration baseline. 1. Deploy the configuration baseline containing the **Application Visibility Browser Extension Configuration Item** and complete the following: - Select **Remediate noncompliant rules when supported**. - In the **Schedule** section, set the schedule to the desired value. Note Group policies update, by default, every 90 minutes. If this is replacing a GPO, consider lowering the policies update interval. 1. Select **OK**. 1. Once SCCM has updated its policies, verify that Edge is now managed on endpoints: - Open Microsoft Edge and browse to `edge://policy`. - Verify under **Microsoft Edge Policies** you can see the **ExtensionInstallForcelistDesc** policy name with the following value: `ckdibgmbbhmafmjpjmknleccgcddanan;https://extension.savvy.security/update.xml`. - Open a new tab and go to `edge://extensions`. - Verify that the extension is installed and enabled. # Deploying Using Workspace ONE UEM for Chrome on Mac OS 1. Log into the VMware Workspace ONE UEM management console. 1. Go to **Resources > Profiles & Baselines > Profiles > Add > Add Profile**. 1. Select **Apple macOS > macOS**. 1. Configure the profile’s General Settings. 1. Select **Custom Settings > Configure**. 1. Paste the following payload: ```py PayloadIdentifier org.extension.profiles.com.google.Chrome PayloadRemovalDisallowed PayloadScope User PayloadType Configuration PayloadUUID 63a4d234-ff4e-46f0-bb59-68801ed918bb PayloadOrganization Savvy PayloadVersion 1 PayloadDisplayName Chrome Savvy Extension PayloadContent PayloadType com.apple.ManagedClient.preferences PayloadVersion 2 PayloadIdentifier org.extension.profiles.com.google.Chrome.customsettings PayloadUUID eb004daf-4eae-4a69-be51-a77c6a0442ae PayloadEnabled PayloadDisplayName Google Chrome Preferences PayloadContent com.google.Chrome Forced mcx_preference_settings ExtensionInstallForcelist ckdibgmbbhmafmjpjmknleccgcddanan;https://extension.savvy.security/update.xml ``` 1. Select **Save and Publish**. # Integrating with Identity Providers Application Visibility can integrate with external Identity Providers (IdPs) in order to provide visibility into SaaS usage and risk in your organization. Once integrated and also depending on your chosen IdP, Application Visibility might be able to: - Allow the [browser extension](https://documentation.sailpoint.com/saam/help/browser_extension/index.html) and Application Visibility administrators to authenticate against the IdP. - Read the list of SaaS applications that have been installed in your organization, and parse SSO logs to continuously detect SSO’ed accounts. - Support listing user accounts, user groups, application, and related user activity in the admin portal. - Review the IdP configuration, such as MFA settings and last password rotation dates. Available IdP integrations include: - [Microsoft Entra ID](https://documentation.sailpoint.com/saam/help/idp/entra_idp.html) – Use for integration with Microsoft Entra ID IdP. - [Okta](https://documentation.sailpoint.com/saam/help/idp/okta_idp.html) – Use for integration with Okta IdP. - [Other IdP](https://documentation.sailpoint.com/saam/help/idp/other_idp.html) – Use for integration with IdP’s other than Microsoft Entra ID or Okta. # Integrating with Microsoft Entra ID The Application Visibility platform is deployed in Microsoft Entra ID as a multi-tenant application. Application Visibility uses Microsoft Entra ID API to authenticate end users and administrators logging into the Application Visibility platform and to gather information on applications integrated with Microsoft Entra ID and their permissions. Once integrated with Microsoft Entra ID, Application Visibility can: - Allow the [browser extension](https://documentation.sailpoint.com/saam/help/browser_extension/index.html) and Application Visibility administrators to authenticate against the IdP. - Read the list of SaaS applications that have been installed in your organization, and parse SSO logs to continuously detect SSO’ed accounts. - Support listing user accounts, user groups, application, and related user activity in the admin portal. - Review the IdP configuration, such as MFA settings and last password rotation dates. You will first create an application integration in Microsoft Entra ID to configure authentication, and then create a Privileged Role Administrator. To establish trust with Microsoft Entra ID, an [Azure Active Directory Administrator with the Privileged role administrator](#creating-a-privileged-role-administrator-in-azure-active-directory) role is required. **To configure authentication:** 1. [Log into the Application Visibility admin console](https://documentation.sailpoint.com/saam/help/index.html#accessing-application-visibility). 1. Go to **Settings > General Settings**. 1. Select the **Identity Provider** tab. 1. Select **+Add**. 1. Select **Azure AD**. 1. Select **Connect**. 1. If your are an Azure Active Directory Administrator with an admin privileged role, select **Open link**. - Select the checkbox to accept the permissions requested by Application Visibility. For a full list of requested permissions, refer to [Requested Permissions](#requested-permissions). - A confirmation page is displayed confirming trust has been successfully established. Note Cloud Application Administrator or Application Administrator roles are insufficient due to Graph API permission requirements. 1. If you are not an Azure Active Directory Administrator with an admin privileged role, select **Copy link**. - Ask your Microsoft Entra ID administrator with an admin privileged role, to click on the copied link and establish trust. - Once trust is established, select **Connect**. 1. A green dot is displayed confirming that connection was established. 1. You will be automatically redirected back to the Application Visibility admin portal after accepting the permissions. 1. Go to **Settings > Admin Management**. 1. Select **Add Admin**. 1. Select the desired Application Visibility admin portal admins from your Entra ID. 1. Select your avatar at the top right, and select **Logout**. 1. Log in with an Entra ID user that was previously configured as Application Visibility admin to confirm successful trust establishment. Application Visibility admins can now access the Application Visibility portal. For more information refer to [Accessing Application Visibility](https://documentation.sailpoint.com/saam/help/index.html#accessing-application-visibility). ## Requested Permissions The following table shows the permissions and access type required by Application Visibility applications from Microsoft Entra ID. | **Microsoft Permission Name** | **Access Type** | **Description** | | -------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------- | | `Directory.Read.All` | Application | Read directory data | | `User.Read.All` | Application | Read all users' full profiles | | `Application.Read.All` | Application | Read all applications | | `AuditLog.Read.All` | Application | Read all audit logs | | `Policy.Read.All` | Application | Read all organizational policies (e.g., Conditional Access, authentication, token policies) | | `UserAuthenticationMethod.Read.All` | Application | Read all users' registered authentication methods (e.g., phone, FIDO2, Authenticator app) | | `email` `openid` `profile` `User.Read` | Delegated | SSO sign-in with Microsoft identity platform. Log in (OpenID Connect 2.0) and read user's profile | ## Creating a Privileged Role Administrator in Azure Active Directory 1. Log in to Azure Portal at . 1. Under Azure Services, select **Azure Active Directory**. 1. Select **Users** and select the user that will be used for the Application Visibility authorization. 1. From the left panel, select **Assigned roles**. 1. Select **Add assignment** and select the checkbox besides **Privileged role administrator**. The role is now assigned to the user. To verify, check that the Resource Name is set to Directory and the Assignment Path is set to Direct. # Integrating with Okta Application Visibility uses Okta API to authenticate end users and administrators logging into the Application Visibility platform and to gather information on applications integrated with Okta and their permissions. Once integrated with Microsoft Entra ID, Application Visibility can: - Allow the [browser extension](https://documentation.sailpoint.com/saam/help/browser_extension/index.html) and Application Visibility administrators to authenticate against the IdP. - Read the list of SaaS applications that have been installed in your organization, and parse SSO logs to continuously detect SSO’ed accounts. - Support listing user accounts, user groups, application, and related user activity in the admin portal. - Review the IdP configuration, such as MFA settings and last password rotation dates. You will first create an app integration in Okta to configure authentication, and then configure a service application. **To configure authentication:** 1. Log into Okta at . 1. Go to **Applications > Applications**. 1. Select **Create app integration.** 1. On the **Create app integration** page complete the following: - In the **Sign-in method** section, select **OIDC OpenID Connect**. - In the **Application type** section, select **Web Application**. 1. Select **Next**. 1. On the **New Web Application Integration** page, complete the following: - In the **App integration name** field, enter **Application Visibility authentication**. - In the **Grant type** field, select **Authorization Code** and **Implicit (hybrid)**. - In the **Sign-in redirect URIs** field, enter ****. - In the **Sign-out redirect URIs** field, remove the default URI. - In the **Assignments** section, select whether to assign the app integration to everyone in your org, only selected group(s), or to skip assignment until after app creation. 1. Select **Save** to save these settings. 1. Select the **Okta API Scopes** tab. 1. Grant the `okta.users.read.self` scope. 1. Select the **General** tab. 1. Copy the following details from the Okta General tab, into the Application Visibility admin console **Settings > General Settings > Identity Provider**: - **Okta domain** - **Client ID** - **Client Secret** **To configure the service application:** 1. Log into Okta at  . 1. Go to **Security > Administrators**. 1. Select the **Roles** tab. 1. Select **Create** to create a new role. 1. On the **Create new role** page complete the following: - In the **Role name** field, enter **SAAM-Role**. - In the **Description** filed, provide additional details about the role and the access it grants. - In the **Select permissions** section, search for "view roles", and add the **View roles, resources and admin assignments** permission. 1. Select **Save** to save the role settings. 1. Select the **Resources** tab. 1. Select **Create new resource set**. 1. On the **Create new resource set** page complete the following: - In the **Resource name** field, enter **SAAM-Resource**. - In the **Description** filed, provide additional details about the resource. 1. Select **Add Resource**. 1. On the **Add Resource** page, select **Identity and Access Management** and then select **All Identity and Access Management resources**. 1. Select **Save** to save these settings. 1. Go to **Applications > Applications**. 1. Select **Create app integration.** 1. On the **Create app integration** page complete the following: - In the **Sign-in method** section, select **API Services**. 1. Select **Next**. 1. On the **New API Services App Integration** page complete the following: - In the **App integration name** field, enter **Application Visibility services app**. 1. Select the **Admin roles** tab. - On the **Complete the assignment** page complete the following: - In the **Role** field, select **SAAM-Role**. - In the **Resources set** field, select **SAAM-Resource**. - In the **Role** field, select the **Read-only Administrator** role. 1. Select **Add assignment**. 1. Select the **Okta API Scopes** tab. 1. Grant the following scopes: - `okta.users.read` - Read users for policy matching. - `okta.groups.read` - Read groups for policy matching. - `okta.apps.read` - Read oauth/saml applications to create inventory items. - `okta.logs.read` - Read sign in events. - `okta.policies.read` - Read policies in order to understand MFA status per application. - `okta.domains.read` - Fetching any verified domain. - `okta.roles.read` - Determine role per user, primarily to evaluate if a user is an administrator. - `okta.appGrants.read` - Read all app grants. 1. Select the **General** tab. 1. Select **Edit** to edit the client credentials. 1. In the **Client Credentials** section, for Client authentication select **Public key / Private key**. 1. In the **PUBLIC KEYS** section complete the following: - In the Configuration field, select **Use a URL to fetch keys dynamically**. - In the **URL** field, enter the URL from the Application Visibility admin console **Settings > General Settings > Identity Provider**. - Deselect the **Proof of possession** radio button. 1. Select Save to save the settings. 1. Select the **General** tab. 1. Copy the following details from the Okta General tab, into the Application Visibility admin console **Settings > General Settings > Identity Provider**: - **Client ID** - **Okta domain** Application Visibility admins can now access the Application Visibility portal. For more information refer to [Accessing Application Visibility](https://documentation.sailpoint.com/saam/help/index.html#accessing-application-visibility). # Integrating with Other IdPs Application Visibility can be integrated with IdPs other than Microsoft Entra ID and Okta, to authenticate end users and administrators logging into the Application Visibility platform, and to gather information on applications. Once integrated with your IdP, Application Visibility can: - Allow the [browser extension](https://documentation.sailpoint.com/saam/help/browser_extension/index.html) and Application Visibility administrators to authenticate against the IdP. - Support listing user accounts, applications, and related user activity in the admin portal. Notes - When integrating with an IdP other than Microsoft Entra ID or Okta, the browser extension cannot retrieve the list of onboarded applications, therefore Application Visibility cannot parse the SSO logs. Most applications and accounts will still be detected by the browser extension, unless they are: - Completely inactive, or; - Used exclusively outside of managed browsers. - Because real-time correlation with IdP SSO events is not available, the browser extension is unable to determine the login method for these IdPs. As a result, it is not possible to automatically detect local access to applications that are SSO-enabled. Advanced administrators can still investigate potential local access by: - Reviewing [activity logs](https://documentation.sailpoint.com/saam/help/data_analytics.html) for suspected applications. - Focusing on “Credentials submitted” [events](https://documentation.sailpoint.com/saam/help/data_analytics.html). - Examining the destination URLs to which credentials are submitted, which may indicate local authentication paths. You will first configure an OIDC application in your IdP to allow browser extension authentication, and then deploy your tenant ID to the browser extension on your endpoints using your MDM solution. ## Configuring an OIDC application in your IdP and Application Visibility Create an application in your IdP to support OIDC-based authentication for browser extensions, and integrate with Application Visibility. This allows the extension to sign in transparently without additional user interaction. 1. Log into your IdP. - Create a new dedicated OIDC application for Application Visibility. Enter the redirect URI as . 1. Copy the information from the Client ID, Client Secret, and Issuer ID fields. You’ll need this information when you configure the IdP in Application Visibility. 1. In Application Visibility, go to **Settings > General Settings > Identity Provider**. 1. Select **Add**. 1. Select **OpenID**. 1. On the **Identity Provider** page, complete the following: - **Client ID** – The Client ID from your IdP. - **Client Secret** - The Client Secret from your IdP. - **Issuer URI** - The Issuer URI from your IdP. ## Deploying a PowerShell Script using MDM These generic instructions describe how to deploy a PowerShell script using a Mobile Device Management (MDM) solution. The MDM pushes the PowerShell script to managed Window’s endpoints and executes it remotely with administrative privileges. This is the recommended method. ### Creating a PowerShell script 1. Create a .ps1 file containing the registry configuration. An example script provided below. Replace `` with the actual tenant value provided to you during onboarding. Example Powershell Script ```json $tenantId = "" $paths = @( "HKLM:\Software\Policies\Google\Chrome\3rdparty\extensions\ckdibgmbbhmafmjpjmknleccgcddanan\policy", "HKLM:\Software\Policies\Microsoft\Edge\3rdparty\extensions\ckdibgmbbhmafmjpjmknleccgcddanan\policy" ) foreach ($p in $paths) { if (!(Test-Path $p)) { New-Item -Path $p -Force | Out-Null } New-ItemProperty -Path $p -Name "TenantID" -Value $tenantId -PropertyType String -Force | Out-Null } ``` 1. Save the .ps1 file as **set-tenant.ps1**. ### Uploading Script to your MDM In your MDM admin console: 1. Go to **Device Management** or **Scripts**. 1. Select **Add Script**, **Run Script**, or **PowerShell Script**. 1. Upload the .ps1 file. 1. Select the target device group, for example *All Windows devices*. ### Configure Execution Settings In your MDM admin console, configure the following settings: | Setting Type | Setting | | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Run as | SYSTEM/Administrator | | Execution Frequency | - Run once (recommended) - Run at every check-in (if you want enforcement) | | PowerShell mode (If supported by your MDM) | - Run in 64-bit PowerShell - Execution policy bypass - Run silently | | Assigning | - Device group, or - All managed Windows devices **Note:** Most MDMs will execute scripts at next endpoint check-in, or immediately if the device is online. | ### Verifying Deployment on Endpoint After deployment, you can verify that the script was successfully applied on a Windows endpoint. **To verify deployment using registry check:** 1. On the endpoint, open **regedit**. 1. Locate the following registry path for your browser: - **Google Chrome** - `HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome\3rdparty\extensions\` - **Microsoft Edge** - `HKEY_LOCAL_MACHINE\Software\Policies\Edge\Chrome\3rdparty\extensions\` 1. Verify the TenantID key value matches your tenant ID. **To verify deployment using PowerShell:** 1. On the endpoint, open **PowerShell**. 1. Run the following command: `Get-ItemProperty "HKLM:\Software\Policies\Google\Chrome\3rdparty\extensions\ckdibgmbbhmafmjpjmknleccgcddanan\policy"` 1. Verify the TenantID key value matches your tenant ID. ### Troubleshooting Script Deployment Issues | Issue | Action | | ----------------------------------- | ---------------------------------------------------------------------------------------- | | Script did not apply | Check: - Device is enrolled in MDM - Device is online - Script assigned to correct group | | Access denied error | Ensure script runs as SYSTEM/Administrator | | Registry key exists but not applied | Restart browser to read new policy | # Viewing the Application Inventory The Application Visibility Inventory provides a near realtime view of all discovered applications, user accounts, accounts and browser plugins in your environment. ## SaaS Inventory The [SaaS Inventory](https://documentation.sailpoint.com/saam/help/inventory/saas.html) provides a continuously updated view of all applications and user accounts discovered by Application Visibility across your organization. Information is aggregated from multiple discovery sources, including the Application Visibility [browser extension](https://documentation.sailpoint.com/saam/help/browser_extension/index.html), and the [IdP connector](https://documentation.sailpoint.com/saam/help/idp/index.html), to present a unified, cross-platform inventory of application usage across your organization. This combined visibility helps admins identify sanctioned and unsanctioned (shadow IT) applications, track authentication patterns, and monitor identity risk across all SaaS environments. The SaaS Inventory also covers private or on-premises applications. Such applications are represented by their apex domain. You can configure one or more [Custom Applications](https://documentation.sailpoint.com/saam/help/custom_apps.html) to replace or split the domain-based representation if multiple applications share the same root domain. ## Users Inventory The [Users Inventory](https://documentation.sailpoint.com/saam/help/inventory/users.html) represents all the employee records that were discovered by the [IdP connector](https://documentation.sailpoint.com/saam/help/idp/index.html), and includes details of the status of the user and when the user was last active. Select a user to view a list all discovered user accounts associated with this user. This view can be searched by username. ## Accounts Inventory The [Accounts Inventory](https://documentation.sailpoint.com/saam/help/inventory/accounts.html) represents all user accounts discovered by the [browser extension](https://documentation.sailpoint.com/saam/help/browser_extension/index.html) and the [IdP connector](https://documentation.sailpoint.com/saam/help/idp/index.html) providing a granular view of each account, its associated application, login method, MFA status, and identity risk indicators. This view can be searched using [basic](https://documentation.sailpoint.com/saam/help/inventory/accounts.html#building-a-basic-account-search-query) and [advanced search queries](https://documentation.sailpoint.com/saam/help/inventory/accounts.html#building-advanced-account-search-queries). # Viewing the Accounts Inventory Select **Inventory > Accounts** from the left panel to view of all user accounts discovered across your organization. Use quick filters to refine accounts listed in the table by login method, identity risks, risk levels, and newly discovered. Additional filtering can be applied by selecting **More filters**. By default, accounts discovered for non-corporate assets, such as applications that users log in to with their consumer credentials are hidden from the Accounts Inventory. Some legitimate corporate assets may be accessed using unknown credentials (usernames without a domain suffix) or consumer / social login. To display discovered accounts for all applications, select the Suitcase icon . Select the Grid / Visualization  toggle to switch between view types: - **Grid View** - The default tabular view displaying detailed application and account metrics. - **Visualization Mode** - Keeps the same underlying query but allows you to create [visualization charts](https://documentation.sailpoint.com/saam/help/data_analytics.html#creating-visualizations) and visual summaries based on SaaS attributes, usage, or risk indicators. Select the Export data as CSV icon to export the grid view as a CSV file for further analysis and reporting. Selecting an account opens the detail panel with detailed contextual information: - **Account risk level** - Provides quick visibility into the accounts overall risk posture. - **Graph**– Provides visibility into how authentication is performed and risks associated with that access. ## Account Graphical View When selecting an account record the details page displays a graph highlighting the authentication relationship between a user and an application account, providing visibility into how authentication is performed and what risks are associated with that access. The graph helps security and identity teams: - Understand how access to an application is granted. - Identify SSO bypass scenarios. - Detect high-risk authentication patterns. - Assess password-related identity risks and blast radius. - Navigate between related user and application records for investigation. The graph visualizes: - The authentication methods used by the user to access the account, including: - SSO-based access. - Local (direct) authentication. - Both methods simultaneously. - Identity-related risks associated with the account, including: - Weak passwords. - Compromised passwords. - Reused passwords. Notes - It is common for an application to be onboarded to SSO while still allowing direct local access. This scenario is identified as an SSO Bypass, representing a potential access risk. - When password reuse is detected, the graph expands to show all additional applications and websites where the same password was used by the same user, providing visibility into lateral exposure risk. ## Building a Basic Account Search Query Basic search queries can be created by searching for an account name or part name and selecting the filter dropdowns to refine your search criteria. **To build a basic search query:** 1. Go to **Inventory > Accounts** from the left panel. 1. (Optional) Enter an account name or part name in the search and select **Enter**. 1. Select the filter dropdowns to refine your search. - **Login methods** - select the desired sources. - **Identity risks** - select the desired risk types. - **Risk Levels** - select the desired risk level. - **Newly discovered** - select the desired time frame during which the application was discovered. 1. Select More Filters to further filter based upon users, account status and MFA status. The search results are displayed based upon your selected search query. To save your query, select the Database icon  next to the search box, and select **Save as new query**. ## Building Advanced Account Search Queries Custom search queries can be created using the search box. Search queries for specific use cases can be built using predefined search query syntax's and combined with AND, OR, NOT, AND NOT, and TO operators. **To build an advanced search query:** 1. Go to **Inventory > Accounts** from the left panel. 1. Enter the required [syntax](https://documentation.sailpoint.com/saam/help/data_analytics.html#search-query-syntax) into the search box. Select the Database icon  next to the search box, and select **Save as new query**. # Viewing the SaaS Inventory Select **Inventory > SaaS** from the left panel to view all applications and user accounts discovered across your organization. You can toggle between two primary modes using the **Live** toggle: - **Default View** - Displays consolidated inventory data refreshed automatically within approximately 24 hours. This view is optimized for reporting, performing [advanced search queries](#building-advanced-application-search-queries), and visualizations such as charts, filters, and saved queries. - **Live View** - Displays real-time SaaS discovery data as discovered by active browser extensions/IdP API. This view can be searched by [application name](#building-a-basic-application-search-query). Use this mode if you wish to see immediate updates, for example if you onboard a new application and want to make sure it is reflected in the SaaS Inventory, or when testing configuration changes such as defining custom applications. Use quick filters to refine applications listed in the table by source, identity risks, and newly discovered. Additional filtering can be applied by selecting **More filters**. By default, non-corporate assets, such as applications that users log in to with their consumer credentials are hidden from the SaaS Inventory. Some legitimate corporate assets may be accessed using unknown credentials (usernames without a domain suffix) or consumer / social login. To display all applications select the Suitcase icon . The source column displays details of where the account data was discovered: - **Browser Extension** - The active sign-in activity was discovered from user browsers. - **IdP Connector** - SSO activity was observed for at least one account, or that the application was discovered using the IdP's installed applications API. Select the **Grid / Visualization** toggle to switch between view types: - **Grid View** - The default tabular view displaying detailed application and account metrics. - **Visualization Mode** - Keeps the same underlying query but allows you to create [visualization charts](https://documentation.sailpoint.com/saam/help/data_analytics.html#creating-visualizations) and visual summaries based on SaaS attributes, usage, or risk indicators. Select the Export data as CSV icon to export the grid view as a CSV file for further analysis and reporting. Selecting an application opens the detail panel with detailed contextual information: - **App description** - A short overview of the application and its purpose. - **Show more** - Expands additional labels and metadata associated with the application including tags or compliance labels. - **Sensitivity** - Indicates the applications sensitivity level. By default, this is derived from out-of-the-box mappings based on the applications category. Admins can override the sensitivity value manually if needed. This affects the overall risk score. - **Risk level**, **Authorization**, and **App owner** - Provides quick visibility into the applications ownership and overall risk posture. ## Building a Basic Application Search Query Basic search queries can be created by searching for an application name and selecting the filter dropdowns to refine your search criteria. **To build a basic search query:** 1. Go to **Inventory > SaaS** from the left panel. 1. (Optional) Enter an application name in the search and select **Enter**. 1. Select the filter dropdowns to refine your search. - **Sources** - select the desired sources. - **Identity risks** - select the desired risk types. - **Newly discovered** - select the desired time frame during which the application was discovered. 1. Select **More Filters** to further filter based upon authorizations and login methods. The search results are displayed based upon your selected search query. To save your query, select the Database icon  next to the search box, and select **Save as new query**. ## Building Advanced Application Search Queries Custom search queries can be created using the search box. Search queries for specific use cases can be built using [predefined search query syntax's](https://documentation.sailpoint.com/saam/help/data_analytics.html#search-query-syntax) and combined with AND, OR, NOT, AND NOT, and TO operators. **To build an advanced search query:** 1. Go to **Inventory > SaaS** from the left panel. 1. Enter the required [syntax](https://documentation.sailpoint.com/saam/help/data_analytics.html#search-query-syntax) into the search box. 1. Select the Database icon  next to the search box, and select **Save as new query**. ## Sorting and Risk Calculation By default, the SaaS Inventory is sorted by overall identity-breach risk for each application. The risk score is calculated by combining two weighted factors: 1. **Exposure** - Measures how easy it would be for a threat actor to gain access to an account in the application. Factors that increase exposure include a high number of compromised accounts, weak passwords, and lack of MFA enforcement. 1. **Sensitivity** - Reflects the potential **impact** of a breach. The score is determined by the applications sensitivity classification, which defaults to OOTB mappings based on application labels. Admins can override the classification sensitivity manually in the applications side panel. The calculated Risk Level (Low, Medium, High, or Very High) determines the applications position in the inventory and how it appears in risk-based visualizations. # Viewing the User Inventory Select **Inventory > Users** from the left panel to view of all users discovered across your organization. Selecting a user record opens the detail panel with detailed contextual information, including user accounts correlated to the user. Selecting a user account record displays the [graphical view](https://documentation.sailpoint.com/saam/help/inventory/accounts.html#account-graphical-view), highlighting the authentication relationship between a user and an application account. ## SaaS View The SaaS view displays a list of all application accounts an active user has logged into. By default, non-corporate applications that users log in to with their consumer credentials are hidden from the User Inventory. To display all applications, select the Suitcase icon . When a user leaves the organization and their IdP account is deactivated, Application Visibility automatically detects the offboarded state. When viewing a deactivated user, the SaaS View displays access status as follows: - Applications accessed exclusively through SSO display greyed out, indicating that access has already been revoked as a result of SSO deactivation. - Applications accessed through local (non-SSO) credentials are marked with a warning indicator, highlighting that access may still be active and require manual offboarding. ## Offboarding View The Offboarding view provides details on the status of application accounts for the offboarded user. ### Required tab The Required tab lists application accounts that must be manually offboarded. Manually offboarded accounts cover: - Access was granted through direct (local) authentication, and is not automatically revoked when SSO is disabled. - The application is identified as a corporate asset, either: - Explicitly marked as sanctioned or labeled in the [application inventory](https://documentation.sailpoint.com/saam/help/inventory/saas.html), or; - Identified automatically using Application Visibility Discovery’s out-of-the-box application intelligence. Important If the application is not governed by an Identity Governance and Administration process, these accounts will require manual offboarding and should be verified to ensure access is disabled. ### Review tab The Review tab lists application accounts accessed using corporate credentials, but where it is unclear whether the application is a corporate asset. Examples include: - Conference or event platforms. - Travel or booking sites. - Other third-party services not necessarily work-related. These applications require a decision: - If offboarding is required, the application can be moved to Required. - Once moved, the application is treated as required globally and will appear under the Required tab for all future offboarded users. ### Excluded tab The Excluded tab lists applications where access was granted only through SSO. Access to these applications is automatically revoked when SSO is disabled, so no additional offboarding action is required. ## Building a Basic User Search Query Basic search queries can be created by searching for a username or part a username and selecting the filter dropdowns to refine your search criteria. **To build a basic search query:** 1. Go to **Inventory > Users** from the left panel. 1. (Optional) Enter a username or part of a username in the search. 1. Select the **Status** filter dropdown to refine your search. # Configuring System Settings Application Visibility includes global settings and reference information that impact your Application Visibility security and privacy. ## Configuring Security Settings - Configure API-level access through [personal access tokens](https://documentation.sailpoint.com/saam/help/settings/security_settings.html#managing-api-tokens). ## Configuring Privacy Controls - Allow [password hashes to be sent to Application Visibility](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#sending-password-hashes-to-the-cloud) cloud to detect reused passwords and compromised accounts. - Allow [hashed passwords to be stored](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#storing-hashed-passwords) to detect reused password. - Allow [login activities from personal browser profiles to be logged](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#logging-personal-profile-user-activity). - Allow [sign-in activity and account activity from personal accounts to be logged](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#logging-personal-accounts). - Allow [ambigious userames to be logged](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#logging-personal-accounts) when logging of personal accounts is disabled. - Define items in the [global allow list](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#managing-global-allowlist) that Application Visibility will not monitor. - Define who can [pause monitoring by the browser extension](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#pausing-the-browser-extension). # Configuring Privacy Controls Admins can set when the [browser extension](https://documentation.sailpoint.com/saam/help/browser_extension/index.html) monitors and logs browser activity through privacy controls. - [**Send password hashes to the cloud**](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#sending-password-hashes-to-the-cloud) - When enabled, password hashes are sent to the Application Visibility cloud so Application Visibility can detect reused passwords and compromised accounts. - [**Store hashed passwords**](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#storing-hashed-passwords) - When enabled, hashed passwords are stored so Application Visibility can detect reused passwords. - [**Activate when using personal profile**](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#logging-personal-profile-user-activity) - When enabled, and a non-corporate browser profile is used, Application Visibility will monitor and log the activity. - [**Logging personal accounts**](#logging-personal-accounts) - When enabled, all accounts including corporate and personal are logged. - [**Global allowlist**](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#managing-global-allowlist) - When an application, domain, or IP address is added, Application Visibility will not monitor activity for sessions involving matching items. - [**Set who can pause the browser extension**](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#pausing-the-browser-extension) - Set whether all or only specific users are allowed to pause the extension. ## Sending Password Hashes to the Cloud The Send Hashed Passwords to the Cloud toggle allows the Application Visibility browser extension to transmit a cryptographically hashed version of the user’s username and password to the Application Visibility cloud. This transmission supports security checks, including: - **Breached/Compromised Credentials** - Determines whether the account appears in known breach or dark-web datasets. - **Password Reuse Detection** - Detects whether the same password is used across multiple applications. Important - Enabling Send Password Hashes to the Cloud only submits the hash for external verification. The hashed username and password is not stored. This is sufficient for the detection of compromised credentials. - To support password reuse detection, Send Password Hashes to the Cloud and [Store Hashed Passwords](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#storing-hashed-passwords) must be enabled. **To send password hashes to the cloud:** 1. Go to **General settings > General** tab. 1. Within the **Privacy** section, select the toggle next to **Send password hashes to the cloud**. ## Storing Hashed Passwords The Store Hashed Passwords toggle allows the Application Visibility browser extension to store a cryptographically hashed version of the user’s password on their endpoint to support detection of reused passwords. **To store hashed passwords:** 1. Go to **General settings > General** tab. 1. Within the **Privacy** section, select the toggle next to **Store hashed passwords so Savvy can detect reused passwords**. Important To fully support password reuse detection, [Send Password Hashes to the Cloud](https://documentation.sailpoint.com/saam/help/settings/privacy_settings.html#sending-password-hashes-to-the-cloud) and Store Hashed Passwords must be enabled. ## Logging Personal Profile User Activity The Activate when using personal profile toggle controls if Application Visibility monitors and logs user activity when a non-corporate browser profile is used. **To activate browser extension when using a non-corporate browser profile:** 1. Go to **General settings > General** tab. 1. Within the **Privacy** section, select the toggle next to **Activate when using personal profile**. Note This setting only applies if your organization requires the use of separate browser profiles for corporate and personal web browsing. ## Logging Personal Accounts The Log all accounts toggle controls if Application Visibility logs activity and discovered accounts for personal accounts. When disabled, you can configure whether discovered apps for ambiguous usernames, such as usernames without a domain suffix, are logged even when they cannot be identified as a corporate account. Activity of unresolved identities is always logged. If during the session the identity is resolved and it shouldn't be logged, logging is stopped for the remainder of the session. **To log sign-in activity and accounts for personal accounts:** 1. Go to **General settings > General** tab. 1. Within the **Privacy** section, select the toggle next to **Log all accounts**. **To log ambiguous usernames:** 1. Go to **General settings > General** tab. 1. Within the **Privacy** section, disable the toggle next to **Log all accounts**. 1. Enable the toggle next to **Log ambiguous usernames**. Tip Admins can configure the **include-in-corporate-hostnames** and **include-in-corporate-apps** [lists](https://documentation.sailpoint.com/saam/help/lists.html) to define which apps should always be considered as corporate. When **Log all accounts** is disabled, activity for hostnames or apps that match will be logged. ## Managing Global Allowlist The Global Allow List is a policy-level feature that allows admins to explicitly exclude specific websites or applications from being monitored. When a website or application is included in the global allow list, the browser extension does not trigger for that destination resulting no activity being collected or logged. **To add an application to the allowlist:** 1. Go to **General settings > Global allowlist** tab. 1. Select **Add items**. 1. Select **Applications**. 1. Select **Next**. 1. On the allow items window, select the **Value** field and complete the following: - Select **Lists** to choose [lists](https://documentation.sailpoint.com/saam/help/lists.html) of applications. - Select **Applications** to choose individual applications. 1. Select **Add**. Application Visibility will not monitor activity for sessions involving matching websites or applications. **To add a domain to the allowlist:** 1. Go to **General settings > Global allowlist** tab. 1. Select **Add items**. 1. Select **Domains**. 1. Select **Next**. 1. On the allow items window, select the **Value** field. 1. Select the desired [list](https://documentation.sailpoint.com/saam/help/lists.html) of domains. 1. Select **Add**. Application Visibility will not monitor activity for sessions involving matching domains. **To add an IP address to the allowlist:** 1. Go to **General settings > Global allowlist** tab. 1. Select **Add items**. 1. Select **Domains**. 1. Select **Next**. 1. On the allow items window, select the **Value** field. 1. Select the desired [list](https://documentation.sailpoint.com/saam/help/lists.html) of IP addresses. 1. Select **Add**. Application Visibility will not monitor activity for sessions involving matching IP addresses. ## Pausing the Browser Extension Admins can configure whether all users or only specific users can pause the browser extension on their endpoint. **To configure who can pause the browser extension:** 1. Go to **Extensions > Settings** tab. 1. In the **Set who can pause the extension** section, complete the following: - **All users** – Select to allow all users to pause the browser extension. - **Only the following users** – Select to choose specific users or groups that can pause the browser extension. 1. Select **Save**. # Configuring Security Settings Admin users manage Application Visibility through the admin console, where they can view and retrieve data. Users with the Org Admin user level can also configure system settings, define privacy controls, and create API tokens to allow API clients to integrate with the Application Visibility platform. For more information about admin user levels, refer to [User Levels and Permissions](https://documentation.sailpoint.com/saam/help/index.html#user-levels-and-permissions). ## Configuring Discovery Settings You can configure the scope of activity that is discovered and tracked by Application Visibility, and for which areas of organization. To temporarily stop discovery for all users, select **Pause discovery**. To restart discovery for the configured select **Start discovery**. ### Configuring User Activity Types to Discover Activity types control Application Visibility’s scope of visibility into user activity and potential security risks. **To configure which user activity types you want to discover:** 1. Go to **Playbooks > Discovery settings > Activity**. 1. Enable the toggle next to each desired type. | Activity Type | Description | | ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | **General** | | | General website browsing | Tracks general browsing activity to identify accessed applications and services. | | **Data** | | | File downloads | Tracks download activity to help identify potential data ingress and risky file acquisition patterns. | | File uploads | Tracks upload activity to help identify potential data exfiltration paths. | | Print attempt | Tracks web page printing events. | | **Identity** | | | Corporate credentials used in unmapped web apps | Tracks events where users have submitted corporate credentials to unmapped web applications that were not visited by other employees before. | | Submission of credentials | Track events where employees submitted credentials to websites. This includes any type of credentials against any website. | | Sign-ins, sign-ups, and password changes to SaaS applications | Track sign-in events to web applications. Discover IdP password changes when using the web interface of Entra or Okta. | | OAuth | Track OAuth authorization events against OAuth providers (Microsoft, Google, LinkedIn, Apple, Facebook). | ### Configuring Organizational Areas to Track You can control which users and areas of your organization are tracked by Application Visibility. **To configure which users activity is discovered and tracked:** 1. Go to **Playbooks > Discovery settings > Target**. 1. Select the Target group field, and choose the desired [target groups](https://documentation.sailpoint.com/saam/help/target_groups.html). ## Managing API Tokens You can use API personal access tokens to allow API clients to integrate with the Application Visibility platform. **To create an API token:** 1. Go to **General settings > General** tab. 1. Within the **Management API** section, select **Manage API tokens**. 1. On the **API Tokens** page, select **+ New token**. 1. In the **Label** field, enter a name to identify the API token. 1. Select **Create** to generate the API token. 1. Copy and store the token somewhere safe. Important Do not close this window without copying your token. You cannot view or change it later.