Skip to main content

Impact of Workspace Security Policies on Users

Invariant Technology provides several workspace-level security policies that directly influence user access, collaboration, and the overall security posture. These settings are particularly impactful when your workspace owns a domain. Understanding their effects is key to tailoring Invariant to your organization's needs.

Default Login Settings

  • What it controls: The primary method(s) users employ to sign in and whether traditional password-based login is permitted.
  • Impact on Users:
    • Setting OIDC as Default: When users navigate to the Invariant login page, they might be immediately directed to your OIDC provider or see it as the primary option. This streamlines the SSO experience.
    • Disabling Password Sign-In:
      • Effect: This is a significant security enhancement. If enabled, users cannot log in using an Invariant-specific password. They must authenticate via OIDC.
      • User Experience: Users who previously used passwords will need to use the OIDC flow. New users will only have the OIDC option. This ensures all access (for domain users) is channeled through your centrally managed IdP.
      • Consideration: Ensure your OIDC integration is fully functional and all relevant users are provisioned in your IdP before disabling password sign-in to avoid locking users out.

Allow Managed Users to Join Other Workspaces

  • What it controls: Whether users belonging to your managed Invariant domain (e.g., user@yourcompany.invariant.tech) can be members of Invariant workspaces outside your own organization's control.
  • Impact on Users:
    • If Allowed: Your users have the flexibility to collaborate with external partners or join other Invariant instances if invited. This can be beneficial for cross-organizational projects.
    • If Disallowed: This restricts your domain users solely to your organization's Invariant workspace(s).
      • Security Benefit: It provides tighter control over where your employees are active and potentially accessing or sharing data via Invariant.
      • User Experience: Users from your domain will be unable to accept invitations to external Invariant workspaces, which might limit their collaboration capabilities if such external access is needed.

Allow New External Collaborators

  • What it controls: Whether new users from outside your managed domain can be invited to join your workspace.
  • Impact on Users and Collaboration:
    • If Allowed: Your administrators and users (depending on their permissions) can invite external parties (consultants, partners, clients) to collaborate within your Invariant workspace. This fosters broader collaboration.
    • If Disallowed:
      • Security Benefit: This significantly restricts the ability to bring in external individuals, potentially reducing the risk of unauthorized access or data exposure through third parties. Your workspace becomes more insular.
      • User Experience/Collaboration: It will prevent the onboarding of new external collaborators. If you need to work with external entities within Invariant, this setting would need to be enabled (at least temporarily, if your policy is strict).
    • Key Clarification: This setting only affects new external invitations. Existing external collaborators who are already members of your workspace will retain their access even if you disallow new ones. It's about controlling future external additions, not retroactively removing current ones.

By carefully configuring these security policies, administrators can strike the right balance between security, control, and collaborative flexibility for their Invariant Technology workspace users.