pulling v17 content out

Author: mmcallister

docs/pages/enroll-resources/application-access/okta/sync-scim.mdx

@@ -147,53 +147,6 @@ The synchronizer will create the following resources for each matched group or a
 It should be noted that the Access List sync waits until the Okta groups and Okta applications
 has finished syncing as Teleport resources, so it may not start synchronizing immediately on startup.
 
-### Handling nested Access Lists
-
-#### Synchronization from Teleport to Okta
-
-Teleport supports nested Access Lists, where an Access List can include other Access Lists as members,
-creating a hierarchical structure. However, Okta does not support nested groups.
-To accommodate this limitation, the synchronizer flattens nested Access Lists when synchronizing from Teleport to Okta.
-
-Members in Access Lists, from all levels of nesting, are aggregated into a single, flat list of members when
-synchronized to Okta. This ensures that all users who should have access according to the Teleport hierarchy
-are included in the corresponding Okta group or application.
-
-**Example**:
-  - **Teleport Structure**:
-    - **Access List A**:
-      - Members: User1
-      - Nested Members: Access List B
-    - **Access List B**:
-      - Members: User2, User3
-  - **Okta Representation**:
-    - Group/Application for Access List A:
-      - Members: User1, User2, User3
-
-By flattening the Teleport hierarchy, all users receive the permissions associated with the root-level Access List in Okta.
-
-#### Synchronization from Okta to Teleport
-
-When synchronizing from Okta to Teleport, the synchronizer handles the flattened structure from Okta
-by attempting to map it back to the Teleport hierarchy:
-
-- **Comparing with Teleport Hierarchy**: The flattened list of members from Okta is compared against the existing
-Access List hierarchy in Teleport.
-- **Adding New Members**:
-  - **New Users**: If there are new users added in Okta that are not present in the Teleport Identity Governance Access List hierarchy,
-  these users are added as members at the root-level Access List in Teleport.
-  - **Maintaining Hierarchy**: This approach maintains the hierarchical structure within Teleport while ensuring
-  that access changes made in Okta are reflected appropriately.
-- **Example**:
-  - **Okta Group/Application for Access List A**:
-    - Members: User1, User2, User3, User4 (User4 is a new member added in Okta)
-  - **Teleport Update**:
-    - **Access List A**:
-      - Members: User1, User4
-      - Nested Members: Access List B
-    - **Access List B**:
-      - Members: User2, User3
-
 #### Deletion of Access Lists
 
 Access Lists synchronized from Okta will automatically be deleted when there are no members assigned to them in