Signing Palo Alto firewall administrators in through authentik over SAML
Teams that want firewall administrators to sign in to the Palo Alto Networks next-generation firewall web interface with their central identity rather than local accounts can use authentik for this. authentik publishes an integration guide for Palo Alto Networks NGFW that configures SAML single sign-on for the firewall's web interface, so the work is a documented SAML setup rather than a custom build. The guide is the starting point, but treat it as a reference to confirm against the current authentik page and the PAN-OS version you run, since SAML field names, certificate handling and menu paths can change between releases.
The integration covers how an administrator authenticates to the management interface. It does not decide what that administrator can do once signed in. Role assignment, which the firewall maps from SAML attributes or groups, is where most of the design work sits, and it is covered in the next section. It also does not govern device policy, and it does not control VPN user access, which is a separate SAML flow handled on the GlobalProtect and VPN pages. Keeping these boundaries clear matters because an administrator who can sign in through authentik may still have no role on the firewall, and a VPN user should never be able to reach the management interface.
Before you start, confirm three things with your own environment: which PAN-OS release is running on each firewall, whether your authentik version is one that receives security fixes, and whether your change process allows the SAML login to be enabled on production devices before a tested break-glass path exists. Plan a local emergency administrator account and test it while SSO still works, so a failed SAML configuration or an identity provider outage does not lock your team out of the device.
What a working authentik and PAN-OS setup needs before configuration
Most failed SAML logins to a firewall trace back to decisions made before anyone opens the admin console. The cards below cover the authentik version, the firewall's network identity, clock alignment, certificates and the admin group design that the SAML configuration depends on.
Agree the authentik version
Deploy a release from a branch the project still patches. The security policy lists 2026.5.x and 2026.8.x as supported for security fixes, and the project announces security releases at least 24 hours ahead. Confirm the exact patch level you will run against the current release list, and plan a maintenance window for each security release because the firewall login path depends on it.
Give the firewall a stable FQDN
The SAML application, the assertion consumer URL and the firewall management certificate all reference the management hostname. Pick a fully qualified name that will not change, publish it in DNS, and confirm that administrators reach the web interface by that name. A changed hostname later means updating the authentik provider, the firewall SAML profile and the certificate together.
Align time on both sides
SAML assertions carry validity windows, so a drifted clock on either authentik or the firewall can reject valid logins. Confirm that the authentik host and the firewall synchronize to the same reliable time sources, and check the firewall's system clock before testing. Clock problems often look like generic authentication failures, so verify time first when a login is rejected.
Plan the signing and management certificates
Two certificate tasks run in parallel. authentik signs assertions with a key pair that the firewall must trust, and the firewall presents its own management certificate to browsers. Decide who owns each certificate, where the private keys are stored, how renewal is scheduled, and how a replacement will be rolled out without locking out administrators.
Size the authentik host baseline
The Docker Compose guide positions Compose for test setups and small-scale production, with at least 2 CPU cores and 2 GB of RAM. The server and worker containers depend on PostgreSQL, which stores all configuration and data except uploaded files. For production, confirm whether your environment needs a separately managed PostgreSQL and who backs it up, because losing that database loses the SAML application definition.
Design the admin group model first
Decide which authentik groups map to which PAN-OS administrator roles before building anything. List each administrator population, the role it needs on the firewall, and the group that grants it. Also decide who keeps a local emergency administrator account and how that account is protected, so a broken SAML configuration does not remove all administrative access.
How to configure the SAML application, certificate and admin roles in order
This sequence takes you from an authentik SAML provider for the firewall to a working administrator login on PAN-OS, with the signing certificate trusted, the role attribute mapped and a local emergency administrator kept in place. Each step closes with a check you can run before moving on.
Create the SAML provider and application in authentik
Using the authentik Palo Alto Networks NGFW guide as the baseline, create a SAML provider and an application in authentik for the firewall management interface. Set the Assertion Consumer Service URL, entity ID and name ID settings to the values the guide and your PAN-OS management hostname require, and bind the application to a dedicated group of firewall administrators rather than to all users. Confirm the provider saves with the expected entity ID and that the application appears only for the intended group.
Export and import the signing certificate
Export the signing certificate and metadata from the authentik SAML provider, then import the certificate into PAN-OS under the device certificate store so the firewall can validate assertions. Record the certificate name, fingerprint and expiry date in your change record, because a rotated certificate in authentik will break logins until PAN-OS is updated. Confirm the certificate appears in PAN-OS with a valid status and the expected fingerprint.
Configure the SAML identity provider server profile
On PAN-OS, create a SAML identity provider server profile that points to the authentik entity ID, single sign-on URL, and the imported certificate. Set the identity provider to validate signed assertions and confirm the single logout behavior your team expects. Commit the change to a candidate configuration first, then verify that the profile shows the correct endpoints and certificate reference before committing.
Build the authentication profile and attach it to the management interface
Create an authentication profile on PAN-OS that uses the SAML server profile, and set it as the authentication method for the web management interface. Decide whether local administrator accounts remain valid for login at this stage, since that choice determines the emergency access path you test in a later step. Confirm the profile is listed on the management settings page and that the change is staged for commit.
Map the administrator role from the SAML attribute
Add a role attribute to the authentik SAML property mappings that carries group membership, then configure PAN-OS to read that attribute and map each value to an administrator role such as superuser, read-only or a custom role. Keep the attribute names and values identical on both sides, because PAN-OS matches them exactly. Confirm this by decoding a test SAML assertion or reviewing the authentik preview, and check that each test group maps to the role you intended.
Test with a non-admin account before enabling all administrators
Sign in to the firewall web interface with a test account that belongs to a group mapped to a limited role, and confirm that the session opens with that role and no more. Also confirm that an account outside the mapped groups is refused. Check the PAN-OS system logs for the authentication event, and review the authentik event log for the matching login. Do not proceed until the limited role, the denial case and the log entries all match your expectations.
Keep a local emergency administrator and enable for all admins
Before you move production administrators to SAML, keep at least one local emergency administrator account on PAN-OS with a strong password stored under your break-glass process. Confirm that the local account still signs in with the SAML authentication profile in place or disabled, as your design requires. Only after that check passes, extend the SAML group to the full administrator population and record the final role mappings in your configuration documentation.
Mapping authentik groups and attributes to PAN-OS administrator roles
This table pairs each PAN-OS administrator role with the authentik group or SAML attribute value that should grant it, plus the approver for each mapping. Read it as a starting design: confirm every role and attribute string against your firewall's admin role profiles and your authentik SAML assertion before going live.
| Role on the firewall | authentik group or attribute value | Who approves the mapping | Notes |
|---|---|---|---|
| Superuser | Group pan-superusers mapped to role value superuser (illustrative) | Firewall owner and security lead | Limit to named break-glass or platform administrators; confirm the exact role string PAN-OS expects in the SAML role attribute. |
| Read-only | Group pan-readonly mapped to role value read-only (illustrative) | Security operations manager | Suits auditors and monitoring staff; verify that the read-only role matches the vsys or device scope you intend. |
| Device administrator | Group pan-deviceadmin mapped to role value deviceadmin (illustrative) | Network engineering lead | Scope to specific device or virtual system roles; check that the name matches the custom role profile on the firewall. |
| Custom admin profile | Group pan-custom-<profile> mapped to the exact custom profile name (illustrative) | Security architect with change board sign-off | Profile names are case sensitive; a single character mismatch can deny access or fall back to a default role. |
| No matching group | No role attribute in the assertion | Not applicable (denial by design) | Deny sign-in for users with no mapped group rather than assigning a broad default role; confirm how the firewall handles an empty role attribute in your PAN-OS version. |
| Attribute name in SAML assertion | Attribute name configured in both authentik property mapping and PAN-OS SAML server profile | Identity team with firewall owner | Attribute names must match exactly, including case; check the authentik SAML provider documentation and the Palo Alto integration guide. |
| Emergency local admin | Local firewall account, not mapped to authentik | Firewall owner and CISO | Keep outside SAML so access survives an authentik outage; store credentials under dual control and test the login periodically. |
Why a local emergency admin must stay in place
Keep one local administrator account on the firewall even after SAML sign-in works, because the SAML path depends on several moving parts at once: the authentik server and its outpost, the network route from the administrator's browser to both the firewall and authentik, the certificates that sign and verify the SAML messages, and clock alignment between the firewall, authentik and the browser. A failure in any one of them, such as an expired signing certificate, a changed metadata URL or a firewall that drifts out of time sync, can leave every administrator unable to sign in to the management interface. The local account is the way back in when that happens, and it should be the only path that does not rely on authentik. Store the credential offline and make it strong enough that it is not reused anywhere else. Keep the password in a sealed record held by two or more named people, in a location that does not depend on the firewall or the identity platform being available. Confirm the account's role on the firewall with your own team, and decide whether it is limited to the minimum rights needed to repair SAML settings or is a full superuser account. Record the password's creation date and rotation trigger so the record stays accurate after each change.
Test the account on a fixed schedule rather than assuming it works. The test should sign in through the local login page, confirm the role, and sign out, and it should be done in a maintenance window with a change record. Pair it with a check that the SAML sign-in still works, so you know which path is healthy. Each use of the account, including tests, should generate a ticket or log entry that states who opened the sealed credential, why, what was changed and when the SAML path was restored. Confirm with your firewall vendor and your log pipeline how local logins are recorded so that break-glass use is visible to your security team. Treat this account as a break-glass control under your organization's own access policy, not as a convenience account. Your access management standard should define who may use it, the approval or notification needed before use, how long the credential may stay unrotated, and how the account is reviewed in access recertification. Auditors and your own security team will ask for evidence that the control exists and works, so keep the test records and usage logs with the firewall configuration. DeployOpen can help prepare these controls and evidence, but the policy and its approvers belong to your organization.
Hardening the firewall admin login
Signing firewall administrators in through authentik moves the password and second factor out of the firewall, but the firewall's own management plane and the SAML trust remain in your hands. The cards below cover the controls that connect the identity provider, the firewall and your emergency access path, and the checks to make before each one goes live.
Enforce MFA in the authentik flow
Palo Alto Networks does not check the second factor for SAML logins. The MFA requirement has to be enforced in the authentik authentication flow bound to the firewall's SAML application, and only the administrator group should reach that flow. Test with an account that has no second factor enrolled to confirm the sign-in is refused rather than falling through to a weaker stage. Confirm which factor types your edition and your identity policy allow before you write the requirement down.
Restrict management access by source network
Single sign-on controls who can start a login, not where the login request comes from. Limit the firewall management interface to a dedicated management network or a short list of administrator source addresses, and keep it off internet-facing interfaces. Check that the SAML redirect and the assertion consumer path work from those addresses, so that a narrow network rule does not lock every administrator out during a provider outage.
Plan signing certificate rotation
The firewall trusts the authentik signing certificate that you import into its SAML identity provider profile. Record the certificate's expiry date, the owner of the rotation, and the window in which you will import a replacement certificate on the firewall before the old one stops validating. Test the new certificate on a non-production firewall or a spare administrator profile first. A rotation that is planned in advance avoids a sign-in outage on the day the old certificate expires.
Protect the local emergency admin
Keep at least one local administrator account on the firewall that does not depend on authentik, so you can recover if the identity provider, the SAML certificate or the network path fails. Store its credentials in a sealed, audited location, give it a strong unique password, and restrict it to the management network. Test it on a schedule and record each use, because an emergency account that nobody has tried is often not usable when it is needed.
Audit administrator sign-ins
Decide which sign-in events you need as evidence: successful and failed authentications from authentik, role assignments the firewall applied, and local emergency account logins. Enhanced audit logging is listed as an Enterprise-only feature on the authentik pricing page, so confirm which logs your edition provides before you design the retention and forwarding process. Forward firewall system logs to your central log platform and test that a failed MFA attempt is visible there.
Schedule for security releases
authentik's security policy states that security releases are announced at least 24 hours in advance, which gives you a short notice period rather than a planning window. Subscribe to release announcements, keep a standing change slot that can absorb an urgent patch, and confirm that the supported version line you run still receives fixes. Test each authentik upgrade against the firewall SAML login in staging before it reaches production.
Why SAML admin login fails and how to fix it
This table lists the failures teams most often hit when signing firewall administrators in through authentik over SAML, with the likely cause and the fix for each. Read it before go-live and again when a login breaks, and note the final row, which covers the emergency admin route.
| Failure | Likely cause | Fix |
|---|---|---|
| Assertion signature rejected | The wrong signing certificate was imported on the firewall, or the certificate was rotated in authentik without updating the firewall | Export the current signing certificate from the authentik SAML provider and re-import it on the firewall, then confirm the certificate name matches the identity provider profile |
| Assertion expired or not yet valid | Clock skew between the firewall, authentik and the browser client, so the assertion timestamps fall outside the allowed window | Synchronize all three systems to a trusted NTP source and check the firewall's system time before changing SAML settings |
| Entity ID or ACS URL mismatch | The entity ID or assertion consumer service URL on the firewall does not match the values configured in the authentik application, often after a hostname change | Copy the entity ID and ACS URL from the firewall's SAML configuration into the authentik provider exactly, including scheme, host and trailing characters |
| Role attribute missing | The SAML attribute mapping in authentik does not send the admin role attribute, or the attribute name differs from what the firewall expects | Add or correct the attribute mapping in the authentik SAML provider, then test with a single user and inspect the assertion before widening access |
| Role attribute named differently | The firewall matches a specific attribute name or value, and authentik sends a similar name with different casing or a different group string | Align the attribute name and group values character for character on both sides, and document the mapping in your change record |
| User lands with no role | The login succeeds but no administrator role matches the assertion, so the account has no effective privileges | Confirm the group or role value in the assertion, map it to an administrator role on the firewall, and decide whether an unmapped user should be denied rather than allowed in with no role |
| Lockout when SAML is the only admin path | The local administrator account was removed or disabled, or its password is unknown, and the SAML provider is unavailable | Keep a local emergency administrator with a tested password stored under your break-glass procedure, and verify it can sign in before enabling SAML for all administrators |
| Recovery route for any failure | SAML cannot be fixed from the browser because the identity provider or firewall configuration is broken | Sign in with the local emergency administrator, revert the SAML profile to the last working configuration, and troubleshoot from the logs on both sides |
Questions teams ask before configuring firewall admin SSO
Is the open-source edition of authentik enough for Palo Alto firewall admin SSO?
The SAML sign-in itself is part of the open-source code base, which the project distributes under the MIT license, but the decision depends on the features you need around it. The authentik pricing page lists the Open Source edition as free with community support only, while the Enterprise edition adds features such as mTLS client certificate authentication, enhanced audit logging and ticket-based support. Check the license file in the repository, because code in the enterprise directory falls under a separate license. Before you commit, list your requirements: whether you need certificate-based authentication for administrators, audit records that meet your change control, and a support route you can escalate to. Confirm each item against the current pricing page and the license text, and confirm with the PAN-OS documentation that your firewall model and version support the SAML options you plan to use.
How long does firewall admin SSO take to configure and what drives the effort?
The effort depends less on the SAML steps themselves and more on the decisions made before them. The main drivers are the number of administrator roles you map from authentik groups or attributes, the number of firewalls and Panorama instances that need the same profile, and the change control your organization requires for each firewall. A single firewall with two or three roles is a small piece of work. Many firewalls with separate read-only, auditor and superuser roles, plus a tested break-glass path, take longer because each change needs review and a rollback plan. Ask any partner for a written scope that lists the firewalls, roles, test cases and maintenance windows, and tie the schedule to those items rather than to a generic duration.
What must our team provide before the integration work starts?
Prepare four inputs before anyone changes a firewall. First, the authentik groups that will map to each PAN-OS administrator role, with named owners who approve membership. Second, the signing certificate and the certificate chain your firewalls will trust, along with a plan for renewal. Third, a dedicated test account that is a member of each role group, so you can prove every role works before production users rely on it. Fourth, a maintenance window for each firewall, plus a rollback procedure. Also confirm who can edit the authentik application and who can edit the firewall configuration, because separating those duties is a common audit question.
Can our internal engineers configure firewall admin SSO on their own?
Yes, a team that already runs authentik and PAN-OS can usually do the work in-house, provided it has someone comfortable with SAML metadata, certificates and role design on the firewall. The risk lies in the lockout path. A mistake in the SAML profile or the role mapping can stop every administrator from signing in, so the team needs a tested local emergency administrator and a documented way to recover it. A partner can supply an independent review of the design, a written test plan and hands-on implementation under your change control. Decide based on your in-house SAML experience, how many firewalls you run, and whether you have a second person to verify each change before it reaches production.
How do we keep a local emergency administrator without weakening SSO?
Keep at least one local administrator account that does not depend on authentik, and store its credentials under your privileged access process. Limit it to break-glass use, monitor every login, and test that it works during each planned change, not only during an outage. Document who may use it, how the credentials are rotated after use, and how the event is reported. The account must be kept separate from the SAML role mapping so that a broken identity provider cannot remove every path into the firewall. Your security team should confirm the design against its own access control standard before production.
What ongoing work follows an authentik or PAN-OS upgrade?
Any upgrade of authentik or PAN-OS can change the SAML behavior, the certificates or the attribute names that your role mapping depends on, so each upgrade needs a regression test. Before upgrading, review the release notes for both products and check the security policy for supported versions and advance notice of security releases. Then retest a successful sign-in for each administrator role, a denied sign-in for a user without a role, the emergency local account, and the certificate expiry date. Plan the work as a recurring task with a named owner. If you engage a partner for ongoing support, define in the written scope which upgrades, tests and documentation updates are included.
What should we ask a partner for in a quote for firewall admin SSO?
Ask for a written scope that names each deliverable: the authentik SAML application and provider configuration, the PAN-OS SAML profile and role mapping for each firewall, the test plan, the emergency access design, the runbook and the handover. Ask which items are one-time and which recur, such as upgrade testing or certificate renewal support. Ask what the quote assumes about your environment, including the number of firewalls, Panorama use, change windows and who approves changes. Also ask what the quote excludes, such as licensing of authentik Enterprise features or PAN-OS subscriptions, so you can compare offers on the same basis.
What this page does not cover
This page covers administrators signing in to the Palo Alto Networks firewall web interface. It does not cover employees connecting to the firewall through GlobalProtect. That VPN login is handled in the separate page on authentik and Palo Alto GlobalProtect SAML integration, which covers the SAML identity provider profile, the authentication profiles on the portal and gateway, and group-based access. Keep the two integrations apart on purpose. Each uses its own SAML application, its own signing certificate and its own group logic, so a change to administrator role mapping should never alter who can reach the VPN. Before you build either one, confirm which SAML application each login path uses and who owns changes to it.
The same separation applies to other vendors. Administrator sign-in to FortiGate and Cisco Secure Firewall Management Center each has its own page, and so does SSL VPN access on FortiGate. Role names, admin profiles, MFA options and group attributes differ between these products and between the Palo Alto admin and VPN features. Do not copy settings from one device guide to another without checking the vendor's current documentation for the exact version you run. If your firewall estate mixes vendors, build a short table of which identity source, application and role model applies to each management interface.
Some network devices cannot use SAML or OIDC at all. VPN appliances, switches and other equipment that speak only RADIUS need a different design, and the page on VPN login with MFA through authentik RADIUS covers PAP-only password authentication, appending a second factor to the password, and why SMS codes do not work in that model. Wi-Fi and wired 802.1X clients, LDAP-based appliances such as pfSense and OPNsense, and mesh networks such as Tailscale, Headscale and NetBird each have dedicated pages in the network and VPN hub. If the Palo Alto admin account you are planning cannot use SAML, look at those pages first and confirm the protocol your device actually supports.
How DeployOpen scopes and delivers authentik SSO for firewall administrators
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure. For authentik and Palo Alto firewall administrator SAML login, we start from a written scope that names the firewall models, the authentik deployment and the admin roles to be mapped, then build and hand over the configuration in your environment.
How we scope
- Confirm which Palo Alto Networks firewalls and PAN-OS versions need administrator SAML login, and which management interfaces are included.
- Agree the authentik groups or attributes that map to each firewall administrator role, and who approves changes to them.
- Define how the local emergency administrator is kept, stored, tested and excluded from routine sign-in, in the written scope.
How we build
- Configure the authentik SAML provider and application for the firewall, with signing certificate handling documented as built.
- Set up the SAML server profile and admin role mapping on the firewall, then test each role with named test accounts.
- Test MFA enforcement at the identity provider, failed sign-in behavior and the local emergency admin login before go-live.
How we hand over
- Deliver a configuration record covering provider settings, attribute mappings, role assignments and certificate renewal dates.
- Provide a runbook for adding administrators, rotating the signing certificate and recovering from a lockout.
- Document the evidence of testing so your security team and any independent auditor can review the access model.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer, and a quote follows from the written scope.
- Ask for a quote that separates one-time build effort from recurring support, upgrades and retest work.
