docs: add sign in restriction (#505)

Author: OP3ratordec

content/docs/administration/sign-in-frequency.md

@@ -2,27 +2,48 @@
 title: Sign-in Restriction
 ---
 
+This document explains some sign-in restrictions.
+
 ## Sign-in Frequency
 
 <PricingPlanBlock feature_name='SIGNIN_FREQUENCY' />
 
 **Sign-in Frequency** specifies the period that users are required to sign in again.
 
-### Prerequisites
-
-- **Workspace Admin** or **Workspace DBA** role
+Only **Workspace Admin** can update the **Sign-in Frequency** settings.
 
-### Procedure
+In Bytebase Workspace, Go to **Settings** -> **General** and scroll down to **Account** section, where you can
 
-1. Click **Settings** on the top bar.
-2. Click **General** under **Workspace**, and scroll down to the **Security** section.
-3. Choose between `Hour(s)` and `Day(s)`.
-4. Click `+`,`-` or input a number to set the **Sign-in Frequency**.
+- Choose between `Hour(s)` and `Day(s)`.
+- Click `+`,`-` or input a number to set the **Sign-in Frequency**.
 
-![sign-in-frequency](/content/docs/administration/sign-in-restriction/bb-sign-in-frequency.webp)
+![sign-in-frequency](/content/docs/administration/sign-in-restriction/sign-in-frequency.webp)
 
 <HintBlock type="info">
 
 You need to restart Bytebase and re-login to make the change take effect.
 
 </HintBlock>
+
+## Disallow Sign-in with Email & Password
+
+<PricingPlanBlock feature_name='SSO' />
+
+As `Workspace Admin`, having had [SSO](https://www.bytebase.com/docs/administration/sso/overview) (for example [OAuth 2.0 in GitHub](https://www.bytebase.com/docs/administration/sso/oauth2/#github)) configured, you can [enforce SSO sign-in](https://www.bytebase.com/docs/administration/sso/overview/#enforce-sso-sign-in) for all users in Workspace.
+
+## Sign-in from Email Domains
+
+Go to **Settings** -> **General**, scroll down to **Security** section. Fill in `Workspace Domain` tab with the email domain for your Workspace members. Click **Update** to save changes.
+
+![set-domain](/content/docs/administration/sign-in-restriction/set-domain.webp)
+
+You can restrict members' email addresses by ticking the `Members restriction` box. Afterwards, when you
+- Sign in (Note that the new restriction only works for the accounts registered after the `Workspace Domain` was updated)
+    ![sign-in-domain-restriction](/content/docs/administration/sign-in-restriction/sign-in-domain-restriction.webp)
+
+or
+
+-  **Add User** in **IAM & Admin** -> **Users & Groups**
+    ![add-user-domain-restriction](/content/docs/administration/sign-in-restriction/add-user-domain-restriction.webp)
+
+Users' email must be of the domain you set in both scenarios.

content/docs/administration/sign-in-restriction.md

@@ -14,13 +14,13 @@ In the creating SSO dialog, you need to fill following fields:
 
 ![oauth2-basic-information](/content/docs/administration/sso/oauth2-basic-information.webp)
 
-- **Name**: the display name shown to your users (e.g. `GitHub` will be shown as `Sign in with GitHub`)
-- **Identity Provider ID**: a human-readable unique string, only lower-case alphabets and hyphens are allowed (e.g. `github`)
-- **Domain**: the domain name to scope associated users (e.g. `github.com`, optional)
+- **Name**: the display name shown to your users (e.g. `Google` will be shown as `Sign in with Google`)
+- **Identity Provider ID**: a human-readable unique string, only lower-case alphabets and hyphens are allowed (e.g. `google-fsgs`)
+- **Domain**: the domain name to scope associated users (e.g. `google.com`, optional)
 
 ### Identity provider information
 
-The information is the base concept of [OAuth 2.0](https://oauth.net/2/) and comes from your provider.
+The information is the base concept of [OAuth 2.0](https://oauth.net/2) and comes from your provider.
 
 ![oauth2-identity-provider-information](/content/docs/administration/sso/oauth2-identity-provider-information.webp)
 
@@ -36,10 +36,11 @@ The information is the base concept of [OAuth 2.0](https://oauth.net/2/) and com
 
 ### User information mapping
 
-For different providers, the structures returned by their user information API are usually not the same. In order to know how to map the user information from an provider into Bytebase user fields, you need to fill the user information mapping form.
+For different providers, the structures returned by their user information API are usually not the same. That's why you need to fill an information mapping form for mapping user information into Bytebase user fields.
 
-Bytebase will use the mapping to import the user profile fields when creating new accounts.
-The most important user field mapping is the identifier which is used to identify the Bytebase account associated with the OAuth 2.0 login.
+Bytebase uses the mapping to import user profile fields when creating new accounts.
+
+The most important information is `Bytebase user's email`. It identifies the Bytebase account associated with the OAuth 2.0 login.
 
 ![oauth2-user-information-field-mapping](/content/docs/administration/sso/oauth2-user-information-field-mapping.webp)
 
@@ -77,7 +78,7 @@ Bytebase provides templates for configuring built-in OAuth providers.
 
 <PricingPlanBlock feature_name='SSO_BASIC' />
 
-1. Follow [Creating an OAuth App in GitHub](https://docs.github.com/en/developers/apps/building-oauth-apps/creating-an-oauth-app) to create an OAuth app in GitHub.
+1. Follow [Creating an OAuth App in GitHub](https://docs.github.com/en/developers/apps/building-oauth-apps/creating-an-oauth-app) to create an OAuth app in GitHub, where you replace `YOUR_EXTERNAL_URL` in the image below with the external URL you [configured](https://www.bytebase.com/docs/get-started/install/external-url) in Bytebase Workspace.
 
    ![github-oauth-app-config](/content/docs/administration/sso/github-oauth-app-config.webp)
 

content/docs/administration/sso/oauth2.md

@@ -16,17 +16,17 @@ Configure [External URL](/docs/get-started/install/external-url).
 
 ## Create SSO provider
 
-As a **Workspace Admin**, you can create a SSO provider with the following steps:
-
-1. Go to the **Settings** page.
-
-   ![settings-sso](/content/docs/administration/sso/settings-sso.webp)
+As a **Workspace Admin**, you can create a SSO provider following the steps below:
 
+1. In Workspace, go to **IAM & Admin** -> **SSO** from left side bar.
 2. Click **Create** to start creating SSO.
 3. Fill in all the required fields.
 
    ![create-sso-dialog](/content/docs/administration/sso/create-sso-dialog.webp)
 
+4. **Test Connection** on bottom left.
+5. If successfully connected, click **Update** on bottom right.
+
 ## Sign in with SSO
 
 <HintBlock type="info">
@@ -35,20 +35,20 @@ Bytebase employs JIT (Just-In-Time) user provisioning. It will create the user t
 
 </HintBlock>
 
-Once a valid SSO has been created, the user can choose the configured SSO provider to sign in.
+Once a valid SSO has been created, you can choose to sign in with the configured SSO provider.
 
 ![sign-in-with-github](/content/docs/administration/sso/sign-in-with-github.webp)
 
 ## Enforce SSO Sign-in
 
-As a **Workspace Admin**, you can enforce SSO sign-in for all users in the workspace.
+As `Workspace Admin`, you can enforce SSO sign-in for all users in Workspace.
 
-Go to the **Settings > Workspace > General**, find the **Security** section and turn on the **Disallow signin with email&password** option.
+In **Workspace**, go to **Settings** > **General**, scroll down to **Account** section and switch on `Disallow signin with email & password`. Then users can only sign in with SSO.
 
-![bb-disallow-emailpass-only-sso](/content/docs/administration/sso/bb-disallow-emailpass-only-sso.webp)
+![disallow-emailpass-only-sso](/content/docs/administration/sso/disallow-emailpass-only-sso.webp)
 
 Afterwards, when the user tries to sign in, the only option is to sign in with the configured SSO provider.
 
-![bb-only-sso](/content/docs/administration/sso/bb-only-sso.webp)
+![only-sso](/content/docs/administration/sso/only-sso.webp)
 
-In case of an emergency, the admin can log in by navigating to `<YOUR_URL>/auth/admin` and entering the email and password.
+In case of emergency, the admin can log in by navigating to `<YOUR_URL>/auth/admin` and entering the email and password.

content/docs/administration/sso/overview.md

@@ -15,6 +15,8 @@ than the internal one.
 
 </HintBlock>
 
+For testing purpose, you can get an endpoint online with [ngrok](https://dashboard.ngrok.com/get-started/setup/macos) as external URL.
+
 When running Bytebase in production, you should not make the node that's running the Bytebase server directly accessible to the client. Instead, you should set up an gateway such as Nginx or Caddy to forward requests to Bytebase.
 
 Logically, you need to configure 2 endpoints, the external URL that users use to access the Bytebase console, and the GitOps Webhook URL that the VCS pushes the webhook event for GitOps workflow. The former usually is accessed from