A technical asset represents a specific application, information system, or technological unit that requires its own access permissions to function and communicate with its environment (other applications and systems). By itself, it is not a specific account; rather, it is the owner and umbrella element for so-called technical accounts (service accounts).

Examples:

• An integration platform (e.g., the IdM itself) needs to access various systems (AD, HR system, SAP, etc.).
• An HR portal needs to access AD to check which employees are active, and the payroll system to check remaining vacation balances.
• A monitoring tool requires access to the monitored systems.

The primary reason for registering technical assets is to ensure that every technical account within the organization has a clearly defined owner and does not remain anonymous. Therefore, we define two key human roles for each technical asset:

• Technical Asset Guarantor: A person from the business or management side who bears overall functional and compliance responsibility for the given asset. The Guarantor approves permissions for individual technical accounts under the given technical asset.
• Technical Asset Holder: A technical specialist who actually works with asset accounts in practice. In the IdM, the Holder securely retrieves passwords, configures them on target systems, and creates requests for roles that grant the permissions the technical account requires for its intended use.

Thanks to this Person → Technical Asset → Technical Accounts linkage, we can precisely audit at any time who is responsible for which technology and who manages its access rights, which is also crucial from a regulatory standpoint to ensure the organization's compliance with legislative requirements, such as the NIS2 Directive.

• Centralize management of technical accounts under logical asset groupings
• Enable role-based access control for asset-related operations
• Provide audit capabilities for compliance requirements
• Support notifications via NOTIFY event

┌──────────────────┐      ┌────────────────┐
│ TechnicalAccount │◄─ ─ ─│ TechnicalAsset │
└──────────────────┘      └────────────────┘
                                   │
                                   │      ┌─────────────────────────┐
                                   ├─────►│ TechnicalAssetGuarantor │◄────────┐
                                   │      └─────────────────────────┘         │     ┌─────────────┐
                                   │                                          ├─────│ IdmIdentity │
                                   │      ┌──────────────────────┐            │     └─────────────┘
                                   ├─────►│ TechnicalAssetHolder │◄───────────┘
                                   │      └──────────────────────┘
                                   │
                                   │      ┌─────────────────────────────┐
                                   ├─────►│ TechnicalAssetGuarantorRole │◄────┐
                                   │      └─────────────────────────────┘     │     ┌─────────┐
                                   │                                          ├─────│ IdmRole │
                                   │      ┌──────────────────────────┐        │     └─────────┘
                                   └─────►│ TechnicalAssetHolderRole │◄───────┘
                                          └──────────────────────────┘

The technical account has been extended with an optional attribute specifying which technical asset it belongs to. If a technical asset becomes disabled, the technical accounts belonging to it will become disabled as well. Note that this doesn't work in reverse - if a technical asset becomes enabled again, its technical accounts will stay disabled until set to enabled manually.

The overview of technical accounts can be accessed via the "Systems" and "Accounts" agendas in the main menu. The technical accounts in this agenda can be filtered by the technical asset they belong to, as well as by the rest of their properties.

When creating a technical account via the wizard, the first step allows you to select the technical asset to which the technical account belongs. By default, an administrator can create a technical account without selecting a technical asset, whereas all other users are required to fill it in. This behavior can be modified using two configuration properties:

1. idm.pub.tech.techAccountWizard.accountWithoutAssetForAdmin: Setting this to false enforces that even administrator must select a technical asset.
2. idm.pub.tech.techAccountWizard.accountWithoutAssetRoles: By populating this property with role UUIDs (multiple UUIDs can be comma-separated), users with any of these roles assigned will be allowed to create technical accounts without specifying a technical asset.

The primary entity representing a technical asset that can contain multiple technical accounts.

Assigning a technical asset to a technical account is subject to a validation that answers a single question: may this technical asset be assigned to this technical account? The rule is not hardcoded - it is a Groovy script referenced from configuration, so each deployment decides what makes a pair valid.

A technical account references its technical asset and is linked to an AccAccount through TechnicalAccountAccount. The script always receives this pair - the technical asset and the linked AccAccount.

The delivered rule compares the zone attribute, which exists on both sides of the pair:

• Zone of the technical asset - the security zone in which the application represented by the technical asset resides.
• Zone of the technical account - the security zone in which the application the technical account belongs to resides. The value itself is stored on the linked AccAccount.

# Code of the script deciding whether a technical asset may be assigned to a technical account.
# Default: permissive script, nothing is enforced.
idm.sec.tech.accountAssetAssignment.checkScript=techAccountAssetAssignmentAllowAll

Two scripts are delivered with the module:

To enforce matching zones, set the property to techAccountAssetAssignmentZoneMatch. To implement a different rule, create your own script and put its code into the property.

The script is evaluated as a system script and receives two parameters:

The script must return a Boolean - `true` when the pair is acceptable, `false` when it is not. Any other return value is reported as TECH\_ACCOUNT\_ASSET\_ASSIGNMENT\_SCRIPT\_RESULT\_NOT\_BOOLEAN.

The script below is the zone rule delivered as techAccountAssetAssignmentZoneMatch. Use it as a starting point for your own rule.

import com.google.common.base.Strings;
 
// No asset, or asset without zone - no constraint
if (technicalAsset == null || Strings.isNullOrEmpty(technicalAsset.getZone())) {
	return true;
}
 
String accountZone = accAccount == null ? null : accAccount.getZone();
return technicalAsset.getZone().equals(accountZone);

Create the script in the Scripts agenda with category SYSTEM and parameters technicalAsset, accAccount. Classes used in the body have to be allowed for the script - the example above needs com.google.common.base.Strings, eu.bcvsolutions.idm.tech.model.dto.TechnicalAssetDto and eu.bcvsolutions.idm.acc.dto.AccAccountDto.

The check is enforced on save of the involved entities, not only through the wizard or the CSV import:

• change of an AccAccount that is linked to a technical account
• change of the technical asset on a technical account
• creation of the link between a technical account and an AccAccount
• change of a technical asset that is assigned to technical accounts

When the pair is rejected, the operation fails with result code TECH\_ACCOUNT\_ASSET\_ASSIGNMENT\_REJECTED:

Technical asset [asset-code] cannot be assigned to technical account [account-code] (account [account-uid]) - rejected by the assignment check script [techAccountAssetAssignmentZoneMatch].

The technical account CSV import validates the target state of every row before it writes anything, using the same script. A row whose resulting pair would be rejected fails already in the pre-save validation, the rest of the batch continues, and a dry run reports the same verdict.

The tier attribute on AccAccount is an informational, free-form value. Neither of the delivered scripts takes it into account, so by default it imposes no constraint - it is used for classification and table display only. A custom script can use it.

Represents direct assignment of an identity as guarantor for a technical asset.

Represents the assignment of a role to a technical asset, where granting this role to a user designates them as a guarantor of that asset

Represents direct assignment of an identity as holder for a technical asset.

Represents the assignment of a role to a technical asset, where granting this role to a user designates them as a holder of that asset

The overview of technical assets can be accessed via the "Technical assets" agenda in the main menu. By default, the agenda's Inactive filter is pre-set to show active assets only.

The set and order of rendered columns in the technical asset table can be configured via the public configuration property idm.pub.app.show.technicalAsset.table.columns. Comma is used as a separator; the order of the rendered columns is preserved as configured.

# Rendered columns in the technical asset table agenda. Comma is used as separator.
# Order of rendered columns is preserved as configured.
# Available columns:
# - code - unique business identifier of the asset
# - name - asset name
# - description - asset description
# - guarantors - direct and role-based guarantors (truncated to 5)
# - holders - direct and role-based holders (truncated to 5)
# - validFrom - validity start date
# - validTill - validity end date
# - disabled - inactive flag
# - pam - PAM flag (hidden by default - add explicitly to show it)
# - zone - security zone (hidden by default - add explicitly to show it)
 
idm.pub.app.show.technicalAsset.table.columns=code, name, description, guarantors, holders, validFrom, validTill, disabled

The pam and zone columns also control the corresponding filter fields - the PAM and Zone filters are shown only when the column itself is part of the configured value.

After clicking on the magnifying glass icon or the name of a technical asset in the technical asset table, the detail view of the given technical asset is displayed, with "Basic information" as the default sub-agenda. If the user has the Update permission for a technical asset, they can edit the fields.

The Inactive checkbox is always read-only, the activation/deactivation of a technical asset is done using the Activate/Deactivate button. To deactivate/activate a technical asset, the user needs the UPDATE permission. Otherwise the respective button won't be displayed.

The "Technical accounts" sub-agenda contains an overview of all technical accounts under the given technical asset.

This sub-agenda allows you to manage the direct guarantors of the technical asset, as well as guarantor roles, the assignment of which makes a user a guarantor.

This sub-agenda allows you to manage the direct holders of the technical asset, as well as holder roles, the assignment of which makes a user a holder.

This sub-agenda displays the audit log for the technical asset and its related entities.

The audit table has no bulk actions.

To simplify permission setup, the techAssetGuarantorRole and techAssetHolderRole roles have been created, which grant permissions to guarantors and holders of technical roles. These roles can either be nested under userRole or assigned directly to selected users. Default permission settings: