Access Settings

Access Settings allow administrators to control the entry points for new users on the Freedam platform. This interface centralizes how accounts are created, whether through direct invitations, open self-registration, or corporate Single Sign-On (SSO) providers.

By managing these settings, you can ensure that only authorized individuals gain access to your digital assets while automating the assignment of initial permissions for new members.

Page Overview

• Purpose: To define the security and onboarding rules for new user accounts.
• When to use it: Use this page during initial setup or when you need to change how users join the platform (e.g., switching from invitation-only to open registration).
• What you can do here:
  • Enable or disable user-to-user invitations.
  • Toggle public self-registration.
  • Require administrative approval (accreditation) for new sign-ups.
  • Restrict registration to specific corporate email domains.
  • Enable Single Sign-On (SSO) with Google, Microsoft, or both.
  • Set the default role assigned to every new user.

Page Layout

• Top bar: Displays the page title "Access Settings" and the Save Changes button.
• Main area: A centralized card containing a list of toggle switches and configuration fields for registration and authentication.

Who can use it

Access Settings can only be opened and changed by workspace administrators with the System Settings permission. Other team members will not see the page in the admin navigation.

Main Features

Registration Control

• What it's for: Determining if users can create their own accounts or if they must be invited.
• Typical use: Turn off self-registration if you want a private, invite-only environment.
• Result: The "Sign Up" option will appear or disappear from the login screen. When self-registration is off, anyone landing on the sign-up page who does not carry a valid invitation link is blocked with a clear message that registration is by invitation only.

Accreditation (Admin Approval)

• What it's for: Adding a manual review step for new users.
• Typical use: Enable this if you allow self-registration but want to verify each person's identity before they see any assets.
• Result: New users are redirected to a request-access form instead of the normal sign-up flow. Their submission lands in the User Requests queue, where administrators — or a dedicated accreditation reviewer group if one has been configured — approve or deny the applicant. Nobody sees any assets until they are approved.

Domain Restriction

• What it's for: Limiting access to specific organizations.
• Typical use: Enter your company domain (e.g., "company.com") to prevent anyone with a personal email (like Gmail or Yahoo) from registering.
• Result: Registration attempts from non-listed domains are blocked before the account is ever created. The same allowlist is also enforced for SSO sign-in, so a personal Gmail or Outlook.com account will be rejected even when the matching provider is turned on.

Single Sign-On (SSO)

Freedam supports two SSO providers, each with its own independent switch:

• Google — for Google Workspace and Gmail accounts.

• Microsoft — for Microsoft Entra ID (formerly Azure AD) work or school accounts, and personal Microsoft accounts.

• What it's for: Allowing users to log in with an account they already have, instead of creating another password.

• Typical use: Streamlining the login process for employees who already live in Google Workspace or Microsoft 365.

• Result: A "Continue with Google" and/or "Continue with Microsoft" button appears on the login page — one per enabled provider. If a provider's credentials have not been configured at the server level, its toggle stays disabled and the page will tell you so; no save is needed.

You can enable either provider on its own, or both at once. Turning one off does not affect the other, and users who already linked that provider simply lose it as a sign-in option — their account and assets are untouched.

Detailed Feature Documentation

Default Role Assignment

• Purpose: Automatically assigns a specific set of permissions to every new user the moment they join.
• Where to find it: At the bottom of the main settings list, look for Default role for new users.
• What you'll see: A dropdown menu showing all available system roles (e.g., Viewer, Editor).

The default role is applied automatically to anyone who self-registers and to users approved from the accreditation queue. Direct invitations can override this by specifying a different role on the invitation itself.

How to use it:

1. Locate the Default role for new users section.
2. Click the dropdown menu (currently showing the active role).
3. Select the desired role from the list.
4. Click Save Changes in the top bar.

Email Domain Allowlist

• Purpose: To restrict self-registration to specific verified domains.
• Where to find it: Look for the toggle Restrict registration to specific email domains.
• What you'll see: When toggled on, a field labeled Allowed email domains appears where you can enter domain names.

How to use it:

1. Switch the Restrict registration to specific email domains toggle to the "on" position.
2. In the Allowed email domains field, type a domain (e.g., acme.com).
3. Press Enter or Comma to save the tag.
4. Repeat for additional domains if necessary.
5. Click Save Changes.

Complete Workflows

Workflow: Setting up a Private Corporate Portal

• Goal: Ensure only employees with a company email can join, but require admin approval for extra security.
• Prerequisites: Administrator access.

Steps:

1. Navigate to Access Settings.
2. Switch Users can self-register to ON.
3. Switch Users need accreditation to ON.
4. Switch Restrict registration to specific email domains to ON.
5. In Allowed email domains, type your company domain and press Enter.
6. Select "Viewer" (or your preferred base role) in Default role for new users.
7. Click Save Changes.

• Expected result: Only users with your company email can sign up; they will remain "Pending" until you approve them, and they will start with "Viewer" permissions.

Workflow: Enabling SSO Login

• Goal: Allow users to bypass password creation by signing in with Google or Microsoft.
• Prerequisites: The chosen provider's OAuth credentials must be configured in the system environment.

Steps:

1. Locate the Google SSO or Microsoft SSO row — there is one per provider.
2. If the description invites you to allow users to sign in with that account, flip the switch to ON.
3. If the description mentions that the provider "is not configured," contact your system technical lead.
4. Repeat for the second provider if you want to offer both.
5. Click Save Changes.

• Expected result: The login screen will now display one authentication button per enabled provider.

Limits and guardrails

• Each allowed domain must be a valid, lowercase domain name (for example acme.com or team.acme.co.uk). Entries that are not real domain names are rejected with a friendly message when you try to save.
• When the domain restriction is turned on, you must provide at least one domain before you can save the page.
• Leading @ signs and mixed capitalisation are cleaned up automatically — @Company.COM becomes company.com — and duplicate entries are removed silently.
• Invitations always bypass the allowlist. This is intentional: it lets you onboard an outside contractor without having to add their personal domain for everyone.

What happens behind the scenes

• Every change made on this page is recorded in a setting change log with the administrator's name, the old value, the new value, their IP address, and the time of the change. The full history is available for compliance and auditing.
• Saving the page also refreshes the onboarding checklist so that newly completed steps (for example configuring an SSO provider) show as done for every administrator.
• When accreditation is enabled, a dedicated reviewer group — if one has been assigned under User Groups — receives the pending requests instead of the general administrator pool.
• New users who self-register (without an invitation) are still asked to verify their email address before they can sign in. Users who arrive through an invitation link are considered verified and skip this step.

Tips and Best Practices

• Accreditation Dependency: If you turn off "Users can self-register," the "Users need accreditation" setting will automatically be disabled, as invited users are typically considered pre-approved.
• Domain Formatting: You don't need to include the "@" symbol when entering allowed domains. The system will automatically clean entries like @company.com to company.com.
• Invitation Safety: Note that "Restrict registration to specific email domains" only applies to self-registration. If an admin or user sends a direct invitation, the recipient can join regardless of their email domain.

Troubleshooting

Issue: Cannot enable an SSO provider

• Symptoms: The switch for Google SSO or Microsoft SSO is greyed out and cannot be toggled.
• Cause: That provider's technical connection (OAuth Client ID and Secret) has not been set up in the server configuration. The two providers are configured independently, so one can be available while the other is not.
• Fix: Contact your IT department or system administrator to configure the environment variables for the provider you want to offer.

Issue: Microsoft users are asked for administrator approval

• Symptoms: A user signing in with a Microsoft work account sees a Microsoft consent screen saying approval from an administrator is required, and never reaches Freedam.
• Cause: This is a Microsoft policy, not a Freedam setting. Microsoft blocks end users from consenting to a multi-tenant application until its publisher has been verified.
• Fix: Your system technical lead needs to attach a verified publisher to the Freedam app registration in Microsoft Entra. Until then, an administrator of the user's own Microsoft tenant can grant consent on their behalf.

Issue: Save Changes fails with an error

• Symptoms: A red error message appears after clicking Save Changes.
• Cause: You likely enabled "Restrict registration to specific email domains" but did not provide any domains in the list.
• Fix: Add at least one valid domain to the Allowed email domains field before saving.
• Prevention: Always ensure the domain tags are visible in the input field before clicking save.