Set up sign-in

The Authentication providers screen sets how people sign in to Portail ZAPP: with email and password, with Microsoft 365, Google or another identity provider, with or without open registration. The Access requests screen handles people who showed up without an account. Both screens are reserved for administrators: Administration › Users & access › Authentication › Providers and › Pending requests.

Password rules, lockout and two-factor authentication (mandatory for every account or for administrators only) are set elsewhere: see the "Secure sign-in" page.

Authentication providers

Changes take effect as soon as you click Save, without a restart. Secrets are never shown again: the field says "Configured" or "Not configured", and a field left empty keeps the saved value.

Form sign-in allows signing in with an email and a password. When unticked, password sign-in is refused by the server, not just hidden: the form disappears from the sign-in page, a sign-in through the API with a password is refused, forgotten-password requests no longer send a link (a link already received no longer works) and self-registration is closed. Only untick it if another provider (Microsoft 365, Google…) is in use; the screen warns you if no sign-in method is enabled.

If the identity provider goes down while form sign-in is unticked, the server administrator can reopen password sign-in without the screen: set the variable Auth__Providers__Form__ForceEnabled=true in the server configuration and restart the application. While it is set, the screen says so and every password sign-in is logged; remove it once the incident is over.

Self-service registration

When ticked, Self-service registration lets a visitor create their own account, with email and password. The account is only created once the email address is verified: the link sent is valid for 24 hours.

It also applies to identity providers: a person without an account who clicks "Continue with Google" (or Microsoft, or another provider) creates their account self-service, without approval. Their address is verified (by the provider, or by the code sent by Portail ZAPP), they accept the legal texts and can correct their first and last name; the account gets the same group as through the form and the person comes back to the page they came from. An address already used by another account is refused without further detail.

Group code assigned to the created account: the account is added to this group. The group must exist, be active, not be synchronized (for example with organizations) and grant no administration rights: ADMINS, DEVS and any group with access to an administration screen are refused, because anyone could register into it. A refused group is not saved (a message explains why); if the setting was already in place, the account is created without a group and the screen says so.
Legal texts to be accepted: a comma-separated code:version or code:version:address list. The registration form shows one required checkbox per text, with a link if an address is given. The address must start with http://, https:// or /; otherwise nothing is saved. Each checkbox label comes from the translations (key auth.register.legal.<code>).

Human verification (public forms)

Human verification of public forms is no longer set here: this section shows a Human verification link to the dedicated screen (when that module is active). The provider, keys and protected forms are described in the page "Set up human verification".

Identity providers (OpenID Connect)

This section lists the providers used to sign in with an external account: Microsoft 365, Google Workspace, or any OpenID Connect provider (Okta, Keycloak, Authentik…). Each active provider adds a "Continue with …" button on the sign-in page. Changes apply immediately, without a restart.

To add one, click Add and choose the type, then fill in:

the display name shown on the button and the code (letters and digits, permanent: it can no longer be changed);
for Microsoft 365: the Tenant ID — preferably the GUID shown in Entra ID, needed to link an existing account by its email address;
for Google Workspace: the allowed domains (for example example.com); only accounts of these domains with a verified address are accepted. A personal Gmail account is accepted only if you tick Accept personal Google accounts (gmail.com); a Workspace account of another domain is always refused;
for Microsoft (personal account): nothing but the Client ID and the secret. This type accepts personal Microsoft accounts (outlook.com, hotmail.com, live.com…) and only them; it comes in addition to Microsoft 365, which stays limited to your tenant. At Microsoft, the application must accept "personal Microsoft accounts";
for an OpenID Connect provider: the authority (HTTPS address of the provider), the scopes and, if needed, the email and name claims;
the Client ID and Client Secret of the application registered at the provider. The secret is stored in the secrets vault and never shown again; a field left empty keeps the saved secret.

Register at the provider the redirect address shown on the page (your instance address followed by /auth/login/<code>/callback).

A person who signs in through a provider:

finds their account if it is linked to this provider — by their identity at the provider, never by their email address alone;
never opens a local account, an AD account or another provider's account, even with the same email address;
otherwise is refused, unless Self-registration is active (below).

As soon as an account is linked to a provider, its directory (authority or tenant) can no longer change and it can no longer be deleted: disable it, or create another one for another directory.

Personal accounts (Google, Microsoft) — for requesters without a company directory:

when the provider does not guarantee the email address (personal Microsoft account, some OpenID Connect providers), Portail ZAPP sends a six-digit code to the address before linking an account or creating a registration. The code is valid for 10 minutes, 5 attempts at most; a new one can be requested, within a few sends per hour. The email text is edited in Templates (template "Authentication - Address verification code");
a personal account is never created on its own: it links to an account you created (same provider, same address), goes through an access request (Self-registration, below) or, if Self-service registration is ticked, creates its account itself (see above);
a personal account can belong to no administration group (ADMINS, DEVS and any group that grants an administration right): adding it is refused, and so is signing in if the account is there anyway. These accounts escape the two-step verification required from administrators, and your organisation does not control their mailbox;
the user list, the account card and the sign-in log show "Google (personal account)" or "Microsoft (personal account)".

Turning personal accounts on or off for a provider is recorded in the audit trail.

Microsoft 365 already configured before this version: the configuration is taken over automatically at the first start, with the same redirect address and the same accounts; just check that the "Microsoft 365" card is present and active.

Not supported: SAML (use the OpenID Connect provider, which most directories also offer) and automatic Windows sign-in without typing (Kerberos). Signing in AD accounts with their Windows password is planned for a later version.

Identity provider buttons: above the form (recommended) or below. The "Continue with …" buttons take the theme's main colour and carry the provider's logo; a "or with your email" separator divides them from the form. If form sign-in is unticked, only the buttons are shown.

Self-registration

When ticked, Self-registration turns an unknown person's first sign-in through an identity provider into an access request: they see a page telling them their request is pending, and no account is created until an administrator approves it. Members of the group given in Notified group code receive an email for each new request (not when a rejected request is reopened, see below).

Access requests

The list shows requests with name, email, provider, date and status: Pending, Approved or Rejected (50 per page). Tick one or more pending requests, then:

Approve selected creates the accounts (sign-in with the provider of the request) and lets each person know by email. The account is created without a group: after approval, the screen lists the accounts created without a group; then add them to the right groups from user administration. A request that could not be approved is reported separately.
Reject selected asks for a Reason for rejection, included in the email sent to each person. A rejected person who signs in again later reopens their request: it goes back to pending in the list, but no email is sent to the notified group — check the screen regularly.