SGNL Version 1.0

Dec 19, 2022


  • An administrative user is automatically provisioned during client onboarding, based on the parameters specified
  • Users can change user roles directly from the SGNL Console
  • Users can be managed via the SGNL APIs to Create, Update, and Delete Users, as well as to perform management tasks such as password and role maintenance
  • Two new roles exist within SGNL:
    • Admin: Grants full access to the SGNL Platform
    • Reader: Allows read access to non-administrative portions of the SGNL Console and APIs

Data Sources

  • Create connections to 4 key data sources via the SGNL Console and API, including:
    • Azure Active Directory (Users and Groups)
    • Okta (Users and Groups)
    • Salesforce (Users and Customer Accounts)
    • ServiceNow (Users, Customer Accounts, and Cases)
  • Customize the Display Name and Attributes of entities synchronizing to the Graph
  • Create join rules between entities from different systems of record to build a complete graph picture
  • Support for granular control of the synchronization interval of data sources and individual entities


  • Integrations can now be created via the SGNL Console and API to represent applications and services that are protected by SGNL, with support for descriptive Display Names, Descriptions, and unique Integration Identifiers
  • Default Policy Decisions are now available on a per-integration basis, to configure the default behavior if no policies apply to a given request
  • Multiple Identifiers mappings now exist for Principals and Assets to link data in Access Requests to entities in the SGNL Graph
  • Multiple access tokens can now be generated for a given integration, each with unique display names and identifiers, enabling multiple tokens to be issued per integration
  • Versions of Policy can now be linked to an Integration in an Enforced mode, to impact the access decisions SGNL makes for a given integration
  • Version of Policy can now be linked to an integration in a Simulated mode, to audit and log the impact of the changes that will occur to access decisions from SGNL if a given policy is enforced on the integration


  • Policy Snippets can now be created via the Snippets API to scope Principals, Assets, Actions, and Conditions
  • Individual Policy Snippet Versions are now immutable, with new versions of a Policy Snippet able to be created for use in Policy Versions
  • Policy Snippets and Policy Snippet Versions now store metadata to understand when they were created
  • Policies can now be created from the SGNL Console and API and specified to either Allow or Deny access, based on a match on the policy criteria
  • Individual Policy Versions are now immutable, with each new version able to be used independently for Integrations in Simulated or Enforced mode
  • Policies and Policy Versions now contain creation metadata to audit management activities


  • SGNL now logs Access Decisions and Ingestion events in the SGNL logs
  • Logs can now be filtered by time range and type

Access Service

  • The Access Service now accepts Principal Identifiers, Asset Identifiers, and Actions as part of access requests
  • Enforced and Simulated policies are now evaluated as part of requests to the Access Service
  • The Access Service will now determine an Access Decision, based on assigned and matched policies on the integration, or a default decision if only Simulated policies are assigned, or if no Policies match the request