SGNL Release Notes

1.4

Fixed an issue where the ingestion of large payloads from Data Sources could cause synchronization to fail

Improved the accuracy of metrics on the sGNL dashboard and across data sources/policies
Enabled a new PATCH method for SGNL’s config APIs, simplifying the modification of configuration in SGNL

Simplified Okta configuration, eliminating the need to prepend the token type during configuration
Enabled new ways to create relationships between Salesforce Users and other objects in the SGNL Graph

Azure API Management is now available as a Data Source, supporting Users, Groups, and Products to synchronize into SGNL [Learn More]
Curity is now available as a Data Source, supporting Users to synchronize into SGNL [Learn More]
ServiceNow Groups have been added as a target for synchronization into SGNL
Improved Data Source synchronization robustness and implemented several bug fixes
Updating Data Sources now support PATCH operations

Integration request configuration has been improved to allow more flexibility in the required fields to evaluate access for an integration

Access Analyzer (soon to be Policy Lens) has launched, enabling granular troubleshooting of assigned Policies [Learn More]
Simulated Policies on integrations now accurately record matched log entries in Logging [Learn More]
Longer policy names are now supported

Logging layout, fields, and filtering capabilities have been improved to enable better discovery of log entries
Metrics for Data Sources (e.g. entity count), Integrations (e.g. access checks), and Policies (e.g. evaluations) have been created and are now visible on the dashboard and in their respective pages

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

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

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