*.jfrog.io) and self-hosted JFrog Platform deployments.
What Oleria discovers
Once connected, Oleria continuously discovers and maps the following from your JFrog Platform:- Accounts - every user, including JFrog’s built-in
anonymoususer, with email, status, administrator status (including admin rights granted through a group), last login, and the date the password was last changed. Disabled and locked users appear as disabled. Oleria also shows each user’s MFA status (verified, enrollment pending, or not used), whether the user signs in with SAML or OAuth single sign-on, and, when JFrog returns the user’s MFA status, their sign-in methods: password, SSO, authenticator app, and access token. - Non-human identities - access tokens, including admin-scoped, user-scoped, and group-scoped tokens. Each token is paired with a credential that shows its scope, status (active or expired), issue date, expiry, and when it was last used. A token that acts as a JFrog user appears as that user’s personal access token and is linked to the user as its owner. Other tokens appear as API tokens.
- Groups - groups and their members. Each group is marked as built-in (JFrog’s default
readersgroup), synced from an external realm such as LDAP, SAML, SCIM, or Crowd, or custom. - Roles - three kinds of role, with the users and groups that hold each one:
- Platform roles: Admin, User, and JFrog’s global roles, such as Platform Auditor, Watch Manager, Policy Manager, and Manage Webhooks.
- Permission targets: one role per permission target, resource type, and set of actions, because JFrog can grant each user and group different actions on the same target. For example,
<target> — Repositories [READ, WRITE]. - Project roles: one role per project and role, for example
<project> / Developer.
- Resources - repositories and projects, with their creation dates, which repositories belong to each project, and who can reach each one through which role. Permission targets that use
ANY,ANY LOCAL,ANY REMOTE,ANY FEDERATED, orANY DISTRIBUTIONare expanded to the matching repositories. Holders of a permission that includes Manage, and holders of a project’s admin role, are shown as managers. Each repository is also linked to its resource classes: its repository type, such as local or remote, and its package type, such as Docker or Maven. Roles that grant a whole class are linked to that class: anANYtarget, builds, release bundles, distribution destinations, pipeline sources, or the platform Admin role. - Activity - events from the Artifactory access log: logins and failed logins, deploys, downloads, deletes, creates, property changes, build creation, promotion, and deletion, configuration changes, and other denied requests, with the client IP address. Each event reads as a sentence, such as “alice uploaded artifact a/b.jar to repository libs-local”, and repository events link to the repository. Events made with an access token show access token as the sign-in method. Events that JFrog’s own internal services generate are skipped.
- Authentication settings - the SAML and OAuth sign-in settings. When SAML is turned on, Oleria links JFrog to the app in your identity provider through the SAML signing certificate.
Prerequisites
- A JFrog Platform Admin account, to create an admin access token.
- The address of your JFrog Platform, for example
https://acme.jfrog.io. - We recommend a dedicated JFrog admin user for Oleria, so the token isn’t tied to a person. Oleria never disables or deletes the connection’s own user.
- Admin access to the Oleria workspace.
To connect a self-hosted JFrog Platform, first contact Oleria support to allow its address. It must be reachable from Oleria over HTTPS and can’t resolve to a private or loopback IP address.
Create an admin access token in JFrog
1
Generate the token
Sign in to JFrog as a Platform Admin and go to Administration -> User Management -> Access Tokens. Select Generate Token and set the token scope to Admin.
2
Copy the token
Copy the token before you leave the page. You’ll paste it into Oleria in the next section.
Connect JFrog to Oleria
1
Open the integration
Go to your Oleria workspace, select Integrations, then select the JFrog tile.
2
Complete the connection form
3
Authenticate
Select Authenticate. Oleria checks that the token reaches your JFrog Platform and can read users and permission targets, then saves the integration. A token that can’t is refused with a message asking for an admin access token. Editing the integration runs the same check.
Verify the integration
Confirm JFrog appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, you can review the discovered users, groups, roles, repositories, and tokens in your Oleria workspace. The integration’s Capabilities tab shows Read users, Read groups, Read roles, Read resources, Read activity (audit logs), and Read credentials with the permission each one needs,applied-permissions/admin, and checks them against your token.
If you rotate or replace the token in JFrog, update it in Oleria by editing the integration. Leave Access token (optional) blank to keep the stored token.
Remediation actions
Beyond discovery, Oleria can act on JFrog access to remediate risk. Every action needs theapplied-permissions/admin token scope. Before an action runs, Oleria checks that the token still has admin access and reports it if not.
A revert only undoes a change that the action made. If the action changed nothing, the revert changes nothing too.
The role actions apply to project roles only. Permission targets change only through Revoke permission to resource and Revoke anonymous access, which remove a direct user entry. Platform roles can’t be changed through Oleria.
On a default JFrog deployment, every new user joins the
readers group, which is in the Anything permission target that covers every repository. Revoke permission to resource refuses for those users until you narrow that permission target or remove them from readers.
Disable NHI supports access tokens that appear as personal access tokens and as API tokens. If a token was already revoked, or the token ID doesn’t exist, Oleria reports that the token wasn’t found.
Oleria never disables or deletes the user that the connection’s token belongs to, or removes that user from a group or a project role. It never revokes the connection’s own token or the tokens of JFrog’s internal services, and it doesn’t disable, enable, or delete the built-in anonymous user. If Oleria can’t confirm which token the connection uses, it doesn’t disable or delete a user, remove a user from a group or project role, or revoke a token.
Known limitations
- Activity covers the most recent part of the access log. JFrog exposes only the last 300 KB of the current Artifactory access log through its API. Each sync reads that tail and imports the events in its sync window. On a busy deployment, events can rotate out of the tail before a sync reads them, and those events are lost. Older history isn’t imported.
- Admin changes aren’t in the activity. JFrog doesn’t log the creation or deletion of users, groups, or tokens, membership changes, or permission changes anywhere its API can read. Self-hosted deployments keep an access audit log on the server’s file system only.
- Token activity names the user, not the token. The access log records which user a token acts as, but not which token was used. Oleria attributes these events to the user, with access token as the sign-in method.
- No creation dates or creators for some objects. JFrog doesn’t expose when a user or group was created, or who created an access token. Tokens show their issue date, and projects and repositories show their creation date.
- Names are usernames. JFrog doesn’t store a display name, so Oleria shows the username as each user’s name.
- No platform-wide MFA enforcement setting. JFrog Cloud doesn’t expose whether MFA is enforced for the platform. Oleria shows each user’s MFA status instead.
- Some resources aren’t inventoried. Builds, release bundles, distribution destinations, pipeline sources, and project environments aren’t listed as resources. Permission-target roles that grant access to them appear with their holders, linked to the Build, Release Bundle, Destination, or Pipeline Source resource class.
- Some identities aren’t inventoried. OIDC identity mappings used by CI systems aren’t listed. Short-lived tokens that JFrog doesn’t store can’t be listed or revoked.
- Projects need a plan that includes them. If your JFrog plan doesn’t include projects, Oleria syncs repositories and skips projects and project roles.
- One deployment per integration. Add one integration for each JFrog Platform deployment.
Existing SCIM connections
If you connected JFrog earlier with the SCIM setup, that connection keeps syncing without reconnecting. Oleria now reads it through the JFrog Platform API with the token you already stored, and trims the stored SCIM URL to your JFrog Platform address. The JFrog Platform API calls that Oleria now makes need an admin access token. If the stored SCIM token isn’t one, syncs can fail or leave data out, such as access tokens, MFA status, roles, and activity, until you create an admin access token and enter it in the integration. To edit a SCIM connection, open the integration and select Update. You don’t need to re-enter the URL. Leave Access token (optional) blank to keep the stored token, or enter a new admin access token. Oleria checks the token when you save, so a stored SCIM token that isn’t an admin access token is refused. Enter an admin access token instead. After the switch, the first sync replaces your JFrog accounts and groups with new records that have new IDs. Update any access reviews or workflows that used the old accounts or groups. What changes for remediation:- Disable user account, Enable user account, Add user to group, Remove user from group, Create user, and Create group keep working. Create user and Create group now need the admin access token.
- Project role changes, user deletion, permission and anonymous access revocation, and access token revocation are new.