Authentication
NullWard can require visitors to sign in before they reach an application, even if the application has no sign-in of its own. Each service has its own authentication settings, so different applications can use different identity providers. Require sign-in for a service Open the service. In Security, turn on Auth Enabled. Under Auth Providers, click + Add Auth Provider and choose a type. Fill in the provider's settings and click Save Changes. Provider types Type Use it for How visitors sign in OIDC Provider Microsoft Entra ID, Google, Okta, Keycloak, Authentik or any OpenID Connect provider. Recommended. Redirected to the identity provider's sign-in page LDAP Directory Active Directory, OpenLDAP Username and password on a NullWard sign-in page, checked against the directory Email Code People without an account in your directory, such as contractors and partners Enter their email address, then the 6-digit code sent to it Basic Auth Machine-to-machine or legacy integrations Username and password Header Auth Requests from a trusted upstream system that sends an identity header Transparent If a service has more than one provider, visitors choose one on a Choose Your Login Method page. With a single OIDC provider they go straight to the identity provider. OIDC Provider Type: Generic OIDC, Microsoft or Google. Enter the Client ID, Client Secret and Discovery URL (or Tenant ID for Microsoft) from your identity provider. Register the callback URL shown on the page with your identity provider: https://<hostname>/__nullward/callback, for each hostname of the service. Sign-in sessions are per hostname. Optionally restrict access with Allowed Groups (set Group Claim Name to the token claim that holds groups) or Allowed Domains. Reusable OIDC configurations can also be kept under Access Control > Service OIDC and referenced from services. LDAP Choose a Directory Type (Active Directory, OpenLDAP or Custom), then set the LDAP URL, Bind DN, Search Base DN and User Filter. Use Allowed Groups to admit only certain groups. Email Code Allowed Emails and Domains: full addresses, or whole domains written as @example.com. Subdomains aren't included. Code Valid For (minutes): 5–60, default 15. Each code allows 5 attempts. Codes are sent through the SMTP server configured under Settings > Notifications. Options for every provider Allowed CIDRs: offer this provider only to requests from these networks. Auth Paths: require sign-in only on these paths. Empty means all paths. Upstream Header Injection: pass the signed-in identity to the application in headers such as X-Authenticated-User, X-Authenticated-Groups, X-Auth-Method and X-Auth-Provider. [!WARNING] If every provider of a service is limited by Auth Paths or Allowed CIDRs, requests that match no provider are let through without sign-in. Check that your paths and networks cover everything you want protected. Sessions After signing in, visitors get a session cookie for that service. Sessions last 8 hours by default. Change this globally under Settings > Proxy & Session Defaults > Session Duration, or per service under Sessions. Session cookies are HttpOnly and, by default, Secure. Skipping sign-in On the service, under Security: Auth Bypass IPs / CIDRs: requests from these networks skip sign-in entirely, for example your office or monitoring systems. Auth Bypass Paths: path regexes that skip sign-in, for example ^/api/health$ or ^/webhook/. Path access rules Path Access Rules on a service can deny a path to everyone (Deny All) or restrict it to members of certain groups (Allow Groups Only). For example, /admin can be limited to an administrators group from your identity provider. Signing in to the admin dashboard The admin dashboard has its own sign-in, separate from the services: Local accounts: the bootstrap admin from .env, plus users added under Administration > Users. Single sign-on: add a provider (Microsoft, Google or generic OIDC) under Settings > Authentication > Admin OIDC Providers. Its…
NullWard documentation