authentik JFrog Artifactory SAML SSO setup

How authentik signs users into JFrog Artifactory over SAML

A platform team that wants engineers to sign in to Artifactory with their authentik accounts needs two things at once: browser sign-in through SAML for people, and credentials that build tools can use without a browser login. The authentik integrations catalog documents SAML sign-in to JFrog Artifactory, and its Artifactory guide is the supported method this page follows. The work spans four areas: the authentik side of the SAML provider, the Artifactory license that enables SAML, the mapping of authentik groups to Artifactory permissions, and the issuance of API tokens for pipelines after SSO is in place.

Start with the license, because it decides whether the integration is possible at all. The guide states that SAML SSO requires a Pro X, Enterprise X or Enterprise+ license on self-hosted installations, or Enterprise X or Enterprise+ on JFrog Cloud. Confirm the exact tier with JFrog before you design around SAML, since a Pro or lower tier would change the plan. Ask your JFrog contact to put the tier, the number of servers or the SaaS consumption it covers in writing, because the subscription is a recurring cost that will outlast the initial setup.

Then settle the group model before you touch the Artifactory side. Decide which authentik groups correspond to which Artifactory roles and repository permissions, and who owns that mapping after go-live. Plan the API token process separately: pipelines should receive scoped, rotatable credentials issued under a service identity rather than a personal login, and you should confirm with the guide and JFrog documentation how tokens are created and revoked in your version. Test sign-in with a group that has limited access first, so a mapping mistake does not grant broad repository rights.

What you need before you configure SAML

Most SAML delays come from decisions made before anyone opens the authentik admin interface. Confirm the JFrog license tier, the authentik release branch, the endpoints and the group structure first, because each one shapes the SAML provider and the role mapping that follow.

License tier that includes SAML

The authentik Artifactory guide requires Pro X, Enterprise X or Enterprise+ on self-hosted Artifactory, or Enterprise X or Enterprise+ on JFrog Cloud. A Pro or Pro X subscription on SaaS does not qualify for SAML SSO under that guide. Ask JFrog to confirm the tier in writing against your deployment model before scheduling the build, since the lower tiers are the ones most often bought for other reasons.

authentik release branch

Confirm your authentik server and worker containers run a version on the 2026.5.x or 2026.8.x security branch, which are the versions the project lists as receiving security fixes. The project announces security releases at least 24 hours ahead, so your change window should allow for an unscheduled patch. Check the release notes for your target version before you start, since the integration steps depend on the provider settings in that release.

Reachable HTTPS endpoints

Both systems need stable HTTPS URLs that users and browsers can reach. The authentik side hosts the SAML identity provider endpoints, and the Artifactory side receives the assertion consumer callback. Decide the public hostnames now, confirm that the Artifactory base URL in its system settings matches the one you will register, and confirm that any reverse proxy passes the headers and body sizes SAML responses require. A mismatch here produces redirect loops and signature errors that look like certificate problems.

DNS and certificate ownership

Name the owner of each hostname and the certificate that serves it, and confirm the chain is trusted by the browsers and CI runners that will sign in. Decide who holds the SAML signing certificate, where its private key is stored, and when it expires, because rotating it later requires updating the metadata on the Artifactory side. Ask your internal PKI team whether private CA roots must be distributed to build agents.

Group structure for role mapping

Design the authentik groups that will map to Artifactory roles before you configure the attribute statement. For example, a jfrog-readers group could map to read-only access and a jfrog-release-engineers group to deploy rights on release repositories (illustrative names). Keep one group per role, avoid nested groups that a SAML attribute will not flatten, and agree with the repository owners who approves membership changes.

Plan for build tool tokens

SAML covers interactive sign-in to the Artifactory UI, but CI jobs and package managers need separate credentials. Decide now which pipelines will use access tokens, who creates them, and how they are stored in your secret manager. Confirm with JFrog which token types your tier provides and how long they remain valid, so that the post-SSO setup does not depend on a shared personal account.

Which license and deployment path fits SAML sign-in

The authentik Artifactory guide states that SAML SSO on self-hosted installations requires a Pro X, Enterprise X or Enterprise+ license. Pro X is the entry point for the self-managed route that includes SAML, so it is the lowest-cost self-hosted option for this integration. JFrog's pricing page lists self-managed Pro X starting at $27,000 per year for one server. That figure is a starting price, and the final cost depends on the scope agreed with JFrog.

Starting price: Pro X starts at $27,000 per year for 1 server, according to JFrog's pricing page.
Recurring cost: The license is an annual subscription, so it recurs every year after the first purchase.
Infrastructure: Your team or your partner runs the servers, storage, database and backups in your own environment.
Scale limit: Pro X covers one server. High availability with three servers requires Enterprise X.
Upgrade pressure: Self-managed versions are supported for 18 months from each initial minor release, so plan regular upgrades.

Before you commit, confirm with JFrog that the Pro X license covers the SAML feature set your authentik design needs, and confirm the server count your availability target requires.

Configuring the SAML provider and Artifactory in order

This sequence connects authentik to a JFrog Artifactory instance over SAML, so users sign in with their authentik accounts and receive Artifactory roles from their groups. Each step ends with a check you can record before moving on, and the final check confirms that a local administrator can still sign in if the identity provider is unavailable.

Confirm the JFrog license includes SAML
Before you change any sign-in settings, confirm with your JFrog account team that your subscription includes SAML SSO. The authentik Artifactory integration guide requires Pro X, Enterprise X or Enterprise+ on self-hosted installations, and Enterprise X or Enterprise+ on JFrog Cloud. Ask for that entitlement in writing and keep it with the order record. Done when the tier is confirmed in writing and matches your deployment type.
Create the SAML provider and application in authentik
A platform engineer in authentik creates a SAML provider and an application linked to it, using the field names and options in the authentik Artifactory integration guide. Give both objects clear names so the sign-in is easy to identify later, and bind the authorization flow the guide specifies. Confirm each field name against the guide for your authentik version before saving. Done when the application appears in the authentik application list and the provider shows as bound to it.
Export the metadata and signing details
From the authentik provider, export the SAML metadata or copy the endpoints and signing certificate the guide specifies. Store the file in your change record, and keep any private key material out of tickets and chat channels. Open the exported metadata and check that it contains the entity identifier, the single sign-on endpoint and a signing certificate that matches the one shown on the provider page. Done when those three values are recorded and checked.
Configure SAML in Artifactory with matching endpoints
An Artifactory administrator enters the SAML settings in Artifactory, using the endpoints and certificate from the previous step and the field names in the integration guide. Copy the entity identifier exactly as authentik publishes it, since any difference will stop the sign-in handshake. If you have a non-production instance, apply the configuration there first. Done when the SAML sign-in option appears on the Artifactory login page and the saved values match the exported metadata.
Set the attribute and group claims
In authentik, map the user attributes and group membership that the guide says Artifactory needs, such as the username and email, and include a group claim so Artifactory can assign roles. On the Artifactory side, map each authentik group to the matching group or role described in the guide. Use identical group names on both sides and confirm in the guide whether matching is case-sensitive. Done when a test response from authentik shows the expected attributes and group values, and the Artifactory mapping lists them.
Test sign-in with a non-admin account
Choose a standard user in authentik who belongs to one mapped group, then sign in to Artifactory through SAML from a private browser session. Confirm that the user lands in Artifactory with the repository access that group should provide and no administrative rights. Keep the test account and the expected access in your records so you can repeat the test after each change. Done when the login succeeds, the user sees only the expected repositories and administration pages are refused.
Confirm the administrator path still works
Before you require SSO for all users, confirm that a named local administrator account in Artifactory can still sign in without SAML. Test it in a separate browser session while the SAML configuration is active, and record where the credential is stored and who can reach it. Repeat this check after every configuration change or upgrade. Done when the local administrator signs in successfully and the recovery steps are written down for your on-call team.

How authentik groups map to Artifactory roles

This table compares each identity element authentik sends to Artifactory with the Artifactory object it lands in, who decides the mapping and what goes wrong if it is set incorrectly. Read it row by row before you enable SAML for any group, because the admin-role row carries the most risk. Attribute names and group handling must be confirmed in the authentik Artifactory guide and in your own environment before you test.

Element	Destination and decision owner	Risk if the mapping is wrong
authentik user identity (NameID)	Artifactory user account. Confirm in the guide which identifier authentik sends as NameID and whether Artifactory matches it to an existing account. Decided by the platform team with the identity owner.	Duplicate accounts are created, or an existing local account is taken over by a federated user with the same name.
Username	Artifactory username on first SAML sign-in. Confirm the attribute name and whether usernames are case sensitive in your environment. Decided by the platform team.	Users cannot sign in, or a username collision maps a person onto another person's repository history and API tokens.
Email address	Artifactory user profile email, used for notifications and sometimes for matching. Confirm the attribute name in the guide. Decided by the identity team.	Password reset and alert mail go to the wrong mailbox, and an email change in authentik may not update the existing Artifactory account.
authentik groups sent as SAML group attributes	Artifactory group membership on sign-in. Confirm the attribute name and whether the group list is replaced or merged at each login. Decided jointly by the identity and platform teams.	Users keep groups they no longer belong to, or a group name in authentik matches a broader Artifactory group than intended.
Artifactory groups and permission targets	Repository read, deploy and delete rights through permission targets. Decided by the repository owners, with approval from security for production repositories.	Developers can overwrite release repositories, or build agents can publish to repositories they should only read.
Admin-role assignment	Artifactory administrator rights. Confirm in your environment whether admin status can be granted from a SAML group or must stay manual. Decided by the security lead and kept to a named, short list.	A single broad authentik group mapped to admin gives every member control over users, licenses, permissions and system settings, which is the highest-impact error in this table.

Giving build tools access after SSO

SAML signs people into Artifactory's web interface, but CI runners, deployment jobs and package clients need their own credentials. The cards below cover how to separate those machine paths from the human SSO session, from token choice and scope to storage and version checks.

SAML covers people, not pipelines

SAML sign-in through authentik governs interactive logins to the Artifactory UI. It does not authenticate docker push, npm publish or Maven deploys run by a runner, because those clients do not open a browser session. Plan a second credential path before cutover so builds do not stop when SAML is enabled. Confirm which clients in your estate need a non-interactive credential.

Choose the token type for your version

Artifactory offers several token types for API and package access, and their availability, scope options and creation paths can differ between releases. Check the token documentation for the exact Artifactory version you run, including whether tokens can be restricted to specific repositories and whether they can be created through the API. Record the chosen type in your design document.

Scope every token narrowly

A build token should reach only the repositories its pipeline reads or writes, with write access limited to the release or snapshot repositories that job publishes to. Avoid administrator-scoped tokens in pipelines. Ask the vendor or your own testing to confirm which permission targets a given token type can carry, since scope options vary by type and release.

Set expiry and a rotation routine

Decide the maximum lifetime for each token before it is issued, and attach an owner and a rotation date to it. Automate rotation where your pipeline platform supports it, and test that a rotated token works in every job that uses it. Confirm with JFrog whether the token type you choose supports expiry settings and revocation through the API, because that determines how you respond to a leaked credential.

Store tokens in the CI secret store

Keep build tokens in the secret store of your CI platform or a dedicated secrets manager, never in repository files, job logs or container images. Mask them in logs and restrict which branches or protected environments can read them. Review who can edit these secrets, because anyone who can change a pipeline definition can often read the secrets it uses.

Separate service identities from people

Create dedicated service users for each pipeline or team instead of issuing build tokens under a named engineer's account. A service identity keeps audit trails readable, survives staff changes and can be disabled without affecting people. Build tools must not reuse a human's SSO session or personal token, because removing that person would break builds and widen what the pipeline can reach.

Common SAML and token failures and how to fix them

This table pairs the failures teams most often hit after switching Artifactory to authentik SAML with the likely cause, the check to run and the fix. Work down the rows in order, since a broken assertion or missing license blocks every later step. Confirm each setting against the authentik Artifactory guide and your own JFrog license tier before changing production.

Failure	Likely cause	Check and fix
Sign-in loops or assertion errors	The ACS URL, entity ID or signing certificate in the authentik SAML provider does not match what Artifactory expects, or the clock on either side is skewed.	Compare the entity ID and assertion consumer URL in the authentik provider with the SAML settings in Artifactory, copy the signing certificate again, and confirm both hosts sync time. Re-test after each change.
Users sign in but get no roles	The group attribute is missing from the assertion, or it is named differently from the group names Artifactory maps to permissions.	Inspect a SAML response from a test login, confirm the attribute name and values, then align the authentik property mapping and the Artifactory group mapping. Group names are case sensitive in practice, so match them exactly.
Admins locked out after the switch	Local admin login was disabled or the SAML-mapped account has no administrator group, so no one can change the settings back.	Keep one break-glass local administrator, verify its password before cutover, and confirm an SSO user with admin rights exists. Recover by signing in with the local account and correcting the mapping.
SAML option missing from the admin console	The installed license does not include SAML SSO. The authentik guide requires Pro X, Enterprise X or Enterprise+ on self-hosted installations, or Enterprise X or Enterprise+ on JFrog Cloud.	Check the license tier in the Artifactory admin console and with your JFrog account team. Upgrade the license or plan before configuring SAML, rather than trying to work around the missing option.
Build pipelines fail after moving to SSO	Pipelines were using a user session or a password tied to an individual login, which SAML does not issue for automated clients.	Create API tokens or access tokens for each service identity, store them in the CI secret store, and update the pipeline credentials. Test a pull and push with a non-interactive client before retiring the old credential.
Token expires and builds stop intermittently	Tokens were issued with a lifetime or scope that does not match how long or where the pipeline runs.	Review token scope and expiry in Artifactory, set a rotation schedule, and add a failed-auth alert to the pipeline. Confirm the expiry policy with your JFrog administrator.

What buyers ask before outside help on Artifactory SSO

Which JFrog Artifactory license includes SAML sign-in from authentik?

SAML single sign-on from authentik to Artifactory requires a Pro X, Enterprise X or Enterprise+ license on self-hosted installations, according to the authentik integrations catalog entry for JFrog Artifactory. On JFrog Cloud, the guide lists Enterprise X or Enterprise+. Confirm the exact tier with JFrog before you buy, because a Pro or standard SaaS plan will not carry SAML under that requirement. Your authentik edition matters too: the SAML provider type itself is part of the open-source code base, but confirm the feature set for your authentik edition against the pricing page before you assume it covers your use case.

What drives the cost of the Artifactory side of this project?

The JFrog subscription is the largest recurring cost, and it is set by the deployment model and tier. JFrog lists self-managed Pro X from $27,000 per year for 1 server, and Enterprise X from $51,000 per year for 3 servers with high availability, repository federation and SSO. SaaS Enterprise X starts at $950 per month with 125 GB of consumption included. Storage and data transfer both count toward SaaS consumption, so CI pipeline egress adds to the bill. Security bundles such as Unified Security on Enterprise X and Enterprise+, and Ultimate Security on Enterprise+, raise the price above the base subscription if you need software composition analysis or curation. DeployOpen does not publish prices. A quote follows the written scope, which should state the JFrog tier, server count, expected consumption and any security bundles.

How long does Artifactory SAML integration take?

The duration depends mainly on how many groups need mapping and how many environments you run. The SAML configuration itself is a small part of the work. Most of the time goes to agreeing which authentik groups map to which Artifactory roles, testing sign-in with real accounts in each environment, and handling exceptions for service accounts and build pipelines. A single production instance with a short, agreed group model is simpler than a setup with separate test, staging and production instances, each with its own redirect settings. No timeline is given here. The written scope should list the environments, group count and test cases, and the engagement timeline should follow from that list.

What does our team need to provide before work starts?

You need to provide the people and decisions that the integration depends on:

Identity owners who can confirm authentik applications, providers and the users allowed to sign in.
A group model that maps authentik groups to Artifactory roles and repository permissions, agreed before the build.
Access to each environment, with the Artifactory administrator account and the self-hosted or JFrog Cloud details.
Test accounts in authentik for each role, including users who should be denied access.
Change windows for each environment, plus a named contact who can approve a rollback.

The scope should list these items so that delays are visible early.

Can an internal team set up Artifactory SSO without a partner?

Yes, an internal team with authentik and Artifactory administration skills can do the work without an outside partner. The authentik integration guide and the JFrog documentation cover the core steps. The usual gaps are the group design, the test plan across environments, and the rollback path if sign-in fails for administrators. Internal teams often underestimate how many build tools, scripts and service accounts depend on the old credentials. Decide whether your team has the time to run the change in each environment and to support users afterward. If it does not, a fixed-scope engagement can cover the design, configuration, testing and handover in writing.

What happens to Artifactory API tokens when someone leaves?

SAML sign-in controls the web session, but it does not automatically revoke the API tokens or access keys that build tools already hold. A departing user's personal access token can keep working until someone revokes it, so the offboarding process must include Artifactory tokens as well as the authentik account. Plan build tokens separately: issue them to service accounts rather than to people, scope them to the repositories a pipeline needs, and record an owner for each one. Confirm the exact token behavior with JFrog for your version, since token lifetimes and revocation options depend on the deployment.

Does the JFrog end-of-life schedule affect this project?

Yes, for self-managed installations. JFrog supports each self-managed Artifactory version for 18 months from the release of its initial minor version. The end-of-life page lists 7.111.x reaching end of life on October 23, 2026 and 7.125.x on April 30, 2027. If your instance runs an older line, an upgrade may be needed before or alongside the SAML work, which changes the schedule and the test plan. Check your current version against the JFrog end-of-life page and include any required upgrade in the written scope. SaaS customers have the upgrade handled on the JFrog side, but should still confirm the SAML settings after any platform change.

How DeployOpen scopes and delivers the Artifactory SSO work

DeployOpen plans, configures and documents authentik and JFrog Artifactory SAML integration inside your own infrastructure, starting from a written scope. We begin by confirming your Artifactory deployment type and license tier, because SAML sign-in depends on it, and then build, test and hand over the working setup.

How we scope

Confirm whether Artifactory is self-hosted or JFrog SaaS and which license tier you hold before any build work begins.
Agree in writing which groups map to Artifactory roles, which repositories each role reaches, and who approves changes.
Record which build tools and pipelines need API tokens after sign-in, so token handling is part of the agreed scope.

How we build

Configure the authentik SAML provider and application for Artifactory, with signing certificates and metadata exchanged and recorded.
Set up group attribute mapping from authentik to Artifactory and test each mapped group against a known account.
Test browser sign-in, a break-glass local admin path and CI token generation as separate, documented checks.

How we hand over

Deliver configuration notes, the group-to-role mapping table, and the certificate renewal steps your team will own.
Walk your platform and security staff through the runbook covering sign-in failures, group changes and token rotation.
Document which settings depend on your Artifactory version, so upgrade planning starts from a known baseline.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, Artifactory upgrades and continuous testing are available as a retainer after handover.
Ask any partner, including us, to confirm in writing which SAML and SSO capabilities your specific license tier includes.

authentik and JFrog Artifactory SAML integration