Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSO for review #563

Closed
wants to merge 7 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
56 changes: 25 additions & 31 deletions modules/ROOT/pages/platform/security/single-sign-on.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -2,29 +2,29 @@
= Single Sign-On (SSO)
:description: SSO allows you to log in to the Aura Console using their company IdP credentials.

label:AuraDB-Virtual-Dedicated-Cloud[]
label:AuraDS-Enterprise[]
label:AuraDB-Business-Critical[]
* *AuraDB Virtual Dedicated Cloud and AuraDS Enterprise* Supports both Organization SSO and Instance SSO which are configurable in the Aura console.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* *AuraDB Virtual Dedicated Cloud and AuraDS Enterprise* Supports both Organization SSO and Instance SSO which are configurable in the Aura console.
*AuraDB Virtual Dedicated Cloud and AuraDS Enterprise* support Single Sign-On both on Organization and Instance levels, configurable in the Aura console.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm missing information here about the limitations of SSO (ie that access, roles, and permissions are controlled via RBAC).
Also, a page should start with some sort of introduction, even if it is just a one-sentence paragraph. I suggest you remove the bullets here.

Copy link

@KingJohanna KingJohanna Dec 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Org SSO is available to orgs that have access to* AuraDB Virtual Dedicated Cloud, AuraDS Enterprise or AuraDB Business Critical.

*Aka the capability to create instances with any of these tiers. Effectively this is

  1. Orgs with plan type Virtual Dedicated Cloud.
  2. Orgs with plan type self-serve with at least one non-marketplace (N4GCP, AWS, Azure) project.

Copy link

@KingJohanna KingJohanna Dec 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I started questioning this logic, because we don't have a technical reason for this limitation.

In the next year, we plan to remove this restriction so that org SSO is available for all orgs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good stuff, SSO for all orgs will be a better user experience!

Organization owners and organization admins can configure one or more SSO login methods for user authentication.
* *AuraDB Business Critical* Individual instance level SSO is available by request through support.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* *AuraDB Business Critical* Individual instance level SSO is available by request through support.
*AuraDB Business Critical* Individual instance level SSO is available by request through support.

Copy link

@KingJohanna KingJohanna Dec 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is incorrect, instance SSO is always available for BC instances.

Copy link
Contributor Author

@fiquick fiquick Dec 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, but support can set up a special configuration so that only 1 instance in a project with multiple instances has SSO applied to it, and this is only available to Business Critical according to our support colleague. Would that be correct?


== SSO levels
SSO allows users to authenticate through an Identity Provider (IdP) to access an organization or instances within a project.

== Organization SSO

Organization admins can configure organization level SSO (org SSO) and project level SSO (project SSO).
_Use as a login method for the organization_
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this in italics?


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

* *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.
* Okta
* Microsoft Entra ID
* Google SSO (not Google Workspace SSO)

* *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.
You can disable email/password and Google SSO if Okta or Microsoft Entra ID are configured.

When Organization SSO is set up, the *Organization SSO login* link is available in the *Organization Settings > Summary* section of the Aura console.

=== SSO Org level roles

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

* Owner
* Admin
Expand Down Expand Up @@ -146,33 +146,25 @@ The following roles are available at the org level and these are assigned via in
|
|===

== Instance SSO

== Log-in methods
_Use as a login method for instances within Projects in this Org._
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, why italics?


Log-in methods are different for each SSO level.
Administrators can configure a combination of one or more of the log-in methods.
You can select which projects are included during setup.
Applies to authentication at the instance level meaning that the SSO login method is shown when a user tries to access an instance.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this referring to? The sentence is missing a subject?

Role mapping is a feature exclusive to Instance SSO.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it really? Role mapping exists at org level too and you've listed a whole table about org-level roles and their privileges.
I think what you're trying to say is that role-mapping via SSO is only available for instance SSO?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The UI says
Role mapping only applies for Instance SSO = For example "group1"=role1;"group2"=role2


*Org SSO supports:*
=== Instance SSO login methods

* 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.
You cannot disable user/password.
Professional and Free instances within your selected projects will not have SSO configured.

== Setup requirements

Accessing Aura with SSO requires:
To set up SSO, you need:

* Authorization Code Flow
* A publicly accessible IdP server
Expand All @@ -199,6 +191,8 @@ image::sso.png[A screenshot of the SSO configuration dialogue,640,480]

== Individual instance level SSO configurations available from Support

label:AuraDB-Business-Critical[]

Support can assist with:

* Role mapping specific to a database instance
Expand Down
Loading