SSO & user management UPX

modules/ROOT/content-nav.adoc

@@ -74,6 +74,9 @@ Generic Start
 ** xref:logging/security-log-analyzer.adoc[Security log analyzer]
 ** xref:logging/log-downloads.adoc[Download logs]
 
+* **Security**
+** xref:security/single-sign-on.adoc[Single sign-on]
+
 * **Manage users**
 ** xref:user-management.adoc[]
 

modules/ROOT/pages/security/single-sign-on.adoc

@@ -0,0 +1,86 @@
+[[aura-reference-security]]
+= 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[]
+
+== SSO levels
+
+Organization admins can configure SSO on organization level and project level.
+
+SSO is a log-in method and access, roles, and permissions are dictated by role-based access control (RBAC).
+
+* *Organization-level:* Allows org admins to control how users log in when they are trying to access the org.
+Access beyond log-in is managed via RBAC.
+It is essentially a log-in method for the Aura console.
+
+* *Project-level:*  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.
+
+== 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.
+
+*Organization-level supports:*
+
+* Email/password
+* Okta
+* Microsoft Entra ID
+* Google SSO (not Google Workspace SSO)
+
+*Project-level supports:*
+
+* User/password
+* Okta
+* Microsoft Entra ID
+
+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.
+
+.Organization settings
+[.shadow]
+image::organizationsettings.png[A screenshot of how to navigate to organization settings in the UI]
+
+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.
+
+.SSO configuration
+[.shadow]
+image::sso.png[A screenshot of the SSO configuration dialogue,640,480]
+
+== Individual instance-level
+label:AuraDB-Business-Critical[]
+
+Support can assist with SSO configurations at instance-level including:
+
+* Role mapping specific to a database instance
+* Custom groups claim besides `groups`
+* Updating SSO on already running instances
+
+If you require support assistance, visit link:https://support.neo4j.com/[Customer Support] and raise a support ticket including the following information:
+
+
+. The _Project ID_ of the projects you want to use SSO for.
+See xref:platform/user-management.adoc#_projects[Projects] for more information on how to find your __Project ID__.
+
+. The name of your IdP

modules/ROOT/pages/user-management.adoc

@@ -4,9 +4,132 @@
 
 User management is a feature within Aura that allows you to invite users and set their roles within an isolated environment.
 
-image::inviteusers.png[]
+== Organization-level roles
+
+The following roles are available at the org level and these are assigned via invitation:
+
+* Owner
+* Admin
+* Member
 
-== Projects
+:check-mark: icon:check[]
+.Roles
+[opts="header",cols="3,1,1,1"]
+|===
+| Capability
+| Owner
+| Admin
+| Member
+
+| List org
+| {check-mark}
+| {check-mark}
+| {check-mark}
+
+| List org projects
+| {check-mark}
+| {check-mark}
+| {check-mark}
+
+| Update org
+| {check-mark}
+| {check-mark}
+|
+
+| Add projects
+| {check-mark}
+| {check-mark}
+|
+
+| List existing SSO configs
+| {check-mark}
+| {check-mark}
+|
+
+| Add SSO configs
+| {check-mark}
+| {check-mark}
+|
+
+| List SSO configs on project-level
+| {check-mark}
+| {check-mark}
+|
+
+| Update SSO configs on project-level
+| {check-mark}
+| {check-mark}
+|
+
+| Delete SSO configs on project-level
+| {check-mark}
+| {check-mark}
+|
+
+| Invite non-owner users to org
+| {check-mark}
+| {check-mark}
+|
+
+| List users
+| {check-mark}
+| {check-mark}
+|
+
+| List roles
+| {check-mark}
+| {check-mark}
+|
+
+| List members of a project
+| {check-mark}
+| {check-mark} footnote:[An admin can only list members of projects the admin is also a member of.]
+|
+
+// | Add customer information for a trial within org
+// | {check-mark}
+// | {check-mark}
+// |
+
+// | List customer information for a trial within org
+// | {check-mark}
+// | {check-mark}
+// |
+
+// | List seamless login for org
+// | {check-mark}
+// | {check-mark}
+// |
+
+// | Update seamless login for org
+// | {check-mark}
+// | {check-mark}
+// |
+
+| Invite owners to org
+| {check-mark}
+|
+|
+
+| Add owner
+| {check-mark}
+|
+|
+
+| Delete owners
+| {check-mark}
+|
+|
+
+| Transfer projects to and from the org
+| {check-mark} footnote:[An owner needs to permission for both the source and destination orgs.]
+|
+|
+|===
+
+== Project-level roles
+
+image::inviteusers.png[]
 
 Grant users access to a project.