Kob 45044 documents for 4 14 release (#253)

### Summary
<!-- In one or two sentences, describe your changes. -->
- Documents for 4.14 release

### Related PRs, issues, or features (optional)
<!-- Add "Fixes #XYZ" (Replace #XYZ with the GitHub issue or feature
number). -->
- https://kobiton.atlassian.net/browse/KOB-41007. Preview:
http://10.2.7.208/device-lab-management/deviceConnect/remote-update-deviceconnect
- https://kobiton.atlassian.net/browse/KOB-45412. Preview:
http://10.2.7.208/automation-testing/scripting/obfuscate-private-data-in-appium-script
- https://kobiton.atlassian.net/browse/KOB-45891. Preview:
http://10.2.7.208/devices/device-metadata#_lightning_mode
- https://kobiton.atlassian.net/browse/KOB-45892. Preview:
http://10.2.7.208/organization/sso-authentication/use-okta

### Metadata
<!-- ✅ Check all boxes that apply, like this: [x] -->
- [x] Adds new file(s)
- [x] Edits existing file(s)
- [x] Removes file(s)

### PR contributor checklist
<!-- Once you've filled out your metadata, select "Create Draft Pull
Request" and review your PR _before_ filling out the following
checklist. -->

- [x] My PR follows the [Kobiton Docs contributor
guidelines](https://github.com/kobiton/docs/blob/main/CONTRIBUTE.adoc),
meaning:

    - My content contains correct spelling and grammar.
- My directories and files are
[named](https://github.com/kobiton/docs/blob/main/CONTRIBUTING.md#directory-and-file-names)
and
[structured](https://github.com/kobiton/docs/blob/main/CONTRIBUTING.md#directory-structure)
correctly.
- My style and voice follows the [Microsoft Style
Guide](https://learn.microsoft.com/en-us/style-guide/brand-voice-above-all-simple-human).
- I added all new pages to their section's [`nav.adoc`
file](https://github.com/kobiton/docs/blob/main/CONTRIBUTING.md#configure-navigation-in-navadoc).
    - I removed all localizations (like `en-us`) from my URLs.

docs/modules/automation-testing/nav.adoc

@@ -13,6 +13,7 @@
 ** xref:automation-testing:scripting/create-biometric-authentication-script.adoc[]
 ** xref:automation-testing:scripting/add-image-injection-to-appium-script.adoc[]
 ** xref:automation-testing:scripting/run-applitools-eyes-script.adoc[]
+** xref:automation-testing:scripting/obfuscate-private-data-in-appium-script.adoc[]
 
 
 * Get a session ID

docs/modules/automation-testing/pages/scripting/obfuscate-private-data-in-appium-script.adoc

@@ -0,0 +1,166 @@
+= Obfuscate private data in Appium script
+:navtitle: Obfuscate private data in Appium script
+
+Learn how to obfuscate (hide) private data in an Appium test script in the *View HTTP Headers* and *Appium Inspector* section of Session Explorer.
+
+== Data obfuscation Appium setting
+
+We introduced a new custom setting to start and stop obfuscation for private data in an Appium sesssion:
+
+[options="header"]
+|=======================
+|Appium setting | Description | Default value
+| `kobiton:privateMode` | Set to `true` to start obfuscating data, or to `false` to stop obfuscating | `false`
+|=======================
+
+== Start data obfuscation
+
+Before starting a test action that involves private data, such as passing account password, use the `Update Settings` Appium command to set `'kobiton:privateMode'` to `true`.
+
+.Example (JavaScript)
+[source,javascript]
+
+await driver.updateSettings({'kobiton:privateMode': true})
+
+As long as the setting is `true`, the data provided is marked for obfuscation.
+
+== Stop data obfuscation
+
+When test steps no longer involve private data, use the `Update Settings` Appium command to set `'kobiton:privateMode'` back to `false`.
+
+.Example (JavaScript)
+[source,javascript]
+
+await driver.updateSettings({'kobiton:privateMode': false})
+
+After this command, the data is no longer obfuscated.
+
+== Examples
+
+Below is a complete example of JavaScript code using `wd` that demonstrates a simple login on a website, with the username and password obfuscated during the process.
+
+.Example (JavaScript)
+[source,javascript]
+
+----
+
+import 'babel-polyfill'
+import 'colors'
+import wd from 'wd'
+import {assert} from 'chai'
+
+const username = process.env.KOBITON_USERNAME
+const apiKey = process.env.KOBITON_API_KEY
+const deviceUdid = process.env.KOBITON_DEVICE_UDID
+const protocol = 'https'
+const host = 'api.kobiton.com'
+
+if (!username || !apiKey || !deviceUdid) {
+  console.log('Error: Environment variables KOBITON_USERNAME, KOBITON_API_KEY or KOBITON_DEVICE_UDID are required to execute script')
+  process.exit(1)
+}
+
+const kobitonServerConfig = {protocol, host, auth: `${username}:${apiKey}`}
+
+const desiredCaps = {
+  sessionName: 'Automation test data obfuscation',
+  sessionDescription: 'An automation test with private data to obfuscate',
+  udid: deviceUdid,
+  noReset: true,
+  fullReset: false,
+  browserName: 'chrome',
+  autoWebview: 'true',
+}
+
+let driver
+
+function sleep(ms) {
+  return new Promise((resolve) => setTimeout(resolve, ms))
+}
+
+describe('Android Web sample', () => {
+  before(async () => {
+    driver = wd.promiseChainRemote(kobitonServerConfig)
+
+    driver.on('status', (info) => {
+      console.log(info.cyan)
+    })
+    driver.on('command', (meth, path, data) => {
+      console.log(' > ' + meth.yellow, path.grey, data || '')
+    })
+    driver.on('http', (meth, path, data) => {
+      console.log(' > ' + meth.magenta, path, (data || '').grey)
+    })
+
+    try {
+      await driver.init(desiredCaps)
+    }
+    catch (err) {
+      if (err.data) {
+        console.error(`init driver: ${err.data}`)
+      }
+      throw err
+    }
+  })
+
+  it('should perform a simple login', async () => {
+    await driver.settings()
+
+    // Start obfuscating data before passing username and password.
+    await driver.updateSettings({'kobiton:privateMode': true})
+    await driver.settings()
+
+    // Send username and password to log in.
+    await driver.get('https://the-internet.herokuapp.com/login')
+     .waitForElementByName('username')
+     .sendKeys('tomsmith')
+     .sleep(1000)
+     .waitForElementByName('password')
+     .sendKeys('SuperSecretPassword!')
+     .sleep(3000)
+     .keys(wd.SPECIAL_KEYS.Enter)
+
+    // Login completes. Stop obfuscating data.
+    await driver.updateSettings({'kobiton:privateMode': false})
+    await driver.settings()
+
+    await driver.get('https://the-internet.herokuapp.com/')
+    await sleep(2000)
+    await driver.title()
+
+  })
+
+  after(async () => {
+    if (driver != null) {
+    try {
+      await driver.quit()
+    }
+    catch (err) {
+      console.error(`quit driver: ${err}`)
+    }
+  }
+  })
+})
+
+
+----
+
+== Obfuscated private data in Session Explorer
+
+When an Appium script with data obfuscation finishes running, the private data is obfuscated in the Session Explorer page in these places:
+
+* View HTTP Headers
+
+image:session-explorer-obfuscate-private-data-http-headers.png[width=500,alt="The obfuscated data in the View HTTP Headers section"]
+
+* Appium Inspector
+
+image:session-explorer-obfuscate-private-data-inspector.png[width=500,alt="The obfuscated data in the Appium Inspector section"]
+
+== Limitations/Notes
+
+* Only supported in Xium and Appium 2 Basic automation sessions.
+
+* Unlike Manual sessions with sensitive data, Automation sessions with obfuscated data are not marked as sensitive sessions and can be accessed by admins or other team members.
+
+* Although the private data is obfuscated in _View HTTP Headers_ and _Appium Inspector_, it may not be obfuscated in session video, screenshots, and logs.

docs/modules/device-lab-management/nav.adoc

@@ -3,6 +3,7 @@
 ** xref:deviceConnect/hardware-requirements-for-deviceconnect.adoc[]
 ** xref:deviceConnect/retrieve-deviceconnect-logs.adoc[]
 ** xref:deviceConnect/restart-deviceconnect-services.adoc[]
+** xref:deviceConnect/remote-update-deviceconnect.adoc[]
 * xref:ios-devices/index.adoc[]
 ** xref:ios-devices/prepare-ios-device.adoc[]
 ** xref:ios-devices/generate-an-ios-signing-certificate-and-provisioning-profile.adoc[]

docs/modules/device-lab-management/pages/deviceConnect/remote-update-deviceconnect.adoc

@@ -0,0 +1,81 @@
+= Perform a remote deviceConnect update
+:navtitle: Perform a remote deviceConnect update
+
+Cloud and Hybrid customers hosting dedicated devices can perform a remote update for deviceConnect on the Mac mini host. This action can be performed either manually or automatically from the Kobiton Portal via the Device Management page.
+
+
+== Prerequisites
+
+* Only available for Cloud and Hybrid customers.
+* Gather the internal IP address or hostname of the Mac mini host(s).
+* Kobiton administrator with the ADMIN predefined permission.
+* Remote update is available in deviceConnect version 4.13.0 and above.
+
+== Perform a remote deviceConnect update manually
+
+When the below notification banner appears in the Portal, a deviceConnect update is available for at least 1 Mac mini host in your organization:
+
+image:new-version-available.png[width=1000,alt="The banner about new version of deviceConnect"]
+
+To update deviceConnect remotely, log in to the Kobiton Portal with an administrator account.
+
+include::profile:partial$open-settings.adoc[]
+
+Select the *Device Management* tab.
+
+The *Device Management* page lists all dedicated mobile devices for the org grouped by Mac mini host. Locate the Mac mini host you want to update and select the corresponding *Upgrade* button.
+
+[TIP]
+A Mac mini host that does not have the latest deviceConnect version has a warning icon next to its name in Device Management.
+
+[IMPORTANT]
+Make sure the current deviceConnect version on the Mac mini host is at least 4.13.0 before continuing, as deviceConnect below this version cannot be updated via the Portal.
+
+image:upgrade-host-machine-device-management.png[width=1000,alt="The Upgrade button next to the hosting machine name in Device Management"]
+
+In the confirmation modal, choose *Upgrade* again to proceed.
+
+The Mac mini host will download the latest deviceConnect version and apply the update. Once the update starts, any active sessions on devices hosted by that Mac mini will be terminated. During the update, no actions can be performed on the Mac mini or the connected devices (all the buttons are grayed out).
+
+After the update finishes, the devices should automatically come back online. Double-check the current version of deviceConnect on the Mac mini host to verify if the update is successful.
+
+== Enable or disable automatic deviceConnect update for an organization
+
+By default, automatic deviceConnect update is disabled for an organization. When automatic update is enabled, the system will periodically check for the latest deviceConnect version, download it, then update.
+
+The update only starts when all devices hosted by the Mac mini are not in use, i.e. there is no active sessions on the devices. If there are active sessions on the devices, the update is skipped until the next update check (about 30 minutes between each check).
+
+To check the current automatic update setting for your organization, or to enable/disable automatic update, follow the steps below:
+
+Log in to the Kobiton Portal with an administrator account.
+
+include::profile:partial$open-settings.adoc[]
+
+Select the *Device Management* tab. If the organization has at least 1 Mac mini host with online devices, the *New version upgrade* section displays and *Manual* is selected by default:
+
+image:device-management-new-version-upgrade-manual.png[width=800,alt="The New version upgrade option in Device Management"]
+
+To enable automatic update, select the drop-down list, choose *Automatic*, then choose *Save*:
+
+image:device-management-new-version-upgrade-automatic.png[width=500,alt="The New version upgrade set to Automatic"]
+
+== Force offline devices for old deviceConnect versions
+
+Devices are automatically taken offline on the Kobiton portal if the deviceConnect version on the Mac mini host is two major versions behind the current release.
+
+For example, if the latest deviceConnect version is 4.14, all devices hosted by deviceConnect v4.12 or below will become offline. Devices hosted by deviceConnect v4.13 are still online until v4.15 is released (if not updated).
+
+[WARNING]
+====
+
+When adding a new hosting machine with deviceConnect v4.12 or earlier to an organization, neither the machine nor its devices appear on the Device Management page in the portal.
+
+To avoid this issue, ensure that deviceConnect v4.13 or later is installed on all new hosting machines.
+
+====
+
+When devices are offline due to deviceConnect version being outdated, you will see  `Kobiton upgrade required` under the device message in *Settings* -> *Device Management*:
+
+image:device-lab-management:force-offline-devices-old-deviceconnect.png[width=1000,alt="The Kobiton upgrade required message under Device Management"]
+
+Perform the deviceConnect update manually or automatically to make the devices online again.

docs/modules/devices/pages/device-metadata.adoc

@@ -109,3 +109,13 @@ The device model, such as `D10Ap` or `Lenovo TB-8705F`.
 == Location
 
 The location where the device is physically located, such as `Atlanta, US`.
+
+== Lightning mode
+
+The Lightning mode capability of the device. This can filter devices with or without Lightning mode support.
+
+image:devices:lightning-mode-filter-device-list.png[width=400,alt="The Lightning mode filter options in Device List"]
+
+In List View, the Lightning mode column (when enabled) indicates the Lightning mode capability of the device:
+
+image:devices:lightning-mode-indicator-device-list.png[width=1000,alt="The lightning indicator on the device under the list view"]

docs/modules/organization/partials/sso-authentication/add-idp-parameters-and-certificate-to-kobiton.adoc

@@ -11,3 +11,8 @@ Add your IdP parameters and certificate to the following:
 * *Identity provider sign in URL*
 * *Identity provider sign out URL*
 * *Identity provider certificate*
+
++
+
+[IMPORTANT]
+The Identity provider certificate must be a `.pem` file. If the certificate downloaded from the IdP has a different file extension (such as `.cert`), rename it to `.pem` before uploading.

docs/modules/organization/partials/sso-authentication/verify-and-save-configuration.adoc

@@ -1,11 +1,33 @@
 // Verify and save configuration
 
-If you enable *Enforce users to login to Kobiton only through SSO*, you'll also gain access to *Specify Organization Access Restrictions* with the ability to enable *Pass role/team assignments to users in the SAML validations*.
+*Important*: Make sure you have created an account with the same email as the currently logged in Kobiton account and assign the new SAML application to that user on the IdP side before continuing.
 
-Choose the method that's best for your organization.
+Select *Verify* to test your SSO configuration.
 
-image:organization:sso-organization-access-restrictions.png[width=1000, alt="The Specify Organization Access Restrictions step in SSO settings"]
+image:organization:sso-verify-configuration.png[width=1000, alt="The Verify button under Verify Configuration"]
 
-After you've chosen a method, select *Verify* to test your SSO configuration.
+The system will open a new browser tab to the SSO login page. In this new tab, logs in using the account that has the same email as the current Kobiton account.
 
-If you received a successful response, select *Save* to complete your SSO configuration.
+If logged in successfully, go back to the previous browser tab with the SSO Settings opened.
+
+Wait for a while for the SSO Settings page to automatically reload (*do not force reload the page*) and a success message displays like the below:
+
+image:organization:sso-verify-configuration-verified.png[width=1000, alt="The success message under Verify Configuration"]
+
+After receiving the success response, select *Save* to complete your SSO configuration.
+
+After verifying and saving the configuration, you can turn on *Enforce users to login to Kobiton only through SSO* to force the users to log in only via SSO (optional).
+
+When SSO login enforcement is turned on:
+
+* You can add existing users to be exempted from the SSO login enforcement by adding the username into the *Choose users who are allowed to login without SSO* field.
+
++
+
+image:organization:sso-choose-non-sso-users.png[width=500, alt="The list of users that are exempted from the enforcement list when SSO enforcement is enabled"]
+
+* You also gain access to *Specify Organization Access Restrictions* with the ability to enable *Pass role/team assignments to users in the SAML validations*. Choose the method that's best for your organization.
+
++
+
+image:organization:sso-organization-access-restrictions.png[width=1000, alt="The Specify Organization Access Restrictions step in SSO settings"]

docs/modules/release-notes/pages/all-releases/4_14.adoc

@@ -47,13 +47,13 @@ Users can easily find devices that support Lightning mode in the Device List by:
 
 * Selecting *Lightning mode* in the device search bar and choose *Supported*:
 
-image:lightning-mode-filter-device-list.png[width=400,alt="The Lightning mode filter options in Device List"]
+image:devices:lightning-mode-filter-device-list.png[width=400,alt="The Lightning mode filter options in Device List"]
 
 * Choosing *List View*, then *Edit Column*, and check *Lightning mode* to see devices with the Lightning icon:
 
-image:lightning-mode-list-view-column.png[width=250,alt="Show the Lightning mode column in the List View of Device List"]
+image:devices:lightning-mode-list-view-column.png[width=250,alt="Show the Lightning mode column in the List View of Device List"]
 
-image:lightning-mode-indicator-device-list.png[width=1000,alt="The lightning indicator on the device under the list view"]
+image:devices:lightning-mode-indicator-device-list.png[width=1000,alt="The lightning indicator on the device under the list view"]
 
 == Script-based automation: obfuscate sensitive data in HTTP headers and Inspector of Session Explorer
 
@@ -67,11 +67,11 @@ Below are sample screens with obfuscated data for:
 
 * View HTTP Headers
 
-image:session-explorer-obfuscate-private-data-http-headers.png[width=500,alt="The obfuscated data in the View HTTP Headers section"]
+image:automation-testing:session-explorer-obfuscate-private-data-http-headers.png[width=500,alt="The obfuscated data in the View HTTP Headers section"]
 
 * Appium Inspector
 
-image:session-explorer-obfuscate-private-data-inspector.png[width=500,alt="The obfuscated data in the Appium Inspector section"]
+image:automation-testing:session-explorer-obfuscate-private-data-inspector.png[width=500,alt="The obfuscated data in the Appium Inspector section"]
 
 [NOTE]
 ====
@@ -100,11 +100,11 @@ To avoid this issue, ensure that deviceConnect v4.13 or later is installed on al
 
 When devices are offline due to deviceConnect version being too old, you will see  `Kobiton upgrade required` under the device message in *Settings* -> *Device Management*:
 
-image:force-offline-devices-old-deviceconnect.png[width=1000,alt="The Kobiton upgrade required message under Device Management"]
+image:device-lab-management:force-offline-devices-old-deviceconnect.png[width=1000,alt="The Kobiton upgrade required message under Device Management"]
 
 If this issue occurs and automatic upgrade is enabled in your organization, the system will automatically download and install the latest version of deviceConnect. If automatic upgrades are disabled, you can manually upgrade deviceConnect on the host machine by selecting *Upgrade*.
 
-image:upgrade-host-machine-device-management.png[width=1000,alt="The Upgrade button next to the hosting machine name in Device Management"]
+image:device-lab-management:upgrade-host-machine-device-management.png[width=1000,alt="The Upgrade button next to the hosting machine name in Device Management"]
 
 == Minor improvements and bug fixes