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
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
Policies
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
Logs
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
