Access Federation gives you control over access to all, or any subset of your services from one location by synchronising allsecurityentities (users, groups, permissions and access tokens) between the federated services. Once Access Federation has been set up, you can manage all security entities in the federated services from one place.
Access Federation supports setting up the security entities you want tosynchroniseacross different federated services, and provides quick and easy configuration to set up a Full Mesh or Star topology. Thesynchronisation过程是由多种均nt parameters whose default values have been set to satisfy most installations.
Requirements
Enterprise+ license
Admin permissions
WebUI Changes implemented in Artifactory 7.38.x and above
Identity and Access is now called User Management. All the relevant text and images on this page have been updated to reflect this change.
Before you proceed to the next step of configuring your Access Federation topologies, make sure toconfigure the Base URLon the Artifactory side.
Setting up Access Federation requires the following main steps:
Configuring Access to allow remote calls from Mission Control In this step, you will enable Mission Control to send commands to any of the Access services in the JFrog Platform Deployment.
Establishing the Circle of Trust In this step, you will establish the basis for your Access Federation topology by providing synchronization target services with the root certificate of the synchronization source service.
Configuring Access Federation Topologies In this step, you will establish the connections required so that the Access service in the Source platform deployment will be able to synchronize security entities to the Access service in the target platform deployment (i.e. those that have been furnished with the source service's root certificate).
Establishing the Circle of Trust
You can only configure synchronization of security entities from a source to a target Platform Deployment, if the source is trusted by the target. This trust is established by providing the Access in the target Platform Deployments with the source Platform Deployments's root certificate. For more information, seeEstablishing a Circle of Trust.
Before configuring access federation topologies
Before you proceed to the next step of configuring your Access Federation topologies, make sure that your target Access service is furnished with the required root certificates from the source Access service.
美元JFROG_HOME / artifactory / var / etc / /键/ truste访问dfolder
Once your circle of trust is established by providing target Platform Deployments with the root certificates of source Platform Deployments, you need to configure the topology by setting up the relationship in Access Federation.
SampleTopologies
Example 1: Setting Up a Star Topology
Consider the scenario where three Access services that should be set up in a Star topology where Access-A synchronizes to Access-B and Access-C.
In this case, you need to provide Access-B and Access-C the root certificate of Access-A so that A becomes trusted by B and C.
Example 2: Setting Up A Full Mesh Topology
Consider the scenario where three Access services that should be set up in a Full Mesh topology where each service should be able to synchronize changes to security entities to both other services.
In this case, you need to provide each Access service with the root certificates of both other services so that both are trusted.
Setting up the Relationship in Access Federation
To configure Access Federation topologies, from theAdministrationmodule in the Platform Deployment where Mission Control is installed, expand用户管理and selectAccess Federation. The list of Platform Deployments managed is displayed.
Mesh Topology
To set up Mesh topology, clickApply Topology | Mesh. The wizard that will take you through the following steps:
Selecting Platform Deployments
Selecting security entities to synchronize
Summary
1. Selecting Platform Deployments
In this step, you select the Platform Deployments that will be part of the federated group. To include Platform Deployments in the federated group, select them from theAvailable Platform Deploymentslist and use the arrows to transfer them to theSelected Platform Deploymentslist.
2. Selecting Security Entities
Once you have set the Access services that are in the federated group, you select the set of security entities that should be synchronized out of the following:
Users
Groups
Permissions
Access tokens
Simply check the entities that should be synchronized (by default, they are all checked) and clickNext.
3. Summary
Finally, the wizard displays a summary of your configuration. To apply, clickFinish.
A summary of the results is displayed.
Star Topology
To set up access federation, clickApply Topologyand selectStar.A wizard will take you through the steps of the process which are:
Selecting services
Selecting security entities to synchronize
Summary
This example shows setting up a star topology to allow synchronization of security entities from theHome-JPDtoartifactory-edge1. Prior to setup,artifactory-edge1提供的根证书吗Home-JPDand Mission Control was setup to make calls to the Access service inartifactory-edge1.
1. Selecting Services
In this step, you select the services that will be part of the federated group. To include services in the federated group, select them from theAvailable Platform Deploymentslist and use the arrows to transfer them to theSelected Platform Deploymentslist.
2. Selecting Security Entities
To sync security entities:
Select the method for assigning entity types to targets.
Manually assign entities to different targets: This provides flexibility as it allows you to assign different entity types to different targets. For example: You decide to synchronize users and groups from Access A to Access B, choose to only synchronize users, groups and permission from Access A to Access C, and synchronize all the entities from Access A to Access E.
Apply on all Targets:Any selection made applies to all targets and selecting Permissions applies to all permissions. This option is enabled when selecting the Star Topology.
Select the entity types to be synced.
Users
Groups
Permissions
Include/exclude Patterns: When assigning entity types to targets, you can assign specific permissions to be synchronized using the Include/Exclude regular expressions.
Tokens
3. Summary
Finally, the wizard displays a summary of your configuration. To apply, clickFinish.
A summary of the results is displayed.
Configuring Synchronization
In this step, you configure which security entities an Access service should synchronize to its target services. At the same time, you may optionally set a number of parameters that govern the synchronization process. The configuration parameters are specified in theYAML configuration filethat is uploaded to the different Access services.
Federated Repositories utilize a URL calledfederatedRepoUrlBase,which is relevantONLYto Federated Repositories and cannot be applied to other features for setting up geo-synchronization. To configure geo-synchronization, you will need to set it up through theAccess YAML Configuration.
Access Federation Parameters
The following sections in the YAML configuration file govern access federation:
"inbound":The inbound parameters map service ids from a source Access service, to service ids to which the receiving Access service is attached. To determine the service ID of an Artifactory service, use theGet Service IDREST API endpoint.
"outbound":The outbound parameters define parameters that govern synchronization of security entities outwardly from the source service to a target service.
The format of the federation YAML file parameters is shown below with default values:
Specifies which entities should be synchronized to the target servers configured. Possible values are:
- users
- groups
- permissions
- tokens
Implicit synchronization
To maintain consistency in the hierarchical relationship of entities between the different Access services in a circle of trust, the following rules apply to synchronization of security entities:
For anygroupthat is synchronized from a source Access service to a target, all theusersin that group are also synchronized.
For anypermissionthat is synchronized from a source Access service to a target all theusers and groupsassociated with that permission are also synchronized.
LDAP, SAML, Crowd etc.
When using 3rd party authentication providers such as LDAP, SAML and Crowd, only theUsersdefined in these providers can be federated, NOTconfigurations.
Note also that for federation to work, these users must be created AFTER logging in to Artifactory.
exclude-users
Optional
Specific users that should be excluded from synchronization
buffer-wait-millis
Optional [Default:30000]
The time (ms) between synchronization attempts. For example: buffer-wait-millis = 3000 means that every 30 seconds the source Access service will attempt to sync with the target Access service.
buffer-max-size
Optional [Default:500]
The maximum number of entities that can be accumulated between synchronization attempts. For Example: buffer-max-size = 500 means that whenever 500 security entity updates have been accumulated, the source Access service will attempt to sync with the target Access.
consider-stale-hours
Optional [Default:168 (one week)]
The length of time a receiving server can fail to respond or respond with an error before it is considered to be "stale" and unable to be synchronized with updates. Once a server is deemed to be "stale", it can only be brought back into operation using the REST API endpoint described in Updating a Stale Server.
maximum-future-time-diff-millis
Optional [Default:60000]
If an Access service is updated, and another update is subsequently synchronized over to it, the Access service will only accept the subsequent change if its timestamp is at leastmaximum-future-time-diff-millislater than the previous update.
The length of time after synchronizing an update that an Access service will wait for acknowledgement from the receiving Access service before retrying to synchronize the update. If no acknowledgement is received within this period of time, the sending server will retry synchronizing the update to the target server the number of times specified in thenumber-of-retriesparameter.
number-of-retries
Optional [Default:3]
The number of times an Access service will attempt to synchronize an update to a distant service until. If an acknowledgement is not received from the target server after this number of retries the synchronization is deemed to have failed.
servers
The logical name and URL of target Access services to which this Access service can synchronize entities
service-id-mapping
When a service such as Mission Control, Xray or Distribution selects an Artifactory instance as its authentication provider, that service's service ID is automatically registered with the corresponding Access service.
This field maps the service IDs of services being synchronized over to this Access service. The mapping is automatically generated by Access and need not be entered manually except for a few limitations described below.
For a synchronization target, the "from" and "to" fields define the mapping of service IDs.
The来自:field should specify the service type with a wildcard character. For example, for Artifactory, specifyjfrt@*, for Xray, specifyjfxr@*.
Theto:field should specify the specific service to which the source service(in the来自:field)is being mapped.
Limitations
An access service can only serve one service of each supported type, i.e., one each of Artifactory, Mission Control, Xray and Distribution.
If you remove a registered service (for example, by changing the Artifactory that is used as the authentication provider), you need to manually remove the corresponding service ID registered with Access before you can add a new service of the same type.
From version 5.4, the Artifactory service ID format changed. If you need to map a service ID whose format is from below Artifactory version 5.4 to a format that is from Artifactory version 5.4 and above, or vice versa, then you have to manually write the service ID.
当升级Artifactory,服务标识格式remains that of the originally installed version. For example, if the original version of Artifactory that you installed was version 5.2, and you have upgraded through the versions to version 5.11, the service ID format of your Artifactory installationwill still be that of version 5.2.
Watch your whitespace
The YAML file format is sensitive to whitespace, so you need to ensure that all required whitespace characters are in place. If the YAML format is invalid, permissions will not be synchronized successfully and you will not receive error messages.
Handling Synchronization Conflicts
Depending on the synchronization topology you have configured, an Access server may receive multiple updates from different sources at short time intervals Successive updates may even conflict. For example, in a full mesh topology, an Access server may have a user's password updated to one value sync'ed over from one source, but that same user's password may be updated to a different value sync'ed over from another source. To resolve such conflicts, an Access server will finalize upon the update that has the latest timestamp. However, since synchronization of server clocks may not always be completely accurate, there could still be an inconsistency when an Access server receives conflicting updates. To overcome the possible inaccuracy in synchronization of server clocks, an Access server uses a time buffer specified in themaximum-future-time-diff-millisparameter specified above. Access will not update an entity if the update arrives sooner thanmaximum-future-time-diff-millismilliseconds from the previous update.
Consider the following example using the default value of maximum-future-time-diff-millis = 60000.
On Access Service 1, the password for User1 is changed to "abc" at time 09:02:00:000.
However, at approximately the same time, User1 is synchronized over to Access Service 1 from Access Service 2 which has set the password to be "def".
If the change synchronized over from Access Service 2 has a timestamp that is between 09:02:00:000 and 09:02:59:999, then User1's password will be "abc" because the password synchronized from Access Service 2 is ignored.
If the change synchronized over from Access Service 2 has a timestamp that is 09:03:00:000 or later, then User1's password will be "def" because the password synchronized from Access Service 2 is deemed to be later than the one set directly on Access Server 1 so it will be accepted.
Synchronizing Data
Once your access services are configured with their corresponding YAML files, you are ready to synchronize data from the source to the target Access services.
From Artifactory release 7.42.1, there are two way to synchronize data:
Invoking a Full Broadcast from the Access Federation Menu
The purpose of a full broadcast is when you are first setting up a federation. You can also use this functionality toresolve a "stale-server" status.
Resource-heavy Operation
Because a "full broadcast" isresource-heavy, you should avoid repeated Broadcast clicks whenever possible.
To trigger a full broadcast from a specific Access Federation source, navigate to用户管理| Access Federation.
Select the source you wish to broadcast from, and from three-dot menu on the right, selectBroadcast. You will be asked to confirm the full broadcast and resync.
ClickOKto begin the broadcast or Cancel.
Manually Applying a REST API Endpoint on the Source Service
Descriptiont:同步数据从源o a target Access service Notes:Requires Artifactory Enterprise Plus Since: 5.11 Security: Requires an admin user. Usage:PUT /api/v1/system/federation/[targetServer]/full_broadcast Sample Usage:
REST API calls on an Access service need to be authenticated using the Admin user of the Access service on which you are making the call.
Don't confuse this with any Admin user defined in Artifactory. Those can be used to make REST API calls on Artifactory. This call is made on the Access service to revive it after a long period of inactivity, not on Artifactory.
Example
The following is an example of how you might configure a 1-way replication of permissions by synchronizing permissions settings from a source Access service in your circle of trust to a target. Here are the steps in this process:
This example applys for manual setting of Access Federation using Access configurations. When setting up Access Federation viaMission Control's UI, some of the settings are handled by Mission Control during set up.
Mapping Permission Targets with repositories of different types
By default, federation only works for permission targets where the permissions are applied on resources of the same type (local-to-local and remote-to-remote). Mapping repositories with different types (remote-to-local or local-to-remote) requires editing the artifactory system properties. To enable local permissions on remote repositories:
The first step is to obtain the service IDs of the Artifactory services involved in the permission synchronization relationship. Note that we need theArtifactoryservice IDs, although, in fact, the permissions are managed and synchronized by the corresponding Access services.
For each of the source and target Artifactory services run the theGet Service IDREST API endpoint. In this example, we are assuming you are applying this call directly on the machine that the Artifactory service is running (i.e. on localhost):
curl -uadmin:password -v http://localhost:8081/artifactory/api/system/service_id On the source service, the response is: jfrt@01c9s2y40bcs960sdxwy4302yc On the target service, the response is: jfrt@01c9wadx1fvh3d1egg7wne0e0g
Plan and map out your synchronization
We strongly recommend having the service ID of each Artifactory cluster involved ready for use, and creating a diagram that illustrates the permission synchronization topology you are implementing while assigning a logical name for service ID. In this example, we will assign the following logical names to the source and target service IDs:
access-1: jfrt@01c9s2y40bcs960sdxwy4302yc
access-2: jfrt@01c9wadx1fvh3d1egg7wne0e0g
Inbound Configuration
Load the following YAML file on thetargetAccess service to create the service ID mapping as described inUploading the YAML File. Note that since the target service is receiving permissions (and not synchronizing anything out), there is no need to include theentity-types-to-syncfield.
federation:\n inbound:\n service-id-mapping:\n - from: jfrt@*\n - to: jfrt@01c9wadx1fvh3d1egg7wne0e0g\n
Don't forget to restart the Access service after placing the YAML file in the designated location.
出站Configuration
出站configuration goes on the source Access instance
Note that the Outbound configuration should be applied to the source Access instance from which you are synchronizing security entities.
In this example, we want to synchronize all security entities using default values except for the following settings that we want to modify:
timeout-millis = 4000
number-of-retries: 5
Load the following YAML file on thesourceAccess service as described inUploading the YAML Fileto specify the above parameters and set access-2 as the synchronization target for access-1 (this example assumes the access-2 service IP address is 35.230.92.254):
Don't forget to restart the Access service after placing the YAML file in the designated location.
Invoke Synchronization
Once your federation is setup, you are ready to synchronize data by applying the Federation REST API endpoint described inSynchronizing Dataon access-1:
A "stale" service is one that has been registered as a synchronization target, however it has not responded to any attempt to synchronize data for a period of time greater than that defined in the consider-stale-hours parameter with which the source Access service was configured. Once a target service is deemed to be stale, the source service will not may any further attempts to synchronize data to it. To "revive" a stale service and resume synchronizing data you need to manually apply the "Federation" REST API endpoint described inSynchronizing Dataon the source service:
Removing a Registered Synchronization Target
To remove a synchronization target that has been registered with an Access service, you need to remove it from the YAML configuration file and reload the file as described inUploading the YAML File.
Don't forget to restart the Access service once the file is in the designated location.
REST API
Mission Control supports managingAccess Federationthrough the REST API.
