Access Federation vs. Repository Federation
Compare Access Federation and Repository Federation to sync identities or artifacts across JPDs.
The JFrog Platform supports two distinct types of federation: Access Federation and Repository Federation. While they share the word "federation," they serve different purposes, operate at different layers, and are configured independently. Understanding the difference is important to avoid confusion when setting up multi-site environments.
Comparison
The following table compares Access Federation and Repository Federation.
| Aspect | Access Federation | Repository Federation |
|---|---|---|
| Purpose | Synchronize users, groups, permissions, and tokens across JPDs. | Synchronize artifacts, metadata, and properties across JPDs. |
| Layer | Identity and access management, handled by the Access service. | Artifact storage and delivery, handled by JFrog Artifactory. |
| What is synced | Users, groups, permission targets, access tokens. | Artifacts, binaries, properties, metadata. |
| Topology | Star or Mesh. | Mesh (up to 10 members per repository). |
| Configuration location | Administration > User Management > Settings > Federation. | Administration > Repositories > Federated tab. |
| Monitoring | Access service logs. | Federation Status Dashboard (Administration > Platform Monitoring > Federation Status). |
| Service | JFrog Access service. | Repository Federation Service (RTFS) or legacy in-process handler. |
| Operates on | Platform-wide identity data. | Per-repository artifact data. |
Access Federation
Access Federation manages identity synchronization (users, groups, permissions, tokens) across JFrog Platform Deployments (JPDs). When configured, user accounts, groups, and permission targets created on one JPD are automatically synchronized to other JPDs.
| What is Synced | Description |
|---|---|
| Users | User accounts, credentials, and profile data. |
| Groups | Group definitions and memberships. |
| Permission Targets | Permission definitions that control who can read, deploy, and manage repositories. |
| Access Tokens | Platform-level tokens for service-to-service and CI/CD authentication. |
Topology Options
Access Federation supports two topology models:
Star Topology
One JPD is designated as the central hub. All other JPDs synchronize identity data from the central instance.
flowchart TD
central["Central JPD (Hub)"]
site1["JPD Site A"]
site2["JPD Site B"]
site3["JPD Site C"]
central --> site1
central --> site2
central --> site3
classDef component fill:#41b375,stroke:#389b65,stroke-width:1px,color:#fff;
classDef secondary fill:#ffffff,stroke:#41b375,stroke-width:1.5px,color:#41b375;
class central component;
class site1,site2,site3 secondary;
linkStyle default stroke:#8e9aaf,stroke-width:1.5px;
The following table describes the characteristics of Star topology.
| Characteristic | Description |
|---|---|
| Direction | One-way: central pushes to all spoke JPDs. |
| Best for | Organizations with a single headquarters managing identity centrally. |
| Limitation | Changes must be made on the central JPD. Changes on spoke JPDs are not propagated back. |
Mesh Topology
All JPDs are equal peers. Identity changes on any JPD propagate to all other JPDs.
flowchart TD
site1["JPD Site A"] <--> site2["JPD Site B"]
site2 <--> site3["JPD Site C"]
site1 <--> site3
classDef component fill:#41b375,stroke:#389b65,stroke-width:1px,color:#fff;
class site1,site2,site3 component;
linkStyle default stroke:#8e9aaf,stroke-width:1.5px;
The following table describes the characteristics of Mesh topology.
| Characteristic | Description |
|---|---|
| Direction | Bidirectional: all JPDs send and receive identity updates. |
| Best for | Organizations with distributed administration across sites. |
| Consideration | Conflict resolution is needed when the same user or group is modified on multiple JPDs simultaneously. |
Use Cases
- Ensure developers have the same credentials across all sites.
- Centrally manage permission targets that apply to repositories on multiple JPDs.
- Provide single sign-on (SSO) experience across geographically distributed instances.
Repository Federation
Repository Federation (the primary subject of this documentation set) enables artifact synchronization across multiple JPDs. When a Federated repository is configured, artifacts deployed to one member are automatically replicated to all other members.
Key Characteristics
- Configured per-repository (not platform-wide).
- Supports mirror modes: bidirectional, receiver, transmitter.
- Supports priority levels: STANDARD, HIGH (URGENT is available via REST API only, not in the Platform UI).
- Monitored via the Federation Status Dashboard.
- Managed by the RTFS microservice (or legacy in-process handler).
Use Cases
- Distribute build artifacts to regional sites for low-latency resolution.
- Maintain disaster recovery copies of critical repositories.
- Enable globally distributed teams to deploy and consume artifacts locally.
Using Both Together
In a typical multi-site deployment, you configure both types:
- Access Federation ensures all JPDs share the same user accounts and permission targets, so developers can authenticate against any site.
- Repository Federation ensures specific repositories share the same artifacts, so developers can resolve and deploy locally.
Configuring one does not automatically configure the other. They must be set up independently.
Prerequisites That Overlap
Both types of federation require:
- Circle of Trust or binding tokens established between JPDs.
- Network connectivity between JPDs (HTTPS).
- Enterprise subscription (Enterprise+ or Enterprise X).
Access Federation must be configured before Repository Federation if you want identity-based permissions to work consistently across all sites.
Circle of Trust
A Circle of Trust establishes mutual authentication between JPDs. It is a prerequisite for both Access Federation and Repository Federation.
| Term | Description |
|---|---|
| Binding Token | A one-time token generated on one JPD and used on another to establish trust. |
| Circle of Trust | The set of JPDs that trust each other and can exchange tokens for cross-instance authentication. |
| Master Token | A long-lived token used by services (RTFS, Access) for service-to-service communication between trusted JPDs. |
For setup instructions, see Access Tokens - Circle of Trust.
Frequently Asked Questions
This section provides answers to frequently asked questions about Access Federation and Repository Federation.
FAQs
Q: What's the difference between Access Federation and Repository Federation?
A: Access Federation synchronizes identity data (users, groups, tokens) through the JFrog Access service, while Repository Federation synchronizes artifacts and metadata through JFrog Artifactory. See the Comparison table for the full breakdown.
Q: Do I need to set up both Access Federation and Repository Federation?
A: No. Configuring one doesn't automatically configure the other since they're set up independently. Configure Access Federation first if you want identity-based permissions to work consistently across all sites.
Q: What is a Circle of Trust and why do I need one?
A: A Circle of Trust establishes mutual authentication between JPDs using binding tokens. It's a prerequisite for both Access Federation and Repository Federation.
Q: Can Access Federation use a mesh topology instead of a star topology?
A: Yes. Access Federation supports both Star topology (one central hub) and Mesh topology (all JPDs as equal peers). Repository Federation always uses a mesh of up to 10 members.
Q: Which JFrog subscription is required for federation?
A: Both federation types require an Enterprise subscription, either Enterprise+ or Enterprise X.
Related Topics
Updated about 7 hours ago