Schema Reference

The application schema is used to configure the objects returned from a connector.

Note

The Account Schema tab is used to define the attributes for each object type in the application being configured. The schema attributes can be defined as Entitlement or Multi-Valued. Refer to Managing Source Account Schemas for more information.
The schema attributes that are not present by default must be defined as strings if not specified.

The GitLab connector uses the following default correlation and object configurations.

Default Account Schema

Each source supports a variety of details, or attributes, about each user who has an account, such as their name, email address, manager name, and location.

The set of account attributes each source stores and how they're organized is known as the account's schema. To best represent your data, you can configure sources to use an account schema matching the one you use in the external connector. Refer to Managing Source Account Schemas for more information.

Default Account Attributes

The GitLab connector supports the following default account schema attributes and customer configurable attributes. The attributes must be defined as strings if not specified.

Attribute Name	Description
id	Numeric GitLab user ID. Account identity
username	GitLab username. Display attribute
name	Display name
public_email	Public email address, used for correlation. Empty unless the user has published one
state	GitLab account state, for example active or blocked
locked	Whether the account is locked.
groups	Multi-valued. The groups the user belongs to
projects	The Multi-valued. The projects the user belongs to
groupPermissions	The Multi-valued. Role held on each group, as `Role@full/path`
projectPermissions	The Multi-valued. Role held on each project, as `Role@full/path`

Default Entitlement Attributes

Entitlement attributes define the entitlements, such as groups or roles, that can be assigned to the managed system's user accounts. Refer to Managing Entitlements for more information.

Caution

Changing the attribute marked as the Entitlement ID after aggregating accounts or entitlements can result in duplicate entitlements being created, or access profiles and roles breaking. To avoid this, edit the entitlement schema before performing any aggregations.

Two entitlement types. Both key on the numeric id and display the full path, because groups of the same name in different trees are otherwise indistinguishable.

This section describes the entitlement attributes for group.

Attribute Name	Description
id	GitLab numeric group ID
full_path	Unique path of the GitLab group
name	Display name of the GitLab group
description	Description recorded on the GitLab group
visibility	Visibility of the GitLab group
parent_id	ID of the parent GitLab group
web_url	URL of the GitLab group

This section describes the entitlement attributes for project.

Attribute Name	Description
id	GitLab numeric group ID
path_with_namespace	Unique path of the GitLab project
name	Display name of the GitLab project
description	Description recorded on the GitLab project
visibility	Visibility of the GitLab project
archived	True when the GitLab project is archived and read-only
web_url	URL of the GitLab project

Machine Identities

The source reports six datasets. Each dataset reports one kind of holder. Tokens are reported as credentials. Bots and service accounts are reported as machine accounts.

Dataset	Reports	Requires
Project access tokens	The token and the bot user it runs as	Maintainer or Owner on the project
Group access tokens	The token and its bot user	Owner on the group
Personal access tokens	The token only. Its holder already aggregates as an account	Instance administrator on self-managed. Otherwise a top-level group's credentials inventory, which is a Premium and Ultimate feature
Group service accounts	The service account and its tokens	Owner on a top-level group. Premium or Ultimate
Project service accounts	The service account and its tokens	Premium or Ultimate
Security policy bots	The bots only. They hold no credentials	Visibility of project members

Every token row carries tokenType as personal, group, or project. A credential is identifiable without referring to the dataset it arrived in. A token row names its bot through user_id. A bot row names its token through tokenId. This links a credential and the identity that uses it. A bot that holds several tokens is reported once.

Risk Indicators

Every token carries a multi-valued riskFlags attribute. It also carries the measure behind each flag, so a reviewer can see how far past a threshold a token is: daysUntilExpiry, daysSinceLastUse, tokenAgeDays, and lifetimeDays.

A token with nothing wrong carries an empty array. If GitLab does not report a date, the source omits the measures that need it. The run does not fail.

Flag	Meaning
`ABOUT_TO_EXPIRE`	Expires within the warning window, 30 days by default
`EXPIRED_NOT_REVOKED`	Past expiry but never revoked. GitLab no longer honours it, yet it remains on the books.
`IDLE`	Unused for the idle threshold, 90 days by default
`NEVER_USED`	Never used at all, and old enough that it would have been by now, 14 days by default
`LONG_EXPIRATION`	Issued with a lifetime longer than a year by default
`NOT_ROTATED`	Older than the rotation threshold, 90 days by default
`OVER_SCOPED`	Holds `api` or `write_repository`, granting write access across everything the holder reaches
`OVER_PRIVILEGED`	Holds Maintainer or above. A personal access token carries no role, so it is never flagged.

Documentation Feedback

Feedback is provided as an informational resource only and does not form part of SailPoint’s official product documentation. SailPoint does not warrant or make any guarantees about the feedback (including without limitation as to its accuracy, relevance, or reliability). All feedback is subject to the terms set forth at https://developer.sailpoint.com/discuss/tos.