Neo4j allows you to cascade SSO configuration applied at the Aura Console level to the underlying Aura instances.
This is only applicable to Aura VDC (Virtual Dedicated Cloud / Enterprise) and Business Critical instances.

Once the options are enabled, the Console SSO configuration will be cascaded to instances created after saving the above settings.

Important Points to consider:

Role Mapping:

• The Console SSO configuration has an option to add Role Mapping
   
• The SSO login to the Aura Console itself only supports Authentication and not Authorization. Users will still have to be managed manually through the User Management page.
• But the Configuration cascaded to the instance Level SSO does support IdP group to Neo4j DB Role mapping
• So the mapping you enter will be applicable to the instances.

Changes to the Configuration

• Changes made to the IdP app and secret WILL reflect in the underlying instances as this information is held at the Org SSO level.
• Changes made to the Group:Role mapping WILL NOT reflect in the underlying instance as these are stored at the instance level SSO. Any desired change will have to be manually override with the support team's help through a support ticket.
  • The updated configuration will only be applied to instances created after the changes were saved
• Any other manual overrides done to the instance level SSO after the configuration was cascaded will have to be managed manually - with the support team's help through a support ticket.

Changes required in the IdP application:

• Since SSO at the console level only supports ID Token, ensure that your ID token claims response includes groups.
• user to group membership. Ensure the users belong to the aforementioned group(s) in your IdP
• Aura Console SSO requires the application in the IdP side to be created as a 'Web' application, with https://login.neo4j.com/login/callback as the redirect URI.
• The type of client application or redirect URIs do not have to be changed.
• We have an intermediate layer that handles the redirect URIs needed for Browser, Bloom and Workspace.

The SSO settings at the Instance level do not match with the Console SSO configuration:

• If you run `CALL dbms.listConfig()` as shown, how can I see the SSO parameters configured in my Virtual Dedicated Cloud Tier instance? article, you may notice that the well-known discovery URI and Client ID are different from what you configured for the console SSO
• The 'SSO Cascade' from the Aura Console to the underlying instances is not just a copy-paste.
• An internal deployment of Auth0 comes into play.
• The client application in Auth0 includes the necessary redirect URIs for the different SSO login methods, such as Bloom and Browser.
• So, the discovery URI and Client ID used for the individual instances are the ones needed to communicate with the internal Client application in Auth0.
• Each 'SSO Configuration' you configure at the Aura Console will have its own 'Client ID', that maps to Client application in our internal Auth0 deployment.