How authentik signs FortiGate administrators in over SAML
A team that wants firewall administrators to sign in to the FortiGate management interface with their central identity and MFA, while VPN users keep their own sign-in path, needs two separate SAML applications in authentik, not one. authentik publishes a FortiGate administrator login guide that uses SAML, and it is distinct from its FortiGate SSL VPN guide. The admin login has its own application and provider, its own group-to-profile mapping, and its own validation, so a change made for VPN users should never be assumed to affect administrator access. Keeping the two apart also means a VPN policy change cannot lock out the people who manage the firewall.
The decision to make first is which authentik groups map to which FortiGate administrator profiles. Define the groups from the least privileged profile upward, and confirm that the attribute authentik sends in the SAML assertion matches what the FortiGate expects, so that a user in one group lands in the intended profile and nowhere else. Plan MFA as an authentik authentication policy on this application, and test it with an account that belongs to each admin group. Confirm the exact attribute names, certificate handling and profile names against the current guide in your environment before you configure anything.
This section does not cover the FortiGate SSL VPN login, which is handled in its own guide, or the wider set of firewall and network platforms in this group. It also does not cover FortiGate configuration beyond the administrator SAML settings, the build of authentik itself, or the installation and upgrade of FortiGate firmware. Keep a local emergency administrator account on the FortiGate and confirm how you will reach the device if authentik or the SAML trust is unavailable.
What you need before configuring FortiGate admin SAML
Administrator SAML login depends on four things being settled before anyone touches the FortiGate: the authentik deployment, the firewall's own recovery path, the groups that will carry admin rights, and the certificates, DNS and clocks that SAML relies on. Work through these cards in order, because a gap in one usually shows up as a failed login in another.
Confirmed authentik edition and version
Choose the edition before you build. The Open Source edition is free and has community support only, while Enterprise and Enterprise Plus add features and support terms listed on the pricing page. Pin the deployment to a version line the security policy lists as receiving fixes, which currently means 2026.5.x or 2026.8.x. Confirm the exact patch release against the GitHub releases page before you start, because security releases are announced at least 24 hours in advance.
FortiGate firmware confirmed against the guide
Before you plan the SAML steps, check your FortiGate firmware version against the FortiGate admin integration guide published by authentik. Menu paths and SAML options differ between firmware branches, so the guide you follow must match the build running on your appliance. Record the version in your change ticket so reviewers can see which steps were validated.
Tested local administrator
Keep a local administrator account that works before you enable SAML. If the SAML provider is unreachable, misconfigured or its certificate expires, the local account is the only way back into the management interface. Log in with it once, confirm its admin profile grants full access, and store its credentials in your privileged secret store. Plan to keep it after go-live, and document who may use it and under what change approval.
Groups mapped to admin profiles
Decide which authentik groups correspond to which FortiGate admin profiles before you create any mappings. A typical split separates read-only operators from network and security administrators, with a super-admin group kept small. Confirm that each group exists in authentik, has the intended members, and is sent in the SAML assertion under the attribute name the FortiGate expects. Groups with no mapping should be denied rather than defaulting to a broad profile.
Certificates and DNS for both endpoints
The SAML exchange needs a name that resolves and a certificate that the browser and the FortiGate both trust for each endpoint: the authentik server that issues assertions and the FortiGate management interface that consumes them. Confirm the fully qualified names, the certificate chain and its expiry date, and whether the FortiGate will present its own certificate or one you import. Mismatched hostnames and private certificate authorities are the most common causes of signing and redirect errors.
Time synchronization on both systems
SAML assertions carry validity windows, so clock drift between authentik, the FortiGate and the administrator's browser can make valid logins fail. Confirm that the authentik host and the FortiGate both sync to reliable time sources from your network time service, and that the FortiGate time zone and date are correct. Check the offset before testing, and include time sources in your operations runbook so drift is caught after go-live.
Configure the authentik SAML provider and FortiGate admin login step by step
This sequence connects authentik to the FortiGate management interface over SAML so administrators sign in through authentik, with a local path kept until the SAML login has been proven.
Create the authentik SAML provider and application
In authentik, create a SAML provider and an application for FortiGate administrator login, separate from any provider used for SSL VPN users. Set the ACS URL and the entity identifier to the values your FortiGate management interface will use, which you should copy from the FortiGate SAML configuration page in your own environment. Bind the application to a group or policy that contains only the administrators who should reach the management interface. The step is done when the application appears in the authentik application list and the provider shows the expected entity identifier and ACS URL.
Export the authentik signing certificate
Export the signing certificate and the SSO metadata from the authentik provider page. Keep the certificate file in your change record so the FortiGate import can be traced later. Confirm the certificate fingerprint or subject with the authentik administrator before you import it, because a mismatched certificate is the most common reason a SAML login fails silently. The step is done when you have a certificate file and the metadata URL or file saved alongside the change ticket.
Import the certificate and create the SAML server on FortiGate
On the FortiGate, import the authentik signing certificate under the certificate management area, then create a SAML server object that uses it. Enter the authentik SSO URL and the entity identifier exactly as shown on the authentik provider page, and confirm the username attribute against what authentik sends in its assertion. Check the FortiGate documentation for your firmware version, since menu paths differ between releases. The step is done when the SAML server object saves without error and lists the imported certificate.
Set the redirect and entity identifiers to match
Compare the entity identifier, the ACS (redirect) URL and the FortiGate hostname in both systems. The FortiGate base URL used in the browser must match the value configured in authentik, including the port if the management interface is not on the default port. A mismatch here produces an assertion that FortiGate rejects. Record the final values in your runbook. The step is done when both systems show identical strings and a test assertion decodes without audience or destination errors in the authentik event log.
Create the SAML user group and admin profile
On FortiGate, create a remote SAML user group that references the SAML server, and map it to an admin profile with only the permissions the role needs. Mapping should follow the authentik group names and, where you use attributes, the attribute value sent in the assertion. Keep the mapping list short and review it with the people who approve admin access. The step is done when the group lists the SAML server as its remote source and the admin profile shows the intended privileges.
Bind administrator login to the SAML server
In the FortiGate system settings for administrators, enable remote authentication for the admin accounts that should use SAML, and bind them to the SAML user group. Leave the local administrator account in place with a strong, offline-stored password and, if your policy requires it, a separate console path. Do not remove the local path yet. The step is done when the remote admin accounts are listed with the SAML binding and the local account still exists.
Test sign-in with a non-critical admin before closing local access
Sign in to the FortiGate management interface with a non-critical administrator account through the SAML path, confirm the expected admin profile is applied, and check the authentik event log and the FortiGate system event log for the successful login. Repeat with a second account that should be denied, and confirm the refusal is logged. Only after both checks pass should you decide whether to restrict or remove the local path, and keep a tested break-glass route in place. The step is done when both logs show the expected outcomes and the change record is updated.
Mapping authentik groups to FortiGate admin profiles
This table compares each identity element in the SAML path, from the authentik attribute the firewall reads to the FortiGate admin profile it grants, and the local account that stays outside SAML. Read it top to bottom before you create any group, because a mismatch in one name typically means the administrator logs in with no profile or cannot log in at all. Confirm each FortiGate field name and setting against the integration guide and your FortiOS version before you rely on it.
| Element | Where it is set | What to match or confirm |
|---|---|---|
| Username attribute | authentik SAML provider attribute mapping | Send the attribute FortiGate uses to name the administrator, such as a unique username. Confirm the expected attribute name in the FortiGate guide. |
| Group attribute | authentik SAML provider attribute mapping | Send group membership as a SAML attribute so FortiGate can match SAML user groups. Group names must match exactly, including case and spaces. |
| authentik group names | authentik directory groups | Create one group per admin role, for example a read-only group and a super-admin group. Avoid reusing groups that also grant VPN or application access. |
| FortiGate SAML user group | FortiGate SAML server and user group configuration | Each SAML user group name must equal the value sent by authentik. Any difference leaves the administrator without a matching profile. |
| FortiGate admin profile | FortiGate administrator settings and access profile | Map each SAML user group to one admin profile. Test each profile with a non-super-admin account before rollout. |
| MFA enforcement | authentik authentication flow and policy bound to the admin application | Bind an MFA stage to the admin application only, so administrator sign-in requires a second factor while VPN users keep their own policy. |
| Local emergency admin | FortiGate local administrator account | Keep one local administrator outside SAML with a strong, offline-stored credential and a documented break-glass procedure. Test it before SAML is enforced. |
Where MFA sits in the admin login and what each option means
MFA enforced in the authentik authentication flow runs before authentik builds the SAML response. The FortiGate appliance never sees the second factor. It only receives an assertion after the user has finished the flow, so every administrator who reaches the SAML application passes the same checks. This is the simplest model to explain to an auditor because the enforcement point is a single flow in authentik.
- Scope: Every user bound to the FortiGate admin application goes through the stage, so no admin can skip it.
- Stage order: The MFA stage must sit after the password stage in the flow you bind to the application. Confirm the order in the flow diagram before go-live.
- Failure behavior: A user who cannot finish the second factor gets no assertion and no admin session.
- Change control: Changing the flow changes the admin login for all administrators at once, so test it in a non-production instance first.
Confirm with your team which flow authentik uses for this application and who is allowed to edit it, because that person controls the admin login.
Group-scoped MFA applies the second factor only to a subset of administrators, selected by group membership. You bind the MFA stage to a flow or policy that matches a group, such as a network security group, and leave other administrators on a lighter flow. This fits organizations where read-only operators or helpdesk staff must log in without a second factor, while firewall engineers must always complete one.
- Selection logic: Use an authentik policy bound to the group so the decision depends on membership rather than on a per-user setting.
- Gaps to close: Any account that is not in a covered group falls outside the MFA requirement, so decide what the default is for new users.
- Role alignment: Keep the group that grants MFA identical to the group that grants the most privileged FortiGate admin profile. Otherwise an admin could hold a powerful role without the stronger check.
- Review: Group membership changes over time, so schedule reviews of who belongs to the MFA group.
Illustrative example: a team with two read-only operators and three engineers would place only the engineers in the MFA group, but the engineers' group should also be the one mapped to the super administrator profile. Confirm this mapping before you rely on it.
A FortiGate can keep local administrator accounts alongside SAML sign-in. A local account logs in against the appliance directly, so authentik's flow, including any MFA stage, is not part of that path. The second factor you enforce in authentik protects only the SAML route. Your effective security equals the weakest route into the management interface, so the local fallback needs its own controls.
- Bypass path: A local administrator with a password can sign in without authentik, unless you disable local admin logins or restrict them to specific trusted addresses.
- Emergency access: Keep at least one break-glass account, store its credentials offline under dual control, and test the procedure on a schedule.
- Management exposure: Limit which networks can reach the administrative interface, because the SAML and MFA controls do not restrict network access.
- Version behavior: Confirm in the FortiGate documentation for your firmware how SAML and local logins interact, since this varies by release.
Before sign-off, have an engineer attempt a local login from an untrusted network and record the result as evidence of the control you intend.
The type of second factor is a separate decision from where it is enforced. Which methods authentik supports, how they are enrolled, and how recovery works are covered on the authentik MFA and passwordless page in this group. The FortiGate admin login does not add any factor of its own, so the choice you make in authentik is the only one that applies to SAML administrators.
- Method selection: Pick the factors your admins can use consistently, and check them against the MFA page before enabling them in the flow.
- Enrollment: Decide whether admins enroll their own factors or an operator enrolls them, and document the step.
- Recovery: Define how a locked-out administrator regains access without weakening the flow, and make sure recovery does not route around the MFA stage.
- Consistency: Use the same factor policy for the FortiGate admin application and for other firewall administration tools that share the same identity source.
- Testing: Verify each chosen factor end to end on the FortiGate login page, not only inside authentik.
Before you choose a method, confirm with the MFA page and with your security team which factors meet your internal policy.
Hardening the FortiGate admin SAML path
Moving firewall administration behind SAML removes local passwords from daily use, but it also makes the identity provider a single point of failure for the firewall. The cards below cover the controls that keep administrators able to get in during an outage and keep every sign-in and change traceable on both the authentik and FortiGate sides.
Keep a local break-glass admin
Keep at least one local FortiGate administrator with a long, unique password stored in a sealed, access-logged vault, and test that it works before cutover. This account is the way back in if authentik, its database or the network path to it fails. Restrict it to the console or a management interface that does not depend on SAML, and record each time it is used. Confirm with your own change process who may retrieve the credential and how the password is rotated after any use.
Restrict admin GUI access
Limit which interfaces accept HTTPS and SSH administration and set trusted hosts on each administrator so the management GUI is reachable only from a dedicated admin network or jump host. Keep the management plane off internet-facing interfaces. Make sure the authentik URL used for the SAML callback is reachable from the firewall's management path, because a restricted admin network that cannot reach the identity provider will lock out SAML users in the same way a broken certificate would.
Protect the signing certificate
The SAML signing certificate and any private key used on the FortiGate side are trust anchors for every admin login. Store exported keys in a controlled location, limit who can export or replace the authentik signing certificate, and track certificate expiry so a renewal does not silently break sign-in. Before replacing the certificate on either side, plan the import on the FortiGate and confirm the new certificate is the one authentik presents, as a rushed swap is a common cause of failed logins.
Limit admin profile rights
Map authentik groups to the narrowest FortiGate admin profile that fits each job, rather than granting super_admin to every member of a broad group. Review which profiles can change firewall policy, administrator accounts and the SAML configuration itself, and keep those rights with a small named group. Confirm that group membership changes in authentik are reviewed through the same process as firewall policy changes, since a single group edit can change an administrator's effective rights.
Enable audit logging on both sides
Turn on administrator event logging in FortiGate and send it to a central log store, and confirm that authentik's login, flow and admin events are retained long enough for your investigations. Correlate the two by time and username so you can show who signed in, from which address and what they changed. Authentik's enhanced audit logging is listed as an Enterprise feature on its pricing page, so assess whether the event data available in the open-source edition meets your logging requirements before relying on it.
Common FortiGate admin SAML failures and how to fix them
This table lists the failures most often seen when FortiGate administrator sign-in runs through authentik over SAML, with the likely cause and fix for each. Read each row against the values in the authentik FortiGate admin integration guide, because most failures trace back to a single mismatched entity ID, URL, certificate or group name.
| Failure | Likely cause | Fix and what to confirm |
|---|---|---|
| Login fails with an invalid issuer or audience error | Entity ID on the FortiGate SAML server does not match the entity ID in the authentik SAML provider | Copy the entity ID and ACS URL exactly from the integration guide, including trailing slashes and scheme, then re-save the provider on both sides |
| Browser redirects back to the login page with no error | ACS URL on the authentik provider points to a different FortiGate address than the one used to sign in | Confirm the FortiGate hostname or management IP used in the browser matches the ACS URL configured, and update whichever value is wrong |
| Signature validation fails | FortiGate holds an old or wrong signing certificate, or the certificate was re-created in authentik | Re-import the current signing certificate from the authentik provider into FortiGate and confirm the certificate name selected in the SAML server |
| Sign-in fails after working for months | The signing certificate has expired or was rotated without updating FortiGate | Check the certificate validity date in authentik, plan rotation before expiry, and import the new certificate before retiring the old one |
| Assertion rejected as not yet valid or expired | Clock skew between the FortiGate, authentik server and the user's device | Synchronize time on all components with NTP, then retest; check the FortiGate system time and time zone first |
| Admin signs in but receives no admin profile or read-only access | Group names in authentik do not match the group attribute values FortiGate maps to admin profiles, including case and spelling | Compare the attribute name and group values in the assertion with the SAML user group and admin profile mapping, and align them exactly |
| Admin is denied access after successful login | User is not in any group allowed to use the SAML admin login, or a default profile is missing | Confirm the authentik user belongs to the intended group, and that the FortiGate admin profile mapped to that group exists and has the needed permissions |
| MFA prompt repeats or the login loops | Authentication flow in authentik re-challenges the user, or the session does not carry the MFA result back to FortiGate | Review the authentik flow and stage bindings for the application, and test with a fresh browser session to rule out stale cookies |
| All administrators are locked out after a configuration change | A changed entity ID, certificate or group mapping broke SAML for every admin, and no local admin was kept | Keep at least one local emergency administrator account with a separate credential, test it before changes, and make SAML changes one at a time with a rollback plan |
Questions teams ask before configuring FortiGate admin SSO
Can FortiGate admin login and SSL VPN share one SAML application in authentik?
Usually they should not share one SAML application, and the safer design keeps them separate. authentik publishes separate guides for FortiGate administrator login and FortiGate SSL VPN, and both use SAML, so the two paths have different entity settings, assertion attributes and group rules. Keeping them apart means a change made for VPN users cannot quietly alter who can manage the firewall. Confirm the exact entity IDs, certificate handling and attribute names against the authentik FortiGate admin guide and your FortiGate firmware before you decide.
How long does FortiGate admin SSO setup take, and what drives it?
The duration depends mostly on how many admin profiles you need, how groups are structured in your identity store, and how much testing your change process requires. The main steps are creating the authentik SAML provider and application, importing the signing certificate into FortiGate, defining the SAML user and admin profile mapping, and testing with a break-glass local admin in place. Environments with several admin roles, existing group sprawl or a formal change window take longer. Ask any partner for a written timeline tied to these steps rather than a generic estimate.
Can our own team configure FortiGate admin SSO without outside help?
Yes, a team with working knowledge of SAML, FortiGate administration and authentik can do it, provided it can test safely. The configuration itself is a bounded set of settings, but mistakes can lock administrators out of the firewall, so a tested recovery path matters more than speed. Your team should be able to read SAML assertions, match group names exactly, and reset a local administrator. If any of these skills are thin, a fixed-scope engagement can cover the build and knowledge transfer.
What do we need from our firewall and identity staff?
You need firewall staff who own the FortiGate configuration, administrator profiles and change control, and identity staff who own authentik groups, MFA policy and the signing certificate lifecycle. Both groups should agree who approves changes to admin profile mapping, since that mapping decides who holds full firewall rights. Plan for a test FortiGate or a maintenance window, and document the local emergency administrator separately from SSO.
Which authentik edition do we need for FortiGate admin SSO?
The authentik pricing page lists an Open Source edition at no cost, and SAML provider support is part of the core product, so the FortiGate admin guide does not depend on an Enterprise license. The pricing page lists Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. Enterprise adds features such as mTLS client certificate authentication, enhanced audit logging and ticket-based support, so whether you need them depends on your audit and support requirements. Confirm current pricing and feature availability on the authentik pricing page before you buy.
How do authentik and FortiGate upgrades affect admin login?
An authentik upgrade can change SAML behavior, certificates or defaults, so test admin login in staging before upgrading production. authentik supports only certain versions for security fixes, and the security policy names 2026.5.x and 2026.8.x as supported lines, so plan upgrades to stay on a supported line. FortiGate firmware upgrades can change SAML handling or admin profile behavior, so retest after each firmware change. Keep the signing certificate expiry date on your calendar, and rehearse the break-glass login after every change.
What happens to firewall administration if authentik is down?
Administrators who depend only on SAML cannot sign in to the FortiGate management interface while authentik is unavailable. This is why a local emergency administrator, stored with a strong password and tested on a schedule, should exist outside SSO. Authentik availability depends on its PostgreSQL database and server containers, so design those components for the availability you need. Document the break-glass procedure, limit who can use it, and log each use.
What changes for your firewall team after go-live
The main shift is that FortiGate administrator access stops being a list of local accounts on the firewall and becomes group membership in authentik. Once admin profiles are mapped from groups, granting or removing firewall rights is a change to a directory group, not a change on each appliance. Your team should agree who owns those groups, who approves membership changes, and how often group membership is reviewed. Offboarding then becomes a directory action: disabling the user in authentik ends new SAML logins, but it does not end sessions already open on the FortiGate. Confirm with your own tests how long an existing administrative session stays valid after the account is disabled, and set the administrator session timeout on the appliance to match your policy.
A break-glass process must be written down and rehearsed before go-live, because a SAML outage, an expired signing certificate or a mistake in the group mapping can lock every administrator out of the management interface at once. Keep at least one local administrator account on the FortiGate, store its credentials under dual control, and test that the account still logs in while the authentik integration is in use. Rehearse the steps to reach the appliance console, restore the local login and reverse the change, and record who can perform them outside business hours. Review the certificate and metadata expiry dates on the SAML application as a routine task, since a silent expiry is one of the more common ways admin access fails.
Firmware updates on the FortiGate and version upgrades of authentik both change parts of the login path, so each one needs a retest of administrator sign-in before it reaches production. After an authentik upgrade, check the SAML application, the signing certificate, the attribute mapping and the MFA stage for each admin group, and log in with one account from each profile. After a FortiGate firmware update, confirm that the SAML server and admin profile settings survived the change. Check the upgrade notes for both products before scheduling, and treat a failed retest as a reason to stop and fall back to the local break-glass account rather than to troubleshoot in the live management session.
