What changed

Every content update is versioned. Select a version to compare it with the one before.

Version 10 → 11

Update

Two new lessons: planning the installation with the customer (installer commands, installation code or offline bundle, PoC or production, what the customer prepares), and groups, sign-in policies and external identity providers. The knowledge check has three new questions. Diagrams were added to the new lessons.

2 lessons updatedduration

Content update. Enrolled learners were notified.

Duration changed from 23 to 24 minutes.

Planning the installation with the customer

An installation day goes well when the questions were asked a week earlier. This lesson is the checklist a partner walks through with the customer before anyone touches the server. ### What the installer is `monofor` is one Linux binary. It prepares the customer's server and deploys Monosign as Docker Swarm stacks from a single validated YAML file. It has four commands: | Command | What it does | | --- | --- | | `monofor check` | Checks the server and its surroundings. It changes nothing. | | `monofor install` | Deploys Monosign. | | `monofor status` | Shows the health of the installation. It is read-only. | | `monofor cert install` | Installs a certificate and its key on a system that is already installed. | Run `check` first and fix what it reports. When it says the server is ready, run `install`. ### Two ways to start - **With an installation code.** This is the usual start since v2026.10: `monofor install --code <CODE>`. The code comes from your Monofor contact and carries the settings of that installation. `monofor check --code <CODE>` tests the server without using the code up. - **With an offline bundle.** For a server in an isolated network with no internet access: `monofor install --offline`. How you start has nothing to do with the database. The deploy type decides that. ### PoC or production | `deployType` | Database | Use it for | | --- | --- | --- | | `poc` | A PostgreSQL container that the installer runs itself | Trials and labs | | `production` | An external PostgreSQL or Microsoft SQL Server database. The installer runs no database container. | Real customers | ### What the customer must prepare The installer checks these three things, but it does not do them: - **DNS records** for the Monosign host names. - **Firewall ports** between the users, the server and the database. - **The external database** of a production installation: created, empty and reachable from the server. The tool also deploys Monosign only. Monopam and Monosync are installed separately, even when the customer bought all three. ::diagram msgs-install-plan ### A worked example A partner installs Monosign for a hospital. The server has no internet access, and the hospital's database team runs Microsoft SQL Server. The plan the partner sends a week ahead: 1. Deploy type `production`, with an empty SQL Server database prepared by the database team. 2. DNS records for the host names, requested from the network team. 3. The offline bundle copied to the server. 4. `monofor check --offline` until it reports that the server is ready, then `monofor install --offline`. > Tip: Send the customer the list of DNS names, ports and database requirements well before the installation day. The installer cannot fix a missing DNS record or a database that is not there; it can only tell you.

Groups, sign-in policies and external identity providers

Three questions come up in almost every first project, right after the first application works: who belongs to which group, when should a sign-in ask for more proof, and can people sign in with an account they already have somewhere else? ### Groups, and who gets an application Groups live under Directory → `Groups`. Members get in in one of two ways: - **By hand**: on a user's `Groups` tab, with `Assign New Group`. - **By rule**: a rule under Workflows → `Automation` with a condition such as `Department` equals `Sales` and the action `Assign group(s)`. The rule also covers people hired later. With `Remove access if rule no longer matches` on, it takes the group away again when someone moves to another department. A group does not fill itself: no group type carries its own membership condition. When a customer asks for "a group of everyone in Sales", the answer is a group plus an Automation rule. Putting people in a group does not open an application for them either. An application is opened by an **assignment**: `Assign a User` on the application's `Assignments` tab, or the action `Assign application(s)` in an Automation rule. | The customer says | You configure | | --- | --- | | "Everyone in Sales belongs to this group" | An Automation rule with `Assign group(s)` | | "Everyone in Sales gets the CRM" | An Automation rule with `Assign application(s)` | | "These three people test the new application" | `Assign a User` on the application | ### Asking for more proof only from the people who need it A policy of type `Authentication` under Security → `Policies` has two parts. The `Scope` says whom it applies to: a rule built from conditions about the user, for example membership of a group. The flow on the `Actions` tab says what the sign-in must contain, for example a second factor after the password. Asking for more only when a condition matches is what **conditional access** means, and this is where you configure it in Monosign. Each policy also has a `Priority` from 1 to 10, an optional `Start Date` and `End Date`, and an `Enabled` switch, so you can prepare a policy today and let it take effect next Monday. Example: a customer wants a second factor for the finance team first, before the whole company. You create one `Authentication` policy, scope it to the group `Finance` and add a second factor step to its flow. Everyone else signs in as before. Widening the rollout later means widening the scope, not rebuilding the policy. ::diagram msgs-policy-scope ### Signing in with an account from somewhere else Under Identity → `Providers` you define **external identity providers** that Monosign trusts for sign-in. If a customer's staff already sign in with Microsoft Entra, Entra becomes such a provider: the user is sent to Entra, signs in there and comes back to Monosign already verified. Providers connect over SAML 2.0, OpenID Connect or WS-Federation, and templates exist for common ones such as Microsoft Entra, Google and Okta. Routing rules decide who is sent where, for example everyone whose e-mail address ends in the partner's domain. On the way back, Monosign matches the person to an existing user. A user who does not exist yet is created only when just-in-time provisioning is turned on for that provider. Do not confuse the two directions: | Situation | Who is the identity provider | | --- | --- | | The CRM lets people in because Monosign vouches for them | Monosign | | Monosign lets people in because Entra vouches for them | Entra, and Monosign is the relying side | > Tip: Before you enable a policy that affects everyone, keep one administrator account outside its scope, so that a mistake in the policy cannot lock every administrator out.