Add new slack selector topic for Update an integration

packages/@okta/vuepress-site/docs/guides/index.md

@@ -72,6 +72,7 @@ guides:
  - submit-app
  - submit-app-prereq
  - submit-oin-app
+ - update-oin-app
  - add-private-app
  - deployment-checklist
  - deploy-your-app

packages/@okta/vuepress-site/docs/guides/update-oin-app/index.md

@@ -0,0 +1,9 @@
+---
+title: Update a published integration with the OIN Wizard
+meta:
+  - name: description
+    content: Learn how to update your published integration in the Okta Integration Network (OIN). The update and submit tasks are performed in the Okta Admin Console through the OIN Wizard.
+layout: Guides
+sections:
+ - main
+---

packages/@okta/vuepress-site/docs/guides/update-oin-app/main/index.md

@@ -0,0 +1,159 @@
+---
+title: Update a published integration with the OIN Wizard
+meta:
+  - name: description
+    content: Learn how to update your published integration in the Okta Integration Network (OIN). You can make updates and resubmit your integration in the OIN Wizard. The OIN team reviews your submission and updates the OIN catalog after your integration has been verified.
+layout: Guides
+---
+
+Learn how to update an OIDC, SAML 2.0, or SCIM 2.0 published integration in the Okta Integration Network (OIN) using the OIN Wizard.
+
+---
+
+#### What you need
+
+* A published OIDC, SAML 2.0, or SCIM integration in the OIN that was [submitted using the OIN Wizard](/docs/guides/submit-oin-app/).
+* The [Okta Developer Edition org](https://developer.okta.com/signup/) from where you originally submitted your published integration. The OIN Wizard is only available in Okta Developer Edition orgs.
+* An admin user in the Okta Developer Edition org with either the super admin or the app and org admin roles
+
+---
+
+## Overview
+
+If you have a published Single Sign-On (SSO) or lifecycle management integration in the OIN catalog, you can update and resubmit it with the OIN Wizard.
+
+The OIN Wizard currently supports updates for integrations that use the following protocols:
+
+* OIDC
+* SAML 2.0
+* SCIM 2.0
+
+When you edit a published OIN integration, test the flows for the updated version and the published version for backwards compatibility. Testing the published version for backwards compatibility ensures that your integration still works for users who have already installed it. See [Update integration considerations](#update-integration-considerations) before you edit your published integration. After you successfully test the updated and published versions of your integration, resubmit it to the OIN team.
+
+> **Note:** When you edit your published OIN integration, your previous PUBLISHED status and date are overwritten with the DRAFT status and current date.
+
+To update a previously published OIN integration:
+
+1. Sign in to your Okta Developer Edition org as a user with either app admin or super admin roles.
+   > **Note:** Edit your integration from an Okta account that has your company domain in the email address. You can't use an account with a personal email address. The OIN team doesn't review submission edits from a personal email account.
+1. In the Admin Console, go to **Applications** > **Your OIN Integrations**.
+
+   > **Note:** If you don't need to edit your submission and want to jump to testing, see [Navigate directly to test your integration](#navigate-directly-to-test-your-integration).
+
+1. Click your published integration to update from the dashboard. Your published OIN submission appears in read-only mode.
+1. From the **This integration is read-only** information box, click **Edit integration**.
+    > **Note:** If you open a submission in **DRAFT** status, it's not in read-only mode and the **Edit integration** option isn't available.
+
+    Continue to edit your draft submission as a new submission. See [Start a submission](#start-a-submission).
+1. If the OIN Wizard doesn't detect an instance to test your published integration in the org, then an **Application instance not detected** dialog appears. Click **Generate instance** to create an app instance based on your published OIN integration. See [Add existing app integrations](https://help.okta.com/okta_help.htm?type=oie&id=csh-apps-add-app) to create an instance for backwards-compatibility testing.
+    > **Note:** The **Generate instance** option is disabled if you have five active instances in your org. [Deactivate instances](#deactivate-an-app-instance-in-your-org) that you're not using.
+
+    If the OIN Wizard detects an instance based on your published integration, the dialog doesn't appear. This is usually the case if you tested and submitted your published integration from the same org.
+
+1. Continue to update your integration in the **Select protocol**, **Configure your integration**, and **Test integration** pages. See [Update integration considerations](#update-integration-considerations) for backwards compatibility with integration variables.
+
+    The **Required app instances** box contains the following items:
+    * The instances that you need to test the **PUBLISHED VERSION** of your OIN integration.
+    * The instances that you need to test the **CURRENT VERSION** of your integration submission.
+
+    See [Required app instances](#required-app-instances).
+    > **Note:** If the OIN Submission Tester session expired, click **Refresh tester session** for a new test session.
+
+   Backwards-compatible test instances that were generated from your published integration appear in the **Application instances for testing** list.
+
+1. Click **Generate Instance** to create an instance required for the **CURRENT VERSION** from the **Required app instances** status box.
+
+    See [Generate an instance for testing](#generate-an-instance-for) to create instances for your current submission.
+    > **Note:** There's a maximum of five active app instances allowed in a Developer Edition org. Deactivate any instances that you don't need for testing.
+
+1. Test your integration protocol:
+
+    * For SSO testing, click **Add to Tester** for each required test instance. See [Add to Tester](#add-to-tester).<br> The required tests appear for each test instance. Run your tests from the OIN Submission Tester. See [OIN Submission Tester](#oin-submission-tester). If you encounter errors, see [Failed tests](#failed-tests) for help with resolving the issues.
+
+    * For SCIM testing, see [Test your SCIM integration](#test-your-scim-integration) for all the test requirements.
+
+1. [Submit your updates](#submit-your-updates) if all your tests passed.
+
+## Update integration considerations
+
+* For published integrations that were migrated from the OIN Manager, if you need to update configured properties that aren't available the OIN Wizard, contact <oin@okta.com>.
+
+* You can't update a published SCIM integration with Basic authentication. This breaks the integration for existing customers. For any updates, you must submit a new SCIM integration that implements header authentication or OAuth 2.0 authentication. You can use either token or bearer token format for header authentication.
+
+* If you edit a published SCIM integration that was migrated from the OIN Manager, the **Import users** (and **Import groups** if groups are managed) capability is automatically enabled in the OIN Wizard. You must support and test this capability if your previous SCIM integration didn't support it. If you need help with implementing this feature, contact <developers@okta.com>.
+
+* When you update an integration that's already published, be mindful to preserve backwards compatibility for your integration. Older instances of your integration could be in use by Okta customers.
+
+    * If you modify the **Name** (`name`) property of your [integration variables](#integration-variables), Okta removes the original variable and creates a variable with your updated name. This action negatively impacts your existing customers if you use the original variable in your integration dynamic properties.
+
+    * Migrated published integrations from the OIN Manager don't have some OIN Wizard restrictions. For instance:
+
+        * Published integrations can have more than three integration variables
+        * Published integrations can have variable names with uppercase letters
+        * Published integrations can use `http` (instead of enforced `https`) in URLs and Expression Language-supported properties
+
+    * If your update introduces new variables and you're using dynamic URLs, ensure that your tests cover various scenarios with different possible values for those variables. See [Dynamic properties with Okta Expression Language](#dynamic-properties-with-okta-expression-language). The newly introduced variables aren't populated for older instances of your integration.
+
+        For example:
+
+       <StackSnippet snippet="backward-compatible-eg" />
+
+## Submit your updates
+
+After you successfully test your updated integration, you're ready to submit.
+
+The OIN Wizard checks the following for SSO submissions:
+
+* All required instances are detected.
+* All required instances are active.
+* All required tests passed within the last 48 hours.
+
+The OIN Wizard checks the following for SCIM submissions:
+
+* All required instances are detected.
+* All required instances are active.
+* The **Link to Runscope spec test results** field is specified.
+* The **Link to Runscope CRUD test results** field is specified.
+
+> **Note:** See [Test your SCIM integration](#test-your-scim-integration) for SCIM submission requirements.
+
+**Submit integration** is enabled after all these requirements are met.
+
+1. Select **I certify that I have successfully completed required tests**.
+1. Click **Submit integration** to submit your integration.
+1. Click **Close wizard**.
+    The **Your OIN Integration** dashboard appears.
+
+After you submit your integration, your integration is queued for OIN initial review. Okta sends you an email with the expected initial review completion date.
+
+The OIN review process consists of two phases:
+
+1. The initial review phase
+1. The QA testing phase
+
+Okta sends you an email at each phase of the process to inform you of the status, the expected phase completion date, and any issues for you to fix. If there are issues with your integration, make the necessary corrections and resubmit in the OIN Wizard.
+
+> **Note:** Sometimes, your fix doesn't include OIN Wizard edits to your integration submission. In this case, inform the OIN team of your fix so that they can continue QA testing.
+
+Check the status of your submission on the **Your OIN Integrations** dashboard.
+
+See [Understand the submission review process](/docs/guides/submit-app-overview/#understand-the-submission-review-process).
+
+## Submission support
+
+If you need help during your submission, Okta provides the following support stream for the various phases of your OIN submission:
+
+1. Building an integration phase
+
+    * When you're constructing your SSO app integration, you can post a question on the [Okta Developer Forum](https://devforum.okta.com/) or submit your question to <developers@okta.com>.
+
+1. Using the OIN Wizard to submit an integration phase
+
+    * If you need help with the OIN Wizard, review this document or see [Publish an OIN integration](/docs/guides/submit-app-overview/).
+    * Submit your OIN Wizard question to <developers@okta.com> if you can't find an answer in the documentation.
+    * If you have an integration status issue, contact <oin@okta.com>.
+
+1. Testing an integration phase
+
+    * If you have issues during your integration testing phase, you can post a question on the [Okta Developer Forum](https://devforum.okta.com/) or submit your question to <developers@okta.com>.
+

packages/@okta/vuepress-site/docs/guides/update-oin-app/main/openidconnect/backward-compatible-eg.md

@@ -0,0 +1,9 @@
+   Your integration update introduced a new variable (`companyId`), and you use it in your updated redirect URL. The redirect URL changed from `https://login.myapp.io` to `https://login.myapp.io?connection={app.companyId}`. In this case, ensure that the dynamic redirect URL is also valid for existing instances where the `companyId` value isn't set.
+
+   To handle empty `companyId` values, you can define the redirect URL as:
+
+   ```bash
+   https://{String.len(app.companyId) == 0 ? 'login.myapp.io' : 'login.myapp.io?connection=' + app.companyId}
+   ```
+
+   This expression handles both scenarios where `companyId` is populated or empty.

packages/@okta/vuepress-site/docs/guides/update-oin-app/main/openidconnect/protocol-fullname.md

@@ -0,0 +1 @@
+OpenID Connect (OIDC)

packages/@okta/vuepress-site/docs/guides/update-oin-app/main/openidconnect/protocol-name.md

@@ -0,0 +1 @@
+OIDC

packages/@okta/vuepress-site/docs/guides/update-oin-app/main/openidconnect/protocol-test-flow.md

@@ -0,0 +1,13 @@
+In the **OIDC tests** section, specify the following sign-in flow details:
+
+| <div style="width:150px">Property</div> | &nbsp; | Description  |
+| ----------------- | --: | ------------ |
+| **Supported sign-in flows** | | Indicates which sign-in flow your integration supports |
+| | **IdP** | Sign-in flow is initiated from the Okta End-User Dashboard. If you specified **Initiate login URI** previously from the [OIDC properties](#properties) section, then this flow is selected. |
+| | **SP** | Sign-in flow is initiated from your app sign-in page. This flow is selected and read-only because all OIDC SSO integrations must support the SP-initiated flow. |
+| **Supports Just-In-Time provisioning?** `*` | | Indicate if your integration supports Just-In-Time (JIT) provisioning. With JIT provisioning, user profiles are created when they sign in for the first time. This eliminates the need to create user accounts in advance. |
+| | **Yes** | Your integration supports JIT. |
+| | **No** | Your integration doesn't support JIT. |
+| **SP Initiate URL** | | Specify the URL for SP-initiated sign-in flows. This URL is required for the SP-initiated flow.<br>The maximum URL length is 512 characters. |
+
+`*` Required properties

packages/@okta/vuepress-site/docs/guides/update-oin-app/main/openidconnect/test-instance.md

@@ -0,0 +1,14 @@
+2. Specify the **Application label** and any app properties required in the **General settings** tab.
+3. Click **Done**. The **Assignments** tab appears.
+   You can assign users to your integration later, see the next [Assign test users to your integration](#assign-test-users-to-your-integration-instance) task.
+4. Click the **Sign On** tab to view and copy the OIDC client ID and secret.
+5. Click **View Setup Instructions** to open a new tab to your integration setup instructions. This is the customer configuration guide that you previously specified in the OIN Wizard.
+6. Follow the instructions in your guide to set up the SSO integration on your app with the OIDC client ID and secret provided.
+7. Follow these steps if you have an Identity Engine Developer Edition org:
+   1. Click the **Sign On** tab, scroll to the **User authentication** section, and click **Edit**.
+   1. Select **Password only** from the **Authentication policy** dropdown menu.
+   [[style="list-style-type:lower-alpha"]]
+   1. Click **Save**.
+   > **Note:** Most recent Okta Developer Edition orgs are Identity Engine orgs. See [OIN Wizard authentication policy for testing](/docs/guides/submit-app-prereq/main/#oin-wizard-authentication-policy-for-testing).
+
+8. [Assign test users to your instance](#assign-test-users-to-your-integration-instance) before you start testing your SSO flows.

packages/@okta/vuepress-site/docs/guides/update-oin-app/main/openidconnect/variable-desc.md

@@ -0,0 +1,13 @@
+For example, if you have an OIDC configuration variable called `subdomain`, then you can set your **Redirect URI** string to `https://{app.subdomain}.example.org/strawberry/login`. When your customer sets their `subdomain` variable value to `berryfarm`, then `https://berryfarm.example.org/strawberry/login` is their redirect URL.
+
+> **Note**: A variable can include a complete URL (for example, `https://example.com`). This enables you to use global variables, such as `app.baseURL`.
+
+The following are Expression Language specifics for OIDC properties:
+
+* OIDC [integration variables](#integration-variables) you define in the OIN Wizard are considered [Application properties](/docs/reference/okta-expression-language/#application-properties) and have the `app.` prefix when you reference them in Expression Language. For example, if your integration variable name is `subdomain`, then you can reference that variable with `app.subdomain`.
+
+* OIDC properties support [Expression Language conditional expressions](/docs/reference/okta-expression-language/#conditional-expressions) and evaluates everything between curly brackets. For example, the following is an expression for the **Redirect URI** property:
+
+    ```js
+    {String.stringContains(app.environment, 'PROD') ? 'https://app.data.one/' : 'https://app-sandbox.data.one/'}
+    ```

packages/@okta/vuepress-site/docs/guides/update-oin-app/main/saml2/backward-compatible-eg.md

@@ -0,0 +1,9 @@
+   Your integration update introduced a new variable (`companyId`), and you use it in your updated ACS URL. The ACS URL changed from `https://login.myapp.io` to `https://login.myapp.io?connection={org.companyId}`. In this case, ensure that the dynamic ACS URL is also valid for existing instances where the `companyId` value isn't set.
+
+   To handle empty `companyId` values, you can define the ACS URL as:
+
+   ```bash
+   https://${empty org.companyId ? 'login.myapp.io' : 'login.myapp.io?connection=' += org.companyId}
+   ```
+
+   This expression handles both scenarios where `companyId` is populated or empty.

packages/@okta/vuepress-site/docs/guides/update-oin-app/main/saml2/protocol-fullname.md

@@ -0,0 +1 @@
+Security Assertion Markup Language (SAML)

packages/@okta/vuepress-site/docs/guides/update-oin-app/main/saml2/protocol-name.md

@@ -0,0 +1 @@
+SAML

packages/@okta/vuepress-site/docs/guides/update-oin-app/main/saml2/protocol-test-flow.md

@@ -0,0 +1,14 @@
+In the **SAML tests** section, specify the following sign-in flow details:
+
+| <div style="width:150px">Property</div> | &nbsp; | Description  |
+| ----------------- | --: | ------------ |
+| **Supported sign-in flows** | | Indicate which sign-in flow your integration supports. You must select at least one of the following flows. |
+| | **IdP** | Sign-in flow is initiated from the Okta End-User Dashboard. |
+| | **SP** | Sign-in flow is initiated from your app sign-in page. |
+| **Supports Just-In-Time provisioning?** `*` | | Indicate if your integration supports Just-In-Time (JIT) provisioning. With JIT provisioning, you can use a SAML assertion to create users the first time they try to sign in. This eliminates the need to create user accounts in advance. |
+| | **Yes** | Your integration supports JIT. |
+| | **No** | Your integration doesn't support JIT. |
+| **SP Initiate URL** | | Specify the URL for SP-initiated sign-in flows. This URL is required for the SP flow.<br>The maximum URL length is 512 characters.  |
+| **SP Initiate flow description** | | Provide instructions on how to sign in to your app using the SP-initiated flow.<br>The maximum description length is 2048 characters. This field is required for the SP flow.|
+
+`*` Required properties

packages/@okta/vuepress-site/docs/guides/update-oin-app/main/saml2/test-instance.md

@@ -0,0 +1,16 @@
+2. Specify the **Application label** and any integration properties required in the **General settings** tab.
+3. Click **Done**. The **Assignments** tab appears.
+   You can assign users to your integration later, see [Assign test users to your integration](#assign-test-users-to-your-integration-instance).
+4. Click the **Sign On** tab.
+5. Click **View SAML setup instructions** to open a new tab to your integration setup instructions. This is the customer configuration guide that you previously specified in the OIN Wizard.
+6. Follow the instructions in your guide to set up the SAML SSO integration on your app.
+    * Click **Copy** next to **Metadata URL** to copy the full SAML metadata URL required for the integration.
+    * To view specific SAML metadata details, click the **More details** arrow.
+7. Follow these steps if you have an Identity Engine Developer Edition org:
+   1. Click the **Sign On** tab, scroll to the **User authentication** section, and click **Edit**.
+   1. Select **Password only** from the **Authentication policy** dropdown menu.
+   [[style="list-style-type:lower-alpha"]]
+   1. Click **Save**.
+   > **Note:** Most recent Okta Developer Edition orgs are Identity Engine orgs. See [OIN Wizard authentication policy for testing](/docs/guides/submit-app-prereq/main/#oin-wizard-authentication-policy-for-testing).
+
+8. [Assign test users to your instance](#assign-test-users-to-your-integration-instance) before you start testing your SSO flows.