Skip to main content

Manage customer access

Beta Feature

The Enterprise Portal is Beta. Features described on this page are subject to change. Some capabilities might require additional access.

This topic describes how to give customers access to the new Enterprise Portal, including moving customers from the Classic Enterprise Portal or the Download Portal, and how to manage their portal users from the Vendor Portal.

Give customers access to the new Enterprise Portal​

Teams using only the new Enterprise Portal​

All customers can access the portal. You do not need an app-level or per-customer enable toggle.

Teams using both portals​

If your team also uses the Classic Enterprise Portal or the Download Portal, you can adopt the new Enterprise Portal incrementally. Run the portals side by side, then move customers over individually or all together. All portals share the same backend, so customer data, licenses, and instance information are consistent across them.

Portal coexistence​

You can run the Download Portal, the Classic Enterprise Portal, and the new Enterprise Portal side by side, with different customers on each, indefinitely. Treat this as an ongoing state, not only a step toward a full migration.

For a single customer, though, these are alternatives, not concurrent options. Turning on Enterprise Portal access for a customer moves that customer off the Download Portal onto whichever portal version their Portal Version setting selects.

Plan for the address change​

Moving a customer to the new Enterprise Portal changes the address they use to reach it. The Classic Enterprise Portal and Download Portal run at get.replicated.com/{appSlug} or your custom domain for those portals. The new Enterprise Portal runs at {appSlug}.enterpriseportal.app or a separate custom domain. A single custom domain can't serve both.

Before you move a customer, confirm they can reach the new address. Customers in restricted networks often allowlist the portal address. For them, an unannounced move can make the portal unreachable. Tell customers the new hostname ahead of time, and ask them to allowlist it by hostname, not IP address. For more information about custom domains, see Configure a custom domain.

Move customers​

Moving a customer to the new Enterprise Portal requires a Vendor Portal team admin. A content repo must be linked before you can move customers.

  1. Set up the new Enterprise Portal. In the Vendor Portal, go to Enterprise Portal and select New Portal. Customers continue using their current portal until you move them.
  2. Connect a content repo. Follow the steps in Connect a Git repo. Connecting a repo has no effect on any customer's portal version. No customer sees the new portal until you explicitly move them.
  3. Test it yourself. Use the local CLI preview (replicated enterprise-portal preview) or open the new portal URL directly to see how your content renders. You can also use Login as customer on a customer's Enterprise Portal access tab. For more information, see Test and preview the Enterprise Portal.
  4. Move individual customers. On the customer's Enterprise Portal access tab, turn on Enable Enterprise Portal for this customer. If your team also has the Classic Enterprise Portal, a Portal Version control appears. Set it to Use new Enterprise Portal for this customer, or the customer goes to Classic. The control also appears when access is on through the app-level Enable Enterprise Portal for all customers override.
  5. Move customers back if needed. On teams with the Classic Enterprise Portal, set Portal Version back to Classic at any time. The customer immediately returns to the Classic experience.
  6. Give every customer Enterprise Portal access at once, if you don't need a gradual rollout. On Enterprise Portal > Customer Access, turn on Enable Enterprise Portal for all customers. Every customer moves off the Download Portal immediately. On teams with the Download Portal and the new Enterprise Portal, every customer goes to the new Enterprise Portal, including KOTS and kURL customers. On teams that also have the Classic Enterprise Portal, each customer goes to the portal their Portal Version setting selects, and a customer whose Portal Version isn't set to Use new Enterprise Portal for this customer goes to Classic, which doesn't support KOTS or kURL. Set Portal Version for those KOTS and kURL customers before you turn this on. The setting doesn't change any customer's individual access or Portal Version setting, and turning it back off returns each customer to their individual access setting.

To automate these steps with the Vendor API, see Customer access in Headless Enterprise Portal: Vendor API.

Vendor Portal view and customer portal version​

When both portals are running for your team, New Portal and Classic Portal buttons appear at the top of the main Enterprise Portal settings area in the Vendor Portal. These buttons switch which version of the Enterprise Portal settings you see and configure as a vendor. They have no effect on which portal any customer sees. To change a specific customer's portal, use the Portal Version setting on that customer's Enterprise Portal access tab.

KOTS and kURL customers​

The new Enterprise Portal supports KOTS and kURL customers, with some differences from Helm and Embedded Cluster customers. KOTS and kURL application upgrades are performed in the Admin Console, and their instance cards provide target-aware guidance plus application bundle downloads for entitled air gap customers. For details on what these customers see, including current limitations, see KOTS and kURL instances in Log in to and use the Enterprise Portal.

Moving a KOTS or kURL customer works the same way as moving a Helm or Embedded Cluster customer. The app-level Enable Enterprise Portal for all customers option applies to KOTS and kURL customers too.

Most KOTS and kURL customers don't have Enterprise Portal access enabled yet, since they've been using the Download Portal. On teams with only the Download Portal and the new Enterprise Portal, turning on Enable Enterprise Portal for this customer moves the customer to the new Enterprise Portal. On teams that also have the Classic Enterprise Portal, turning on access makes the Portal Version control appear. The Classic Enterprise Portal does not support KOTS or kURL, so leaving Portal Version at its default does not give the customer a working portal. Set it to Use new Enterprise Portal for this customer explicitly.

To automate this instead of using the Vendor Portal UI, use Patch a customer with is_enterprise_portal_enabled: true to grant access. On teams that also have the Classic Enterprise Portal, then use Update Enterprise Portal settings with portalVersion: "v2" to select the new Enterprise Portal.

If you also want this customer to see Security Center, enable access for the customer or for all customers at the app level. Security Center access is separate from Portal Version. For a KOTS or kURL customer, Security Center shows an explanatory message instead of security data until they also have a Helm or Embedded Cluster instance. For more information, see Enable Security Center access in Enable Customer Access to Security Information.

Invite users​

To invite a customer's end user to the portal:

  1. Go to Customers > [Customer Name] > Enterprise Portal access
  2. In the Customer Users section, click + Invite user
  3. Enter the user's email address and click Send invite
  4. The user receives an email with an invitation link to activate their account

You can also enable Automatically invite customer email to Enterprise Portal on creation so that every new customer with an email address receives an invite automatically.

For teams using only the new Enterprise Portal, go to Enterprise Portal > Customer Access. In the Customer invitations section, enable automatic invitations. On teams using both portals, automatic invitations require the app-level Enable Enterprise Portal for all customers setting.

On teams using both portals, the customer creation screen includes a Use new Enterprise Portal for this customer checkbox. When checked, the customer is enrolled in the new Enterprise Portal and any auto-invite email points them to the new portal URL instead of Classic. This checkbox is only visible to team admins. When unchecked or not visible, new customers default to Classic.

Access to multiple channels​

A license is assigned to a single channel. To give one end user access to releases from more than one channel (for example, a stable channel for production and an alpha channel for a test environment), create a separate customer for each channel, each with a license on the intended channel.

To present these as a single login, invite the same email address to each customer. The user logs in once and switches between the customers using the team switcher in the portal. For the customer-side experience, see Access with multiple teams.

Because each customer appears to the end user as a separate team, name your customers descriptively (for example, Customer A - Stable and Customer A - Alpha) so users can tell their environments apart.

note

Inviting different email addresses to each customer creates separate logins with no team switcher. Use the same email address for each customer to give one person a unified experience.

Remove users​

To remove a user from a customer's portal team:

  1. Go to Customers > [Customer Name] > Enterprise Portal access
  2. In the Customer Users table, click the menu icon (...) next to the user
  3. Select Remove user

Domain restrictions​

Restrict which email domains can be invited to a customer's portal:

  1. Go to Customers > [Customer Name] > Enterprise Portal access
  2. In the Authentication section, enable Domain Restrictions
  3. Add one or more allowed email domains (e.g., acme.com)

Only users with email addresses matching an allowed domain can be invited. This prevents accidental invitations to personal email addresses or unauthorized domains. The allowed domain list also governs SAML logins. For more information, see Just-in-time user provisioning.

SAML authentication​

Allow customers to use their corporate identity provider for portal login. SAML authentication is enabled for all teams by default, so you do not need to request access to it.

  1. Go to Customers > [Customer Name] > Enterprise Portal access
  2. In the Authentication section, enable SAML Authentication
  3. Users on the customer's team can then configure their IdP details (metadata URL, certificates) from the Enterprise Portal's team settings

Just-in-time user provisioning​

SAML supports just-in-time (JIT) user provisioning, which creates a portal account the first time that a user logs in with SAML. Whether the user also needs a pending invitation depends on where the login starts:

  • IdP-initiated: the user starts at the identity provider. The portal creates the account with no invitation
  • Portal-initiated: the user starts at the portal login page. The portal creates the account only if that email address already has a pending invitation, and otherwise returns the saml_invite_required error

When Domain Restrictions are enabled, the allowed domain list also governs SAML. The portal does not create an account for a user whose email domain is absent from the list, and returns the domain_not_allowed error instead. Two details of this check matter in practice:

  • It runs before the invitation check, so a new user from a domain that is not allowed sees domain_not_allowed even when they also lack an invitation
  • It applies only when the portal creates the account. Removing a domain from the list does not lock out users who were already provisioned from it

For the full set of SAML login errors and how to resolve them, see SAML login errors in Troubleshoot the Enterprise Portal.

Service accounts​

Service accounts provide programmatic access to the Enterprise Portal (e.g., for CI/CD pipelines pulling install commands or registry credentials).

  • View and manage service accounts on the customer's Enterprise Portal access tab under Customer Service Accounts
  • Service accounts are created by users on the customer's team from Team Settings > Service Accounts in the Enterprise Portal, automatically when a customer starts a new installation from the portal, and when you create install options through the Vendor API
  • A service account can hold more than one token. Users on the customer's team create additional tokens and revoke individual tokens from Team Settings > Service Accounts. Use an additional token to give a CI system access to an existing installation without changing the token that the installation runs with. For more information, see Manage service account tokens in Log in to and use the Enterprise Portal.
  • Vendors can revoke service accounts from the Vendor Portal. Revoking a service account stops all of its tokens.

Emails​

For information about configuring a custom email sender, customizing email templates, sending release notifications, and viewing email delivery history, see Customize customer emails.

On this page