How authentik signs GlobalProtect VPN users in over SAML
If your security or network team wants GlobalProtect logins to go through authentik instead of local firewall accounts, the integration uses SAML: authentik acts as the identity provider and GlobalProtect acts as the service provider. The authentik GlobalProtect guide documents the configuration, and this page explains how the pieces fit together so you can plan the work before touching either system. In practice, a user who connects to the GlobalProtect portal is redirected to authentik, signs in there, and returns with a SAML assertion that the firewall trusts because of the certificate exchange you configure on both sides.
Three components carry the design. On the authentik side, a SAML provider and its application define the entity ID, the assertion consumer service URL that GlobalProtect posts to, and the signing certificate that the firewall must import. On the firewall side, a SAML identity provider server profile holds that certificate and the sign-in and sign-out endpoints, and an authentication profile binds that server profile to the portal and gateway. Group membership in authentik is the lever for access: the assertion carries attributes that the firewall maps to user groups, which then drive which gateway or portal policy applies. Decide early which authentik groups map to which VPN access levels, because that model determines how many applications and policies you must maintain. The page covers this sequence and the checks that confirm each step works, but it does not set your access policy. Which groups may connect, whether MFA is required before the assertion is issued, how sessions time out, and whether a local emergency account remains on the firewall are decisions for your firewall administrators and security owners. Confirm with your team which authentik edition and license terms apply to your deployment, since the enterprise license governs the code in the enterprise directory and the pricing page lists features such as mTLS that some designs may need. Also confirm the GlobalProtect software version you run against the guide before you start.
What you need before configuring GlobalProtect SAML with authentik
Most GlobalProtect SAML problems start before any profile is created. The items below fix the authentik version, the firewall and portal layout, the certificates clients will trust, and the groups that decide who gets in. Settle them first, because each one changes the SAML settings you enter later.
authentik version to run
Run an authentik release that is still in the supported set listed in the authentik security policy, which currently names the 2026.5.x and 2026.8.x lines. Confirm the exact patch level you deploy against the GitHub releases page, since the project announces security releases at least 24 hours in advance. Plan a maintenance window so you can apply those fixes without leaving the VPN login path exposed or unavailable.
GlobalProtect-capable firewall or Prisma Access
Confirm you administer a Palo Alto Networks firewall or Prisma Access tenant with GlobalProtect portal and gateway roles enabled, and that you can edit the authentication profile and certificate profile on both. Check in your Palo Alto documentation which GlobalProtect release supports the SAML options you plan to use, including single logout and the attributes you need for group checks. Do not assume a feature exists because a neighboring release has it.
Portal and gateway FQDNs
Decide the fully qualified domain names for the portal and the gateway, and make sure DNS resolves them from outside your network. Clients must trust the certificates presented for those names, which means a publicly trusted certificate or an internal CA distributed to every device. Because SAML redirects users to authentik and back, the authentik base URL and the GlobalProtect hostnames must agree on the same DNS zone and be reachable from the user's browser.
SAML signing certificate handling
Plan how the authentik SAML provider signs assertions and how GlobalProtect receives the matching certificate. Export the signing certificate from authentik, import it into the firewall as the identity provider certificate, and record which certificate and key pair is active. Set a rotation owner and a date to repeat the import, because an expired or mismatched certificate will stop every VPN login at once. Keep the firewall's local administrator account available for recovery.
Groups in authentik that drive access
Create the authentik groups that will map to GlobalProtect access before you configure the firewall, and assign users to them through your normal process. Decide which groups grant full tunnel access, which grant restricted access, and which grant nothing. Confirm with your Palo Alto documentation how the firewall reads group membership from the SAML response, and make sure the attribute name you send from authentik matches what the firewall expects.
Test users and a rollback plan
Prepare a small set of test accounts in authentik, including one member of each access group and one user outside every group. Decide how you will roll back to your existing authentication method if the SAML flow fails for all users. Keep the previous authentication profile intact until the test results are complete, and record which users and groups were verified on which firewall version.
Configuration sequence from authentik to GlobalProtect
This sequence connects authentik to GlobalProtect as a SAML identity provider, so that portal and gateway logins are checked against authentik users and group membership. Each step ends with a check you can run before moving on.
Create the SAML provider and application in authentik
An authentik administrator creates a SAML provider for GlobalProtect, sets the assertion consumer service URL and entity ID to the values your GlobalProtect portal and gateway expect, and binds it to a new application. Choose the signing certificate and the name ID format the firewall will use, then assign the application to a group that will hold VPN users. Confirm the settings against the GlobalProtect guide in the authentik integrations catalog, since the exact field names and values come from that guide and your firewall version. The step is done when the application appears in the authentik application list and its SAML metadata page loads without errors.
Export the signing certificate and metadata
From the authentik provider, copy the SAML metadata or download the signing certificate, and record the metadata URL or file for the firewall import. Keep a note of the certificate fingerprint as shown in authentik so you can compare it on the firewall later. The person doing this should be the same administrator who created the provider, so the values match what was configured. The step is done when you have the metadata source saved in a location your firewall administrators can reach, and the fingerprint is written in your change record.
Create the SAML identity provider profile on the firewall
On the Palo Alto firewall, a network administrator creates a SAML identity provider server profile that points to the authentik metadata, either by import or by manual entry of the SSO URL, signing certificate and entity ID. Set the attribute name for group membership if your design uses group claims, and confirm that the firewall's certificate profile trusts the signing certificate. Commit the change in a staging configuration first if your change process allows it. The step is done when the profile saves, and the certificate fingerprint shown on the firewall matches the value you recorded in authentik.
Build the authentication profile for portal and gateway
Create an authentication profile that uses the SAML identity provider profile, then reference it in the GlobalProtect portal and gateway configuration. Keep the portal and gateway on the same profile unless your design separates them, and set the username attribute so that the firewall matches the authentik user identity to its own user records. Document the local emergency access method that remains outside SAML, since a SAML outage should not lock out every administrator. The step is done when the portal and gateway configurations show the new authentication profile and the commit completes.
Assign group-based access policy
Map the authentik group to the GlobalProtect access rules, either through group-based policy on the gateway or through the user group attributes the firewall receives from SAML. Confirm the group name in authentik matches the exact string the firewall expects, because a case or spelling mismatch can deny users who should have access. Limit the group to the users who need VPN access and test a second group to confirm that users outside it are refused. The step is done when a user in the permitted group gets a policy match on the firewall and a user outside it does not.
Confirm login with test accounts
Run a test login from an external client to the GlobalProtect portal using a user from the permitted group, complete authentication in authentik, and confirm the gateway connection. Check the firewall logs for the authentication event and the group attribute, and repeat the test with an account outside the group. If your authentik deployment uses MFA for this application, confirm the second factor is requested during the test. The step is done when both test accounts behave as expected and the logs show the authentication events you planned for.
Applying the authentication profile to portal and gateway
The portal is the first point of contact. Users reach it to sign in, and it hands them the gateway list and client configuration. The authentication profile you assign to the portal decides which SAML identity provider profile handles the first sign-in, so this is where a misconfigured SAML binding usually shows up first. Set the profile on the portal's authentication settings and confirm that the client configuration it returns points to the gateways you intend to use.
- Assignment: Select the authentication profile built on the authentik SAML identity provider profile in the portal's authentication configuration.
- Client configuration: Check which gateways and client settings the portal pushes once authentication succeeds.
- Certificate: Confirm that the portal's server certificate matches the hostname users enter in the GlobalProtect client.
- Group sources: Verify that the group attribute authentik returns is available to any policy that relies on it.
- Test account: Keep a named test user for each change so you can separate portal errors from gateway errors.
Confirm the exact menu paths and field names for your PAN-OS version in the Palo Alto Networks documentation before you change a production portal.
The gateway enforces access once the user is connected. It can use the same authentication profile as the portal, or a different one, and it is the component that applies group-based security policy. A gateway that uses a different profile from the portal may accept a login the portal rejected, or reject one the portal accepted, which makes the failure harder to trace. Many teams set the gateway to the same profile and then add group checks in policy rather than in the profile itself.
- Assignment: Set the authentication profile on each gateway that serves GlobalProtect users.
- Certificate handling: Confirm the gateway certificate and the trust settings it uses for the SAML exchange.
- Group-based access: Map the groups returned by authentik to the security policies and user group objects that control access.
- Multiple gateways: Apply the same profile to every gateway in the same region so users see identical behavior.
- Logs: Note where authentication and policy decisions appear in the firewall logs so you know where to look during an incident.
After each change, sign in with a test user and check the gateway logs for the group the user received.
The deployment model changes where the portal and gateway settings live and who manages them. With on-premises firewalls, you configure the portal and gateways directly on the appliance or in Panorama. With Prisma Access, Palo Alto Networks hosts the service infrastructure, and you configure authentication through the Prisma Access management interface. The authentik side of the design stays the same, but the network path, certificate ownership and log access differ, so the same SAML settings can behave differently in each model.
- Management plane: Confirm whether you use the firewall web interface, Panorama or the Prisma Access console for each setting.
- Certificate ownership: Determine who renews and installs the certificates used by the portal and gateways.
- Network reachability: Confirm that the SAML endpoints on authentik are reachable from the component that performs the exchange.
- Log access: Check which logs you can read directly and which require a support request or a service console.
- Documentation version: Use the documentation for the Prisma Access or PAN-OS release you run, because menu names change between releases.
Ask your Palo Alto Networks account team or implementation partner to confirm which settings are managed in each console for your release.
Using different authentication profiles on the portal and gateway is sometimes valid, for example when a portal serves a broader population than a gateway that enforces stricter groups. The risk is that each component produces its own result, so a user can pass one stage and fail the next with an error that does not name the cause. Consistent profiles mean that a failure points to the attribute, certificate or group that changed, rather than to a difference between two configurations that nobody remembers making.
- Shared profile: Start with one authentication profile for both portal and gateway, then diverge only with a written reason.
- Group checks: Put group restrictions in security policy where possible, so the profile stays simple.
- Change records: Record which profile each component uses and review the record after every upgrade.
- Troubleshooting path: When a user fails, compare the portal log and the gateway log for the same session before you change anything.
- Illustrative case: If a portal accepts a user and the gateway rejects them, the gateway profile or its group mapping is the first thing to check.
Before you deploy, document the expected profile for each component and the group each user type should receive.
Mapping authentik groups and attributes to GlobalProtect access
This table maps each piece of identity data authentik sends in the SAML response to the GlobalProtect decision it supports. Read it as a checklist: confirm each attribute name against the GlobalProtect guide and your firewall configuration before you build policy on it. The main takeaway is that access rules on the gateway are only as precise as the groups and attributes authentik asserts.
| Identity data | What GlobalProtect uses it for | What to confirm before go-live |
|---|---|---|
| Username | Identifies the user in logs, session records and user-based policy matching | Which SAML attribute or NameID carries the username, and that it matches the value your firewall expects |
| Email address | Supports user identification and any mapping that keys on mail-format identities | Whether your firewall configuration reads it, and that it is populated for every user who needs VPN access |
| Group membership | Drives group-based rules on the gateway so that only members of approved groups reach VPN resources | The exact group attribute name, whether groups are sent as names or identifiers, and how nested groups are flattened |
| User-based policy scope | Limits specific users or groups to particular gateway rules, zones or resources | That policy references match the values authentik sends, and that a test user in each group gets the expected rule |
| Attribute mapping in authentik | Converts user and group data from authentik into the assertion attributes the firewall consumes | Mapping names and expressions follow the guide, and each mapping is attached to the SAML provider used by GlobalProtect |
| Users with no mapped group | Should receive no VPN access under a group-based rule unless a default rule is intended | The default rule set on the gateway and whether unassigned users can reach any portal |
| Changes to group membership | Take effect at the next SAML login, so removed users may keep access until their session ends | Your session lifetime settings on both authentik and the gateway, and how you handle revocation for active sessions |
Hardening the SAML trust between authentik and GlobalProtect
The SAML trust between authentik and GlobalProtect is a single point where a certificate, an application assignment or a sign-in policy decides who reaches the VPN. The cards below cover the controls that keep that trust current, narrow and visible. Several of them depend on which authentik edition you run, so check the feature list before you design around it.
Plan signing certificate rotation
GlobalProtect stores the signing certificate from the authentik SAML provider, so a certificate that expires without a replacement in place stops VPN sign-in for every user at once. Record the certificate's expiry date, schedule the new certificate import ahead of it, and confirm with your team how the portal and gateway trust are updated during the change. Test the rotation on a non-production portal first.
Limit which applications and groups sign in
Bind the GlobalProtect application in authentik to an explicit set of groups, and make sure users outside those groups cannot complete the SAML flow. Review group membership on a schedule, because access inherits from whoever is in the group at sign-in. Document which group grants portal access and which grants gateway access, so a change to one does not silently widen the other.
Require MFA at the identity provider
Enforce a second factor inside authentik's authentication flow so that GlobalProtect receives a SAML assertion only after MFA succeeds. Check which second factor types your edition and plan support, because MFA options differ between the open-source and enterprise editions. Test a sign-in from a fresh device and from a user without an enrolled factor to confirm the flow behaves as intended.
Limit the emergency local access path
Keep a local administrator account on the firewall for recovery if the SAML path fails, and restrict it to a named set of administrators with strong, separately stored credentials. Verify that the local path works before you need it, and confirm how the firewall behaves when authentik is unreachable. Record who may use the local account and under what approval.
Audit sign-ins and forward the events
Confirm which sign-in and policy events authentik records for the GlobalProtect application, and forward them to your log platform so failed and successful attempts can be reviewed together. Enhanced audit logging is listed as an enterprise-only feature on the pricing page, so confirm whether your edition covers the events you need. Set a retention period that matches your own policy.
Why GlobalProtect SAML logins fail after setup
This table lists the failures that most often break GlobalProtect SAML sign-in after the authentik setup looks complete, with the likely cause and the first check for each. Work down the rows in order, since a certificate or entity ID problem blocks every later step.
| Failure | Likely cause | First check |
|---|---|---|
| Assertion signature rejected | The signing certificate in the GlobalProtect SAML profile is expired, or it was replaced in authentik without re-importing it on the firewall. | Compare the certificate fingerprint in the authentik provider with the one imported on the firewall, and check its validity dates. |
| Login loops back to the portal | The Assertion Consumer Service URL in authentik does not match the portal or gateway address that GlobalProtect sends in the request. | Confirm the ACS URL in the authentik SAML provider matches the portal FQDN exactly, including the path and https scheme. |
| Unknown audience or entity mismatch | The entity ID configured on the firewall differs from the audience or issuer value authentik expects. | Compare the Entity ID on the firewall SAML profile with the Audience Restriction value in the authentik SAML provider. |
| Assertion rejected as expired or not yet valid | Clock skew between the authentik server, the firewall and the user's device, which pushes the NotBefore or NotOnOrAfter window outside tolerance. | Check NTP status on the authentik host and the firewall, and compare their UTC times against the assertion timestamps in the SAML trace. |
| Login succeeds but group policy does not apply | authentik does not send the group attribute in the assertion, or the attribute name differs from the one the firewall uses for group matching. | Inspect a sample SAML response from authentik and confirm the group attribute name and values match the firewall group mapping. |
| Portal accepts login but gateway rejects it | Portal and gateway point to different authentication profiles, or one profile uses a different SAML identity provider profile. | Confirm both the portal and each gateway reference the same authentication profile, and that it points to the intended SAML profile. |
| Browser shows a certificate warning or fails to load the portal | The portal or gateway certificate does not cover the FQDN users type, or the chain is not trusted on client devices. | Check the certificate subject and SAN values against the FQDN, then confirm the chain is trusted on a clean test device. |
| Users locked out after a configuration change | A partial change left the portal and gateway on mismatched profiles, or a test user lacks the group that the policy requires. | Test with a single known user in the required authentik group and review the firewall system and GlobalProtect logs for the matching failure. |
Testing the integration before users move
Start with a pilot group that represents each access path, not just one admin account. Choose a small set of named users drawn from every authentik group that will reach GlobalProtect, and include at least one user who is expected to be denied. Create dedicated test accounts for each access policy so you can prove both sides of the decision: a permitted user should reach the portal and gateway, and a user outside the group should be stopped at the authentication step. Keep the pilot on a portal and gateway that are not yet the default for production users, so a misconfiguration never blocks the whole workforce. Confirm with your own change process how long the pilot runs and who signs off before the group list expands.
Test the portal and the gateway as two separate logins. A successful portal sign-in does not prove the gateway accepts the same SAML assertion, and each step should be checked from a client on an untrusted network as well as from inside your perimeter. For each test account, record the authentication result, the group-derived access the user receives, and whether MFA was prompted where you configured it. On the Palo Alto side, review the GlobalProtect and authentication logs on the firewall for each attempt. On the authentik side, review the application's authorization events and the SAML provider's activity for the same timestamps. Matching events by time and username on both sides is what tells you where a failure actually happened.
Keep a rollback path that works before you change anything in production. Before the pilot, document the existing access method, whether that is a local GlobalProtect authentication profile, another SAML provider, or a break-glass account, and confirm that someone can use it without authentik being available. Test that path once so you know it works. For change records, retain for each test case the account used, the date and time, the portal and gateway tested, the expected and observed result, the relevant log excerpts from both systems, the authentik and PAN-OS versions in use, and the name of the approver. Store the evidence with the change ticket so an auditor or an incident responder can trace the decision later.
Questions buyers ask about GlobalProtect SAML with authentik
How much does it cost to connect GlobalProtect to authentik over SAML?
The cost depends on the scope agreed in writing, and DeployOpen does not publish a price list, so a quote follows from that scope. The main components are the design of the SAML identity provider profile, the authentication profiles on the portal and gateway, group mapping, MFA design and testing against your real user population. The authentik software is available as open source, but the edition you choose affects what you pay for the platform itself. The authentik pricing page lists Open Source at no cost, Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. Ask any partner to show which edition the quote assumes and which features that edition needs.
How long does a GlobalProtect SAML integration take?
Duration depends on how many gateways, portals and groups are in scope, how much of the firewall configuration already exists, and how long your change process takes to approve a production change. A proof of concept against a test gateway usually moves faster than a cutover for thousands of users, because the rollout includes user communication, a fallback plan and a staged release. No duration is set here because no researched figure supports one. Ask for a timeline in the written scope that lists each phase, its entry and exit criteria, and the change windows you need.
Does the firewall model change the GlobalProtect SAML work?
The SAML concepts are the same across firewall models, but the configuration path, the supported PAN-OS release and the features available on each platform decide how much work the change requires. Confirm the PAN-OS version on every portal and gateway, the SAML options it exposes and the certificate handling it supports before the design is fixed. Also confirm whether your firewalls run in a high-availability pair, because both members need the same SAML settings and a tested failover. Treat these as items to verify against Palo Alto Networks documentation for your release, not as assumptions in the quote.
Is Prisma Access handled differently from an on-premises GlobalProtect gateway?
Yes, the authentication path and the places where you configure SAML can differ between Prisma Access and on-premises gateways, so the scope should name which one you run. With on-premises gateways, you manage the portal and gateway configuration, the certificates they present and the network path from the gateway to authentik. With Prisma Access, part of that configuration sits in the cloud service and some network and certificate decisions change. Confirm with Palo Alto Networks which SAML settings your Prisma Access tenant exposes and whether it can reach your authentik endpoints as required.
How many groups and user populations change the effort?
The number of groups affects both the authentik configuration and the testing. Each group that maps to a different GlobalProtect access level, portal configuration or gateway policy needs a defined source group in authentik, a test user and a documented expected result. Work increases when groups overlap, when users belong to several groups, when contractors or external users need separate treatment, or when group membership comes from an upstream source such as a directory. Ask for a list of groups, their target access and the owner who approves each mapping before the work starts.
How should MFA be designed for GlobalProtect users signing in through authentik?
MFA design sets the user experience, the enrollment burden on the help desk and the failure modes that lock people out. Decide which factors apply to all users, which apply to privileged groups and how recovery works when a device is lost. authentik documents several second-factor types, and the choice of factor should be checked against what your team is willing to support and what the GlobalProtect side accepts in the SAML flow. Test the full sign-in path from the client, including the browser step, the prompt for the second factor and the behavior on a new device.
What certificate work does GlobalProtect SAML require?
Certificate handling is one of the most common sources of delay, because the SAML signing certificate, the portal and gateway certificates and the trust chain all have to match what each side expects. Plan who generates and stores the signing certificate, how it is imported into the firewall, and when it is renewed. Also plan the rotation process, so a renewal does not break sign-in for every user at once. Confirm the certificate lifetime and rotation approach with both the authentik documentation and your own certificate policy before the cutover date is set.
Can our own team run this integration without a partner?
Yes, a team with firewall administration skills and someone who operates authentik can do this work, provided the roles are clear and there is time for testing. The work needs a firewall engineer who knows the PAN-OS SAML and authentication profile settings, an identity engineer who builds the authentik provider, application and group bindings, and a change owner who approves the production window. A partner can take on the design, the test plan and the cutover support under a fixed-scope agreement, which often suits teams that have not run SAML on a firewall before. Ask for the written scope either way so the deliverables and the handover are explicit.
How DeployOpen scopes and delivers GlobalProtect SAML integrations
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including authentik. For GlobalProtect SAML, we agree a written scope first, build the identity provider and gateway configuration in your environment, and hand over the working setup with the notes your team needs to run it.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the GlobalProtect portal and gateways, the authentik version and hosting model, and the groups that map to VPN access.
- We confirm how your SAML signing certificate, user directory and existing VPN policies will connect to authentik before quoting.
How we build
- We configure the authentik SAML provider and application for the portal and gateway entities in a staged test environment first.
- Authentication profiles on the GlobalProtect portal and gateway are set up and checked against your group-based access rules.
- We test login, MFA behavior where your design uses it, group denial, and fallback access for administrators in a defined test plan.
How we hand over
- You receive the configured authentik and GlobalProtect settings, with a record of each group, profile and certificate used.
- Runbooks cover certificate renewal, adding users to groups, and the steps to roll back a failed change.
- Written test results and open items are delivered so your team and auditors can trace what was changed and verified.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover authentik version upgrades and re-testing of the GlobalProtect login path after each planned change.
- Ask any partner for the support scope, response expectations and change process in writing before you sign.
