Troubleshooting Access Decisions


SGNL leverages business context from Data Sources in order to make just-in-time access decisions. In any organization, there will be times when an Administrator, Support User, or Audit/Compliance Specialist will need to understand why a specific access decision was made.

SGNL provides various capabilities to support the troubleshooting of Access Decisions, many of these will be discussed in this article.

How Access Decisions are made

You can have any number of Policy versions assigned to a protected integration and different policies may affect various principals, assets, and actions differently.

It’s important to think about the order by which access decisions are made:

  1. Deny Decisions: Enforced policies that provide Deny decisions, that are matched on a given access request, will immediately return a Deny decision to your protected integration.
  2. Allow Decisions: If no Policies that provide Deny decisions are matched to the request, enforced policies with Allow decisions are evaluated. If one or more policies provide an Allow decision, the principal will be allowed to perform the requested operation.
  3. Default Decision: If no Allow or Deny decisions are reached with any of the enforced policies assigned to the Integration, the default decision for that Integration will be returned. Depending on how you’ve configured the integration - this may result in an Allow or a Deny decision.

There may be times where you have only Simulated policies assigned to an Integration. Simulated policies will never impact the Access Decision returned by the SGNL Access Service. They will however provide logging and auditing events that can be used to assess the impact of a policy being applied to an integration.

Simulated policies can also be useful for debugging and troubleshooting to understand individual impacts of policies.

Policy Lens

SGNL Policy Lens is the most straightforward way to understand why a given Access Decision has been made in one of the systems that have been configured to use SGNL to provide access control.

  1. To get started with Policy Lens, select it from the left navigation menu, and select the Protected Integration you’re investigating.

    SGNL - Policy Lens

  2. Enter the Principal ID of the user you are investigating, using the format detailed below the Principal ID field (in this case, userPrincipalName).

    • Note: Remember that different integrations can use different (or many) identifiers for Principals, so be sure to check here or in the integration directly to ensure you’re using a valid identifier.
  3. Enter either (or both) the Action and the Asset ID that you are interested in investigating, and select Evaluate.

    SGNL - Policy Lens results

  4. From this view, you can see the policy versions that are impacting access decisions in your integration and, if necessary, investigate further into the logic behind the policy.

Policy Lens also allows you to create multiple search queries in a single view, enabling you to compare and contrast different access requests to determine how different policies affect different principals, actions, or even different assets.

Event Logs

SGNL event logs provide granular information about events that happen in your SGNL environment.

SGNL Event Logs are broken up into Access Events and Synchronization Events, both of which can impact the Access Decisions that SGNL returns.

Access Events

Access Events describe the access decisions and simulated access decisions that are occurring across integrations protected by SGNL.

Decisions in the Access Service are the responses that SGNL is handing back to your protected integrations. From here, you’re able to look for anomalies, understand trends, and troubleshoot an individual user’s access result.

SGNL - Logs

In addition to access decisions, you’re also able to look at the results of any policies you may have simulated for a given integration.

SGNL - Log filters

By selecting ‘Match’ in the Logs filters, you can see Policy Versions that are simulated in your environment and understand what the result of their evaluation might have been.

Synchronization Events

In order to make access decisions, SGNL’s policy engine evaluates data in the SGNL graph. This data is populated by the various data sources that are synchronizing business context. Events relating to the successful start and completion of synchronization runs are stored in the SGNL event logs.

SGNL - Sync logs

At times, synchronization may become interrupted between your Data Sources and SGNL - resulting in changes in your Data Source not being reflected in the SGNL Graph, and consequently not being considered in Access Decisions.

When SGNL detects an issue with synchronization, an event is raised in the Event Logs detailing Ingestion Failure and helpful debugging information.

SGNL - Event logs

You can use this data to understand a) whether synchronization is working and b) whether to expect issues when evaluating entities in the SGNL graph - enabling visibility into the state of connectivity and additional debugging/remediation.