Skip to main content
Version: 2026.05

Configure partner sharing (Secure Connections)

Secure Connections let you share individual models and artifacts with a partner organization through authenticated, encrypted channels. An outbound Sending Connection pushes Resources you own to a partner; an inbound Receiving Connection accepts Resources a partner pushes to you. Systems cannot be shared through a Secure Connection as a whole.

This tutorial is for organization administrators configuring partner sharing in the Istari Digital web app. You set up Sending and Receiving Connections, hand off credentials to a partner admin, and verify that a shared model syncs. IT must enable partner sharing on your deployment first — you confirm it is available, then complete every connection step in the browser.

By the end you will:

  • Create a Sending Connection with permitted control tags (when your program uses them)
  • Exchange Shared ID and Shared Secret credentials with the partner admin
  • Optionally create a Receiving Connection if your org also accepts inbound partner data
  • Confirm sync health from Sync Status and verify end-user sharing works

Time: ~30 minutes (partner coordination and first sync may add wait time).

Prerequisites

  • Organization administrator access — the Admin shield in the sidebar footer. See the Administrator Guide.

  • Partner sharing enabled on your deploymentSecure Connections must appear in the admin hub before you start. IT handles installation and storage setup on the cluster; your job is to confirm the feature is ready in the web app:

    1. Open AdminSecure Connections. The page loads with Sending Connections and Receiving Connections tabs.
    2. Open Add Secure Connection and check the dialog for your role:
      • Sending orgAdd Sending Connection lists at least one Outbox in the dropdown. An outbox is the staging location for Resources leaving your registry toward a partner. Each sending connection uses one outbox.
      • Receiving orgAdd Receiving Connection lists at least one Inbox in the dropdown. An inbox is where inbound partner Resources land before they appear in your registry. Each receiving connection uses one inbox.

    Ask IT which outbox or inbox name to select for your partner — names differ by environment. If Secure Connections is missing or the dropdown is empty, hand off to IT using Secure Connection Service Setup and wait before continuing.

  • A partner registry — another Istari Digital deployment whose admin can create the matching connection on their side. Agree in advance which org is sending and which is receiving for this exercise.

  • A tutorial user with Editor access on a test model — pick a colleague (or a second account you control) who has Editor or above on the model. If you completed Onboard your organization, reuse that tutorial user.

  • A test model — any small model on Files that the tutorial user can share. Keep it under the ~2 GB per-file transfer limit. The UAS spreadsheet from Web app 101 works well.


Step 1 — Open Secure Connections

  1. Sign in to the Istari Digital web app as an organization administrator.
  2. Click Admin in the sidebar footer (or go to /admin).
  3. Select Secure Connections in the admin hub (or go to /admin/secure-connections).

The page opens on Sending Connections by default. Two tabs divide outbound and inbound configuration:

  • Sending Connections — connections that push your Resources to partners.
  • Receiving Connections — connections that accept Resources from partners.

Use the Active / All toggle (top-right) to include archived connections. For this tutorial, keep Active selected.

See Secure Connections in the Administrator Guide for column definitions and reference detail.


Step 2 — Agree roles with the partner admin

Partner sharing requires a matched pair of connections — one sending, one receiving — that share the same Shared ID and Shared Secret.

Your org's roleYou createPartner admin createsCredentials flow
Sending (this tutorial's primary path)Sending ConnectionReceiving ConnectionYou generate ID + secret; partner enters them on their side
ReceivingReceiving ConnectionSending ConnectionPartner generates ID + secret; you enter them on your side

Sending org goes first. The sending admin creates the connection and copies the final Shared ID (including any auto-appended suffix) and Shared Secret to the receiving admin through your organization's approved secure channel.

Confirm each registry's outbox or inbox dropdown is populated (see Prerequisites) before either admin creates a connection in Steps 3 and 4.


Step 3 — Create a Sending Connection

Complete this step on the registry that sends data to the partner.

  1. On Sending Connections, click Add Secure ConnectionAdd Sending Connection.
  2. Fill in Name (for example, Partner — Acme Corp) and optionally Description.
  3. Select an Outbox from the dropdown (see Prerequisites). If that outbox is already bound to another sending connection, a warning appears; pick a different outbox or ask IT to add another.
  4. Enter a Shared ID base (letters, digits, ., -, _ only — no spaces). With Append unique suffix to Shared ID checked (default), the platform appends a random suffix on submit so the final ID is globally unique.
  5. Enter and confirm a Shared Secret. Treat it like a password — it is never retrievable after you close the credentials screen.
  6. Optionally set Permitted Control Tags — when you select tags, only Resources carrying all of those tags are eligible to sync. Leave empty to allow any tag (or when your program does not use control tags yet).
  7. If infosec is enabled on your deployment, optionally set Permitted Infosec Level — the maximum classification allowed through this connection.
  8. Check the certification box confirming this connection will share data with an external organization.
  9. Click Create.

A credentials screen shows the final Shared ID and a masked Shared Secret. Copy both before closing — the secret is shown only once.

Send the credentials to the partner admin securely. They need the exact Shared ID string (suffix included) and the Shared Secret to create their receiving connection.


Step 4 — Partner creates the Receiving Connection

The partner admin completes this step on their registry. Include these instructions in your handoff.

  1. AdminSecure ConnectionsReceiving ConnectionsAdd Secure ConnectionAdd Receiving Connection.
  2. Fill in Name and optionally Description.
  3. Select an Inbox from the dropdown (see Prerequisites).
  4. Paste the Shared ID and Shared Secret from your sending connection (Step 3).
  5. Click Create.

The creating user becomes the first Receiving Connection Owner and can see synced Resources that arrive through this connection.

If your org is both sides (for example, a paired dev/stage test), switch to the receiving registry and run the steps above yourself using the credentials you generated in Step 3.


Step 5 — Configure receiving-side access (receiving admins)

Skip this section if your org is only the sending side. Receiving admins complete it after Step 4.

Assign owners

Owners of a receiving connection receive view access to every Resource that syncs through it.

  1. On Receiving Connections, open the row menu → Edit owners (or click the Owners cell).
  2. Search for users who should see inbound partner Resources and add them.
  3. Click Update.

Owners still need matching control tags and infosec levels on their user accounts to see classified or tagged Resources — assign those on AdminUsers when your program requires them. See Manage Owners in the Administrator Guide.

Map control tags (when orgs use different tag names)

If the sending org applies control tags your registry does not recognize, sync fails until you add transform rules on the receiving connection.

  1. On Receiving Connections, click Transform Config on the connection row.
  2. Read the helper text about the shared cybersecurity responsibility model.
  3. If a warning lists uncovered incoming tags, add a Map Control Tag rule for each:
    • Predicate — the tag name sent by the partner.
    • Value — an equivalent tag on your registry (create it first on AdminControl Tags if needed).
    • Description — why the mapping exists.
  4. Click Save.

Rules run in fixed order: removes, then maps, then adds. See Transform Config for all rule types.


Step 6 — Share a model with the partner (verification)

Confirm the end-user path works. Sign in as your tutorial user (Editor or above on the test model), not your org admin account.

  1. Open the test model on Files.
  2. Click Share (share icon) in the resource's action bar.
  3. The Share <filename> dialog opens in user-sharing mode by default. Click Share with external connection (globe icon, top-right of the dialog).
  4. In Add organization, search for and click the sending connection you created in Step 3.
  5. The connection appears under Connections with access (N). Review the amber certification box and check Confirm External Organization(s) will gain access to this model.
  6. Click Update. A toast confirms External connection sharing updated.

The model's details pane now lists the partner under Connections with Access.

On the receiving registry, wait one to two minutes, then confirm:

  • The model appears for a Receiving Connection Owner who holds any required control tags and infosec level.
  • On Receiving Connections, the connection's sync status icon shows success (green check).

If the model does not appear, open Sync Status (next step) or see Debugging Secure Connections.

Optional follow-up: Upload a new revision of the shared model as the tutorial user. The platform pushes the revision to the partner automatically and shows a certification checkbox in the Upload Version dialog — see Actions that automatically push data to partners.


Step 7 — Monitor sync status

  1. Return to AdminSecure Connections as an organization administrator.
  2. On the relevant tab (Sending or Receiving), click the sync status icon on the connection row.

The Sync Status page lists recent sync events, newest first. Each row shows severity, timestamp, and a message preview.

  • Click a row (or its chevron) to expand per-resource details. Copy a resource ID from the expanded view when you need it for support.
  • Use With updates to filter to sync events that changed Resources.
  • The page auto-refreshes about every minute while open.
IconMeaning
DashedNo sync activity yet
Green checkLast sync succeeded
Yellow warningLast sync completed with partial errors
Red XLast sync failed

Common first-sync failures:

  • Secret mismatch — receiving Shared Secret does not match the sending side. On the receiving connection, use Reset Secret (edit dialog) to align with the sender, then wait for the next sync cycle.
  • Uncovered control tags — add Map Control Tag rules on the receiving connection (Step 5).
  • Infosec or tag limits — the model's classification or tags exceed the sending connection's permitted limits. Adjust the connection or the model's tags/level. See Cases where a resource is automatically unshared.

What you set up

PieceWhy it matters
Sending ConnectionLets Editors share models and artifacts with a named partner org through Share with external connection.
Credential handoffShared ID + Shared Secret pair the two registries; mismatched secrets block all sync.
Receiving Connection + ownersDelivers inbound partner Resources to the right users on your registry.
Transform rulesMaps partner control tags to your local tags so classified programs stay consistent.
Verified share + sync statusProves the full path works before engineers follow the Secure Connections user guide.

What's next

  • Secure Connections (User Guide) — How Editors share models and artifacts, handle certification prompts, and understand automatic unshare rules.
  • Secure Connections (Administrator Guide) — Reference for editing connections, inline control-tag edits, archiving, and transform rules.
  • Establish classification and control tags — Planned org-admin tutorial for infosec levels and control tags when your program requires them before partner exchange.
  • Debugging Secure Connections — Resolve sync failures and authentication errors (escalate infrastructure issues to IT).