What Oleria discovers
Once connected, Oleria continuously discovers and maps the following from your Jama Connect instance:- Accounts - every user, active and deactivated, with their name, username, email address, title, phone, location, custom user fields, and license type. Each user’s sign-in method comes from their Jama authentication type: Jama-native and directory (LDAP or Crowd) users sign in with a password, and SAML users sign in with single sign-on. Members of the predefined Organization Admin group are marked as administrators. Only active users with a Creator (
NAMED) license are shown with API access. - Non-human identities - for an OAuth 2.0 client credentials connection, the API client the connection uses, shown as
API client <client ID>. It’s linked to its owner, the Jama user who created the credentials and whose access it acts with, and paired with a client secret credential. Oleria never shows the client secret or adds it to your inventory. A username and password connection adds no non-human identity. - Groups - organization groups and project groups, with their members. Project groups are linked to their project. The Organization Admin group is marked as built-in, and every other group as custom.
- Roles - each license type held by at least one user, such as Creator, Reviewer, Stakeholder, or Test Runner, with the users who hold it. Deactivated users hold the Inactive license type, so they appear under an Inactive role.
- Resources - projects and project folders, with who created and last changed each one and when, the folder that contains each project or folder, and each project’s project manager as its owner.
- Activity - two streams:
- The change log of every project the connection’s user can read: items and relationships created, updated, and deleted. Each change is linked to its project.
- The organization admin audit: users added, activated, deactivated, deleted, and edited (including password and license changes), group membership and group changes, permission grants and revocations, project changes, and organization configuration changes such as item types and pick lists. Each event is linked to the user, group, or project it names when Oleria can match the name to exactly one of them.
Oleria doesn’t import items, sets, baselines, or their contents. A change to an item appears as activity on its project.
Supported entities
Prerequisites
- Jama Connect Cloud, or self-hosted Jama Connect. OAuth 2.0 client credentials need Jama Connect Cloud or self-hosted Jama Connect 8.62 or later.
- A Jama Connect user for Oleria to connect as. A dedicated service account is recommended. The user needs:
- The Organization admin role. Jama returns a filtered user list to anyone else, so users the connection couldn’t see would look removed. Oleria refuses the connection without this role.
- A Named Creator license. Jama limits REST API access to Named Creator users.
- A place on the REST API allowlist, if REST API Access Control is turned on. Add the user, or one of its groups, to the allowlist.
- Admin access to the Oleria workspace.
Self-hosted Jama Connect must be reachable from Oleria over HTTPS at a public address. Before you connect, contact support@oleria.com to have its address allowlisted. Jama Connect Cloud addresses (
*.jamacloud.com) are already allowed.Required permissions
Jama Connect API credentials have no scopes. They act with the roles, license, and permissions of the user who owns them. Oleria’s Capabilities tab names these requirements:
Reading a project’s change log needs read access to that project. A project the user can’t read is skipped, and the rest of the sync continues. If the user can’t read any project, the sync fails, so a revoked role doesn’t silently empty Oleria’s view of project groups and activity.
Remediation actions need the roles in Remediation actions. An Organization admin holds all of them.
Choose an authentication method
Jama Connect offers two authentication methods:- OAuth 2.0 client credentials (recommended) - a client ID and client secret that the connection’s user creates in Jama Connect. This is the only method that works for SAML single sign-on users. It’s also the only method that shows the connection’s API client as a non-human identity in Oleria.
- Username and password - the username and password of a Jama-native user. Jama doesn’t accept password sign-in for SSO users, so use OAuth 2.0 client credentials if your users sign in through SSO.
Create API credentials
Skip this section if you use a username and password.1
Sign in as the connection user
Sign in to Jama Connect as the user that holds the Organization admin role and a Named Creator license.
2
Create the credentials
Open My Profile > Set API Credentials, and create API credentials.
3
Copy the client ID and secret
Copy the client ID and the client secret. Jama shows the client secret only once.
Connect Jama Connect to Oleria
1
Open the integration
Go to your Oleria workspace, select Integrations, then select the Jama Connect tile.
2
Complete the connection form
3
Authenticate
Select Authenticate. Oleria signs in with the credentials and checks that the user is an Organization admin, then saves the integration. If Jama answers that the user isn’t permitted to use the API, give the user a Named Creator license and add it to the REST API allowlist.
Verify the integration
Confirm Jama Connect appears on the Connected tab of your Oleria Integrations page. After the first sync completes, you can review the discovered users, groups, license roles, and projects in your Oleria workspace.If you replace the client secret or change the password in Jama Connect, update it in Oleria by editing the integration. To keep the current credential, leave the secret or password blank. Switching the authentication method, client ID, or username needs a new secret or password.
Remediation actions
Beyond discovery, Oleria can act on Jama Connect access to remediate risk. The connection’s user is always an Organization admin: Oleria requires the role to connect and checks it again before each action, and it covers every permission below. The table lists the narrower Jama role behind each change. Jama has no API that lists a user’s roles, so if Jama refuses a change, Oleria names the role it needs.
Oleria never deactivates the user the connection authenticates as, and never removes that user from any group.
If your identity provider provisions organization groups to Jama Connect with SCIM, it may undo membership changes Oleria makes to those groups. Change the membership in your identity provider instead.
Known limitations
- No permission or organization role data yet. Jama’s API doesn’t expose which users and groups hold organization roles such as Organization admin, User admin, or Project admin. Jama Connect 9.2 added a project permissions endpoint, but Jama hasn’t published its response format, so Oleria doesn’t read it yet. Until it does, Oleria shows no access from users or groups to projects, and project group membership doesn’t count as access to the project.
- Administrators come from the Organization Admin group. A user given the Organization admin role directly, outside the Organization Admin group, isn’t marked as an administrator. If the group is renamed, no user is marked.
- License types are read-only. Oleria shows license types as roles but doesn’t change them.
- No MFA, sign-in, or account date data. Jama has no native multi-factor authentication, so Jama-native and directory users show MFA as not required. For SAML users, MFA is enforced by your identity provider and shows as unavailable. Jama doesn’t provide last sign-in, created, last password change, or expiry dates for users.
- API access shows the license only. Users with a Creator license show API access. The REST API allowlist isn’t available through the API, so a user it excludes still shows API access.
- Partial non-human identity coverage. Oleria discovers only the API client the connection uses. Other users’ API credentials and long-lived bearer tokens aren’t available through Jama’s API. Jama doesn’t return the API client’s name, creation date, or last use.
- No sign-in events. Jama’s activity covers project changes and admin changes only. It has no sign-in, sign-out, or failed sign-in events, and no IP addresses.
- Activity shows the user, not the client. Changes made through an API client appear under the user who owns it, including the remediation actions Oleria takes.
- Admin audit has no date filter. Jama can’t filter the admin audit by date, so Oleria reads it from the newest end until it passes the sync window. Admin events that name a user, group, or project Oleria can’t match stay on the Jama Connect application.
- Deactivated users may not appear in groups. Jama may leave deactivated users out of group member lists. Their memberships return when they’re reactivated.
- Rate limits. Jama Connect Cloud throttles clients above 10 requests per second. Oleria sends at most 8 requests per second per integration and retries throttled requests, so large instances take longer to sync.
- No user creation or group deletion. Oleria can create organization groups, but doesn’t create users or delete groups, other than undoing a group it created. Creating a user needs a password and uses a paid license seat, and SSO users are usually provisioned by your identity provider. Jama can’t delete users.
- The base URL is fixed. To connect a different Jama Connect address, create a new integration.