This page summarizes the main onboarding prerequisites for IQNECT: how users authenticate, what traffic flows IQNECT generates, when the relay tunnel should be enabled, and which domains need to be allowed for the product and support portal.
This guidance reflects the IQNECT 26.2.1 onboarding and connectivity model.
Authentication and authorization #
IQNECT uses Single Sign-on for end-user access. Your organization must have an SSO solution available before IQNECT can be rolled out. See SSO Introduction.
- Both SAML 2.0 and OIDC are supported.
- IQNECT has been validated with providers such as Okta, Microsoft, Google, and AWS Cognito.
- Depending on your rollout model, either all users from the identity provider can be allowed to access IQNECT or only a named subset of users.
For restricted rollouts, prepare the list of user SSO IDs or email addresses that should be granted access.
User access to connected-system data is handled separately from IQNECT sign-in. In general, IQNECT uses delegated authorization so that users access external-system data by connecting their own account, and IQNECT respects the permissions defined in that external system.
- Users sign in to IQNECT through organizational SSO.
- Users then connect their own account in each supported external system when delegated access is required.
- For indexing, IQNECT may also use a separate integration user configured for the connected system. That integration user is used for indexing workflows and does not replace end-user delegated access.
The exact delegated-authorization and integration-user setup depends on the connected system. See the individual setup guides for details.
Supported systems #
IQNECT can connect one or more engineering systems within your organization. Setup details are documented separately for each supported integration.
| System | Supported versions or deployment model | Setup guide |
|---|---|---|
| Codebeamer | 2.2, 2.3, 3.0, 3.1, 3.2 | Codebeamer setup |
| Windchill | 13.1 | Windchill setup |
| Jira | Jira Cloud | Jira Cloud integration |
Networking requirements #
For a tenant administrator, the main networking question is which outbound and inbound flows must be allowed for IQNECT to work in your environment. The answer depends on whether users are accessing IQNECT in the browser only, or whether IQNECT also needs to reach customer-hosted systems such as Codebeamer or Windchill.
Unless stated otherwise, IQNECT traffic uses HTTPS on port 443. When relay tunneling is enabled, the relay connection uses WSS to relay.iqnect.ai.
1. End-user browser access #
When a user accesses IQNECT directly or through a connected system where IQNECT is enabled, the user’s browser makes outgoing HTTPS requests to:
app.iqnect.aito load the IQNECT frontend application and related static assets.api.iqnect.aito call the IQNECT backend.- Your organization’s identity-provider domains as part of IQNECT SSO.
- Connected-system and identity-provider pages involved in delegated authorization, when IQNECT needs the user to authorize access to an external system.
This is the minimum traffic needed for normal IQNECT product usage. No additional external support-portal domains are required just to use IQNECT itself, whether in the admin UI or inside a connected system.
2. Customer-hosted systems using direct connectivity #
If IQNECT needs to connect directly to a customer-hosted system such as Codebeamer or Windchill, there are two sides to the traffic:
- Outgoing HTTPS from the customer-hosted server to IQNECT: the extension makes outbound requests to
api.iqnect.aifor backend API calls, indexing events, and status traffic, and toapp.iqnect.aiwhen it uploads larger payloads or loads frontend bootstrap assets from IQNECT. - Incoming HTTPS from IQNECT to the customer-hosted system: IQNECT reaches the connected system to read data, resolve permissions, refresh delegated tokens, and fetch content for indexing. This means the system base URL configured in IQNECT, and any customer-hosted identity-provider or authorization-server endpoints used for delegated authorization or token refresh, must be reachable from IQNECT.
3. Customer-hosted systems using relay tunneling #
Enable relay tunneling when the connected system is not directly reachable from IQNECT, for example because it is on a private network or behind a firewall. Relay tunneling can also be enabled when you want to force backend traffic through the relay even if direct connectivity is possible.
When relay tunneling is enabled:
- The customer-hosted extension opens an outgoing WSS connection to
relay.iqnect.ai. - IQNECT sends backend traffic through that relay path instead of connecting directly to the customer-hosted system from outside the customer network.
- Outbound access to
relay.iqnect.aimust be allowed from the customer-hosted server.
For detailed tunnel setup guidance, see Configure tunneling for external system connections.
4. Support portal access #
IQNECT support now runs through Zoho Desk at https://support.iqnox.com/portal/en/kb. If end users need access to the support portal, also allow outgoing HTTPS access to:
support.iqnox.comstatic.zohocdn.comcontacts.zoho.comwebfonts.zoho.com
What else should be prepared? #
In addition to SSO and firewall rules, most onboarding efforts should confirm the following early:
- The fully qualified base URLs of all connected systems are known.
- The delegated authorization approach for each connected system has been selected and documented.
- The integration user for indexing has been identified for each connected system and granted the correct access.
- The expected direct-connect or relay-connect model has been decided for each connected system.
- The rollout plan is clear about whether IQNECT should be available to all SSO users or only a restricted allowlist.
