How authentik signs FortiGate SSL VPN users in over SAML
authentik acts as the SAML identity provider and the FortiGate acts as the service provider. Your team wants VPN users to sign in with their authentik accounts, so that passwords, group membership and MFA are managed in one place instead of as local accounts on each FortiGate. The documented method for this is the authentik FortiGate SSL VPN guide in the authentik integrations catalog, which covers the complete configuration on both sides.
At a high level, a user starts a connection to the SSL VPN portal on the FortiGate, and the FortiGate redirects the browser to authentik. authentik authenticates the user, then returns a signed SAML assertion to the FortiGate, which checks the signature against the certificate you imported and decides which SSL VPN portal the user may enter based on the group in that assertion. The guide covers five parts: creating a group and SAML provider in authentik, importing the signing certificate into FortiGate, configuring the SAML SSO server, creating a user group that uses that SSO server, and mapping that group to an SSL VPN portal. Each part depends on the one before it, so the order in the guide matters.
Before you start, confirm three things with your own team rather than assuming the defaults. First, confirm which FortiOS version runs on your FortiGate, because the guide is a vendor integration walkthrough and its screens and menu paths can change between releases. Second, confirm that your VPN design still uses SSL VPN tunnel mode, since FortiOS 7.6.3 replaces that mode with IPsec VPN. Third, decide which authentik group will grant access to each portal and who approves changes to that group. Those decisions shape the mapping step far more than the SAML settings do.
What you need before configuring SAML on FortiGate
Six items have to be in place before you touch either side of the SAML handshake. Each one is a dependency: a supported authentik version, a FortiGate running a FortiOS release that still offers SSL VPN, a portal hostname that resolves, admin rights on both platforms, and groups that already exist in authentik. Confirm each before you schedule the change window.
Supported authentik version line
Confirm that your authentik deployment runs a release line that still receives security fixes. The authentik security policy lists the supported lines, and the project announces security releases at least 24 hours in advance, so subscribe to that notice and plan patch windows around it. Record the exact version you will test against, because the SAML provider settings and the signing certificate export path can change between releases. Also confirm that the server and worker containers, and PostgreSQL, are healthy before you begin.
FortiGate with SSL VPN enabled
Confirm the FortiOS version on the FortiGate and read its release notes before you plan the work. In FortiOS 7.6.3, SSL VPN tunnel mode was replaced by IPsec VPN and its settings were not carried over during upgrade, so a FortiGate on that release or later may not offer the tunnel mode that your users depend on. Check whether SSL VPN is still available on your model and version, and whether your portal uses web mode, which is not supported on some desktop models.
Reachable portal hostname
Decide the fully qualified domain name that users will type to reach the SSL VPN portal, and make sure it resolves to the FortiGate's public or intended listening address. The SAML assertion and the redirect back to the portal both depend on this hostname, so a mismatch between the name in authentik and the name the browser uses will fail the login. Plan a valid certificate for that name on the FortiGate, and confirm that the name is reachable from the networks where your remote users sit.
Admin access on both sides
You need an administrator account in authentik that can create applications, providers and groups, and an administrator account on the FortiGate that can import certificates and edit SAML SSO servers, user groups and SSL VPN portals. Agree on who holds each role and where the change is recorded. Keep a local FortiGate administrator with a known password outside SAML so that a misconfigured SAML server does not lock every administrator out of the device.
Groups that exist in authentik
Create the authentik groups that map to your VPN portals before you configure the FortiGate, because the SAML assertion carries group membership and the FortiGate user group must match what authentik sends. Decide which groups grant access to which portal, and confirm that the users who need VPN access are members. Naming the groups consistently across both platforms avoids a common failure where login succeeds but the user lands in no portal.
Backup of the current FortiGate configuration
Before you change SSL VPN or authentication settings, back up the running configuration. FortiOS can export the configuration as a .conf file or in YAML format, to a local PC, a USB disk or FortiManager, and you can encrypt the backup with a password that is then required to restore it. Store the file and its password where your change team can reach them, and test a restore plan in a lab if one is available. This gives you a known-good state to return to if the SAML change disrupts existing VPN access.
Configuration sequence for the authentik SAML provider and FortiGate SSO server
This sequence connects authentik as the SAML identity provider for FortiGate SSL VPN, so that a user in an authentik group signs in and lands on the correct VPN portal. Each step ends with a check you can run before moving on.
Confirm FortiOS version and VPN mode
The network team confirms the FortiOS version and whether any SSL VPN tunnel mode configuration is in use before changing anything. Fortinet's 7.6.3 release notes state that SSL VPN tunnel mode is replaced by IPsec VPN and that its settings are not carried over on upgrade, so tunnel mode must be migrated first. Confirm this with Fortinet's documentation and your own environment. The step is done when you have a written record of the version, the VPN modes in use, and any migration work that comes before the SAML change.
Create the authentik group and SAML provider
An authentik administrator creates a group for VPN users and a SAML provider for the FortiGate, following the authentik FortiGate SSL VPN guide. The provider defines the Assertion Consumer Service URL, entity ID and the attributes sent to FortiGate, and the application is bound to the group so that only its members can sign in. The step is done when the provider's ACS URL and entity ID match the values shown in the FortiGate SAML settings you will enter later, and a test user who is in the group is listed as authorized for the application.
Export the signing certificate from authentik
The administrator exports the signing certificate that authentik uses for the SAML provider, along with the metadata or certificate file the guide specifies. The certificate is the trust anchor FortiGate uses to verify SAML responses, so the file must come from the same provider configured in the previous step. Store it in your change record. The step is done when the exported certificate's subject and validity dates are recorded and you can confirm it is the certificate attached to the provider, not a certificate from another application.
Import the signing certificate into FortiGate
A FortiGate administrator imports the authentik signing certificate into the FortiGate certificate store. This lets the firewall validate signed SAML assertions from authentik. Use the import location described in the FortiOS administration documentation for your version. The step is done when the certificate appears in the FortiGate certificate list with the same subject and expiry date you recorded in the export step. If the names differ, stop and find out which certificate was imported before continuing.
Configure the SAML SSO server on FortiGate
The FortiGate administrator creates a SAML SSO server that points to the authentik provider, using the entity ID, sign-on URL, and imported certificate from the earlier steps. The SSO server settings must match the authentik provider exactly, because a mismatch in entity ID or ACS URL is the most common cause of a failed login at this stage. The step is done when the SSO server saves without error and the values on both sides have been compared line by line.
Create the FortiGate user group for SAML users
The administrator creates a user group on FortiGate that uses the SAML SSO server as its authentication source. The group should be named so that it is clear which authentik group feeds it. Group membership on the FortiGate side is what determines portal access, so the mapping between the authentik group and this user group must be documented. The step is done when a test user from the authentik group appears as a member of the FortiGate user group after a login attempt, or when the match rule is shown to work in a controlled test.
Map the user group to an SSL VPN portal
The administrator adds the FortiGate user group to the SSL VPN portal policy so that members are sent to the intended portal. Keep separate portals for separate user populations if your access model needs them, and confirm that no other policy grants the same users broader access. The step is done when the portal policy references the correct user group, and a review of the policy confirms that users outside the authentik group cannot match it.
Test login and confirm group resolution
Run a test login with a user from the authentik group and a user outside it. The first user should authenticate through authentik, reach the assigned portal, and show the expected FortiGate group. The second user should be refused or routed away from that portal. Check the FortiGate logs for the SAML authentication events and the group resolved for each session. The sequence is complete when both results match the access model you documented, and any failed attempt has been traced to a specific value in the SSO server or group configuration.
Why FortiOS 7.6.3 changes the SSL VPN design
Before you build the authentik SAML flow, confirm that your FortiGate still runs SSL VPN tunnel mode. The FortiOS 7.6.3 release notes state that SSL VPN tunnel mode is replaced with IPsec VPN on all FortiGate models. The setting is no longer available in the GUI or CLI, and it is not carried over from earlier versions. If your tunnel mode configuration is still in use, you must migrate it to IPsec VPN before upgrading, or the tunnel will not come back after the upgrade. Fortinet publishes SSL VPN to IPsec VPN migration guides for FortiOS 7.4.4 and 7.6.0, and the team should use the guide that matches its current version. Read the FortiOS 7.6.3 release notes before scheduling the upgrade.
The SAML design in this guide assumes the portal you are configuring is still an SSL VPN portal. Under FortiOS 7.6.3, IPsec VPN can run over TCP port 443 in place of SSL VPN tunnel mode, so a team that migrates tunnel users may need a different client path and a different portal and authentication setup. Agentless VPN, formerly SSL VPN web mode, is also not supported on the FortiGate 40F, 60F and 90G series. Confirm with your Fortinet partner or the release notes which of these features your model supports and whether any of your users depend on them. Record that answer before you create the authentik provider, because it decides which portal the SAML SSO server maps to.
Ask for a written inventory of the tunnel mode users, their client versions, and any web mode bookmarks on each device. That inventory tells you how much of the design is a straight swap to a new portal and how much is a migration with user communication and a rollback plan. Plan the authentik changes and the FortiOS migration as one change window, and test the complete login path on a lab FortiGate running the target firmware first.
Mapping authentik groups and SAML attributes to FortiGate user groups and portals
This table traces one VPN user's access from the authentik group, through the SAML attribute in the assertion, to the FortiGate user group and the SSL VPN portal it unlocks. Read each row as a value to set and confirm in your own environment, since names and attribute settings vary by deployment. The main takeaway is that the group name, the attribute name and the FortiGate group name must match exactly, and users outside the target group should have no portal access.
| Mapping element | Value to set or confirm | Why it matters |
|---|---|---|
| authentik group | Dedicated group for SSL VPN users, for example a group created for remote access only | Access is granted by membership, so a broad or shared group can expose the portal to users who should not have it. |
| SAML attribute or group claim | The attribute name and format that authentik sends in the assertion, confirmed against your SAML provider settings | FortiGate matches on what arrives in the assertion, so the attribute name must be checked in a real test login, not assumed. |
| FortiGate user group name | Local user group on FortiGate linked to the SAML SSO server, name chosen by your team | This group is the object policies reference, and a mismatch with the assertion value leaves the user without access. |
| SSL VPN portal | Portal name mapped to the user group in the SSL VPN settings | The portal decides which resources and tunnel options the user sees after sign-in. |
| Username or email identifier | The identifier FortiGate expects in the assertion (username or email), confirmed in your test environment | A mismatch causes login failures or duplicate local accounts, so confirm the identifier before rolling out to users. |
| Users outside the target group | Authentication denied or routed to a no-access portal, to be verified with a test account not in the group | A user who signs in to authentik but is not in the group must not reach a VPN portal, so test this path explicitly. |
| Local emergency administrator | A local FortiGate admin account kept for recovery, tested separately from SAML | If the SAML server or certificate fails, administrators need a documented way back into the device. |
| Group changes after login | Confirm whether group membership is refreshed at each sign-in or only at first login | Removed users may keep access until their session ends or the group is re-evaluated, so confirm the behavior before relying on it. |
Hardening the SAML trust between authentik and FortiGate
Getting SAML working is only the first step. The trust between authentik and FortiGate depends on the signing certificate, the groups that reach each portal, a way back in if authentication fails, MFA at the identity provider, and a patched FortiOS release. The cards below cover each control and what to check before and after a change.
Track the signing certificate lifecycle
The FortiGate trusts the authentik signing certificate you import, so any change to that certificate breaks SSL VPN logins until FortiGate is updated. Record the certificate's expiry date, the date you plan to rotate it, and the owner who imports the replacement. Test a rotation on a lab FortiGate or a maintenance window before production, and confirm the new certificate is active on the SAML SSO server before removing the old one.
Restrict portal access by group
Map each SSL VPN portal to a specific authentik group rather than letting every authenticated user reach every portal. Review group membership on a schedule, and remove access for leavers and contractors through authentik so the change takes effect at the next login. Ask your DeployOpen team or your own administrators to document which group maps to which portal and routes.
Keep a local emergency administrator
If authentik is unavailable or the SAML configuration is wrong, administrators need a way into the FortiGate. Keep at least one local administrator account that does not depend on SAML, protect its password in a secrets store, and test that it still logs in after each change. Confirm the access path with your network team before you disable any password-based login.
Enforce MFA in authentik
FortiGate relies on the SAML assertion from authentik to decide whether a user is authenticated, so the second factor must be enforced in the authentik authorization flow for this application. Attach an MFA stage to the flow used by the SAML provider and test that a user without an enrolled factor is handled as your policy requires. Do not assume the FortiGate applies its own second factor to SAML logins without checking the configuration.
Stay on a supported, patched FortiOS
CVE-2024-21762 is an out-of-bounds write in FortiOS 6.0 through 7.4.2 and FortiProxy that allows unauthorized code execution, and CISA added it to the Known Exploited Vulnerabilities catalog on February 9, 2024. Confirm your FortiOS version is outside the affected range and subscribe to Fortinet security advisories. Also check the FortiOS 7.6.3 release notes if you plan an upgrade, because SSL VPN tunnel mode must be migrated to IPsec VPN before upgrading.
Back up the configuration before changes
Export the FortiGate configuration before any SAML, certificate or upgrade change. FortiOS can save a .conf file in FortiOS format or a YAML file, to a local PC, a USB disk or FortiManager. You can encrypt the backup with a password, but that password is required to restore it, so store it in your password vault before you export. Test a restore on a non-production device when you can.
Common SAML login failures and how to fix them
This table lists the SAML sign-in failures most likely to appear when FortiGate SSL VPN uses authentik as its identity provider, with the likely cause, the check to run and the fix for each. Work down the rows in order, since several symptoms look alike and the first check usually separates them. Confirm exact field names and menu paths against the authentik FortiGate guide and the FortiOS release notes for your version.
| Failure | Likely cause and check | Fix |
|---|---|---|
| Signature validation fails after certificate rotation | The signing certificate imported into FortiGate no longer matches the one authentik now signs assertions with. Compare the certificate fingerprint in the authentik SAML provider with the certificate stored on the FortiGate SSO server entry. | Export the current signing certificate from the authentik SAML provider, import it into FortiGate in place of the old one, and test a fresh login. Schedule this step as part of any certificate change. |
| Assertion rejected because of clock skew | The FortiGate and authentik hosts disagree on time enough to make the assertion's validity window appear expired or not yet valid. Check NTP status on both sides and compare timestamps in the failed login log. | Correct time synchronization on the FortiGate and the authentik server or container host, then retry. Do not widen tolerances as a first step. |
| Audience or ACS URL mismatch | The entity ID or assertion consumer service URL configured in authentik does not match the values FortiGate expects, often because the FortiGate hostname or port changed. Compare the SAML provider's entity ID and ACS URL with the SSO server settings on the FortiGate. | Align the entity ID and ACS URL on both sides to the exact FortiGate address users connect to, including any non-default port. Re-import metadata or update the values by hand, then test. |
| User authenticates but lands without portal access | Authentication succeeded, but the user's authentik group is not mapped to a FortiGate user group or SSL VPN portal. Check the group membership in authentik and the user group that the SAML SSO server maps to on FortiGate. | Add the authentik group to the FortiGate user group used by the target SSL VPN portal, confirm the portal assignment, and have the user sign in again. Document which group grants which portal. |
| Login loop after an upgrade that changed tunnel mode | FortiOS 7.6.3 replaces SSL VPN tunnel mode with IPsec VPN, and tunnel mode settings are not upgraded. Check whether the portal or tunnel configuration was carried over, and whether the client is repeatedly redirected to the SAML step after a failed tunnel setup. | Migrate tunnel mode configuration to IPsec VPN before upgrading, following Fortinet's migration guidance. Back up the configuration first, then confirm the portal and SAML settings after the upgrade. |
Questions teams ask before configuring FortiGate SSO with authentik
What drives the cost of a FortiGate SSL VPN SAML integration with authentik?
The main cost drivers are the number of FortiGate units, SSL VPN portals and user groups in scope, and whether any tunnel mode configuration must be migrated first. The authentik Open Source edition is listed as free on the pricing page, so most of the cost sits in the work itself: staff time for design, configuration, testing and rollout, and any partner fees. Ask for a quote that lists each FortiGate, each portal and group mapping, the test plan, whether the FortiOS migration is included, and what training or documentation is delivered. Check the authentik pricing page to confirm whether any feature you plan to use is restricted to the Enterprise edition.
How long does FortiGate SSO with authentik take to set up?
Duration depends on how many FortiGate devices and portals are involved, how many groups need separate access, and whether the FortiGate is already running a version that requires migration. A single-device lab setup moves faster than a production environment with high availability pairs, multiple VDOMs and change control windows. Plan extra time for testing with real user accounts, for certificate exchange, and for a rollback path. Ask any provider to break the timeline into design, build, test, cutover and handover, and to state which of those steps depend on your change approval process.
What does the integration need from our internal team?
Your team needs administrative access to the FortiGate and to the authentik instance, plus a named owner for each side of the integration. On the FortiGate side, someone must import the signing certificate, configure the SAML SSO server and user group, and map the group to the SSL VPN portal. On the authentik side, someone must create the group, the SAML provider and the application. Your team should also provide test accounts in each group, a maintenance window, a current configuration backup, and a decision on whether backups are encrypted, since FortiGate can require a password to restore an encrypted file.
Can our own team configure FortiGate SSO with authentik without outside help?
A team with working knowledge of FortiGate SSL VPN administration and authentik providers can usually complete the core SAML setup without outside help, because the authentik integration guide walks through the main steps. The harder parts are usually the surrounding work: testing each group and portal, planning a rollback, keeping a local emergency administrator, and documenting the result for audit evidence. Outside help is most useful when the environment is complex, when the team has no spare time for a change window, or when a fixed-scope written plan with test evidence is required. Ask any partner to state in writing what is delivered and what remains with your team.
Can we enforce MFA for FortiGate VPN logins through authentik?
Whether MFA can be enforced depends on how the SAML login flow is built in authentik, and the answer should be confirmed in your own test environment before rollout. Authentik can place an authentication flow with a second factor in front of the SAML provider, so a user must complete the extra step before the assertion is sent to FortiGate. Test that the step applies to every group that reaches the VPN portal, that enrollment works for new users, and that recovery options exist for lost devices. Confirm with the integration guide and your authentik version how the MFA stage is attached to this provider.
Does upgrading to FortiOS 7.6.3 or later affect our SAML VPN setup?
Yes, upgrading to FortiOS 7.6.3 or later can affect an SSL VPN setup because SSL VPN tunnel mode is replaced with IPsec VPN on all FortiGate models. According to the release notes, tunnel mode settings are not upgraded from previous versions, so tunnel mode configuration must be migrated to IPsec VPN before the upgrade. The release notes also say IPsec VPN can run over TCP port 443 in place of tunnel mode. Agentless VPN, formerly web mode, is not supported on the FortiGate 40F, 60F and 90G series. Review the FortiOS 7.6.3 release note on tunnel mode and confirm which migration guide applies to your current version before scheduling the upgrade.
Which FortiGate configuration should we back up before changing SSO?
Back up the full FortiGate configuration before any SAML change, and keep a copy that can be restored if the VPN fails after cutover. FortiOS 7.6 can export the configuration in FortiOS format as a .conf file or in YAML format, to a local PC, a USB disk or FortiManager. You can also set a password to encrypt the file, and that password is then required to restore it, so record it in your secrets store before the change window. Store the backup outside the FortiGate and test restoring it in a lab if your change process requires evidence that rollback works.
Which parts of this integration create the most operational risk after go-live?
The highest operational risk usually comes from certificate changes, group membership errors and firmware upgrades that alter the VPN mode. A signing certificate that expires or is replaced without updating the FortiGate can block every VPN login at once. Group mappings that depend on names can break when an administrator renames a group in authentik. Plan a calendar reminder for certificate renewal, document which group feeds each portal, and retest the login path after every FortiOS or authentik upgrade. Keep a named emergency administrator with local credentials so the firewall stays manageable if the identity provider is unavailable.
Keeping the integration working after go-live
The SAML trust between authentik and FortiGate is a set of settings on both sides, and it keeps working only if someone watches both. Track authentik releases through the authentik security policy, which lists the versions receiving security fixes and states that security releases are announced at least 24 hours in advance. That notice is short, so schedule a standing review of each release note against your deployed version, and confirm in your own environment how far ahead your team will see announcements. Before every FortiGate upgrade, re-read the FortiOS release notes for the target version, because SSL VPN behavior has changed between releases and a firmware change can alter what the SAML SSO server expects. Confirm that the SAML login path still works on a lab unit before you touch production.
Plan the signing certificate rotation as a scheduled change, not an emergency. When authentik issues a new signing certificate, import it into FortiGate, update the SAML SSO server, and test a login before removing the old certificate. Record the expiry date of the certificate in your change calendar. Review the authentik group membership that feeds the user group on FortiGate at a fixed interval, removing accounts that have left the VPN population and confirming that each group still maps to the intended SSL VPN portal. Any change on either side, including a group rename, a provider setting, a new portal or a firmware upgrade, should be followed by a test login with a representative user.
Remember that authentik stores its configuration and data in PostgreSQL, and that the identity service sits in the path of every VPN login. Its database backups, PostgreSQL upgrades, authentik version upgrades and worker health all affect whether remote staff can connect. Ask your team to confirm the database backup and restore procedure, the monitoring that alerts on a failing login, and who is on call for the identity service. Test the restore path for authentik on a regular schedule, since a VPN outage caused by an identity fault will look like a network problem to users.
How DeployOpen delivers authentik and FortiGate SSO
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure. For authentik and FortiGate SSL VPN SAML integration, we agree the scope in writing first, build the SAML application and FortiGate SSO configuration in your environment, and hand over the working setup with the documentation your team needs to run it.
How we scope
- We confirm which FortiOS version and FortiGate models are in use before any SAML work starts.
- We agree the authentik groups, SAML provider and portal mappings that will grant each VPN user group access.
- We check whether your VPN mode is SSL VPN tunnel mode, which FortiOS 7.6.3 replaces with IPsec VPN, and include any migration in the written scope.
How we build
- We create the authentik group and SAML provider, then import the signing certificate into FortiGate under your change process.
- We configure the FortiGate SAML SSO server and user group, then map that group to the agreed SSL VPN portal.
- We test sign-in with users from each group, including MFA prompts and denied-access cases, before any production cutover.
How we hand over
- You receive the as-built configuration record, group-to-portal mapping table and certificate rollover steps for your team.
- We document a FortiGate configuration backup taken before and after changes, with password encryption settings recorded for restores.
- We walk your administrators through the sign-in flow, troubleshooting steps and the points where authentik and FortiGate settings must match.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, FortiOS upgrade planning and re-testing after changes are available as a retainer.
- Before any authentik or FortiOS upgrade, we re-check the SAML integration and confirm the vendor's current release notes apply to your setup.
