Single Sign-On (SSO)

AuraDB Virtual Dedicated Cloud AuraDS Enterprise AuraDB Business Critical

SSO levels

Organization admins can configure organization level SSO (org SSO) and project level SSO (project SSO).

SSO is a log-in method and access, roles, and permissions are dictated by role-based access control (RBAC).

  • Org SSO: Allows org admins to restrict how users log in when they are trying to access the org. Access beyond log-in is managed via RBAC.

  • Project-level SSO: Impacts new database instances created within that project. It ensures users logging in with SSO have access to the database instances within the project. It depends on RBAC if the user can access and view or modify data within the database instances themselves. For this level, the role mapping may be used to grant users different levels of access based on a role in their identity provider (IdP). It does not give access to edit the project settings, for example to edit the project name, network access, or to edit the instance settings such as to rename an instance, or pause and resume.

SSO Org level roles

The following roles are available at the org level and these are assigned via invitation:

  • Owner

  • Admin

  • Member

Table 1. Roles
Capability Owner Admin Member

List org

List org projects

Update org

Add projects

List existing SSO configs

Add SSO configs

List SSO configs on project-level

Update SSO configs on project-level

Delete SSO configs on project-level

Invite non-owner users to org

List users

List roles

List members of a project

[1]

Invite owners to org

Add owner

Delete owners

Transfer projects to and from the org

[2]

1. An admin can only list members of projects the admin is also a member of.

2. An owner needs to permission for both the source and destination orgs.

Log-in methods

Log-in methods are different for each SSO level. Administrators can configure a combination of one or more of the log-in methods.

Org SSO supports:

  • Email/password

  • Okta

  • Microsoft Entra ID

  • Google SSO (not Google Workspace SSO)

An organization’s administrator can add Aura as a log-in from a tile in an organization’s Apps Dashboard.

Project SSO supports:

  • User/password

  • Okta

  • Microsoft Entra ID

However, at the project level you cannot disable user/password, but at the org level you can disable email/password and Google SSO as long as you have at least one other custom SSO provider configured.

Setup requirements

Accessing Aura with SSO requires:

  • Authorization Code Flow

  • A publicly accessible IdP server

To create an SSO Configuration either a Discovery URI or a combination of Issuer, Authorization Endpoint, Token Endpoint and JWKS URI is required.

Create a new SSO configuration

From the Organization settings, go to Single Sign-On and use the SSO Configuration button to set up a new SSO configuration.

A screenshot of how to navigate to organization settings in the UI
Figure 1. Organization settings

The checkboxes Use as a log in for the Organization and Use as login method for instances with projects in this Org define whether SSO should be only on Organization level, only on Project level, or both.

The required basic SSO configuration information can be retrieved from the IdP. Entering the Discovery URI pre-fills the fields below. If this is not known these fields can be completed manually.

A screenshot of the SSO configuration dialogue
Figure 2. SSO configuration

Individual instance level SSO configurations available from Support

Support can assist with:

  • Role mapping specific to a database instance

  • Custom groups claim besides groups

  • Updating SSO on already running instances

If you require support assistance, visit Customer Support and raise a support ticket including the following information:

  1. The Project ID of the projects you want to use SSO for. See Projects for more information on how to find your Project ID.

  2. The name of your IdP