Accounts

RoPE distinguishes between Calculated Account Resource Assignments (CARA) and Calculated Permission Resource Assignments (CPRA).

An identity can only have a permission assignment (CPRA) if it has a corresponding account assignment (CARA) in the same system or in a trusted system.

Account types

RoPE regards all resource data objects as being defined for one or more account types. RoPE uses the information when a resource is assigned to a regular identity to determine the account which it is for.

Example

1. As a result of an assignment policy, RoPE assigns the AD group HR document readers to the identity John Smith.

2. The AD group is defined for the account type called Personal. The identity has an account of the type Personal in AD with the account name JOSM.

3. Because of that, it is the JOSM account that becomes a member of the HR document readers group.

Typically, there are only a few account types defined, such as Personal, Administrative, and Service.

warning

Deleting account types is currently unavailable.

Account type model

An identity to which the account type model applies can only have one account assignment per system per account type. The account type model applies to all regular identities. The account type model does not apply to irregular identities, e.g. technical identities and the special UNRESOLVED identity.

Irregular identities

RoPE treats irregular identities, that is the UNRESOLVED identity and machine identities to whom the account type model does not apply, differently than regular identities:

• It is not required that irregular identities have only one account for a system/account type combination.
• Account renaming is not supported for irregular identities.
• Irregular identities do not have default account names.
• Assignment policies are not evaluated.
• Additional assignments are not assigned.
• SoD violations are not checked.
• The traversal from (explicitly assigned) compound resources to child permissions is not performed.
• The status of business contexts is not evaluated.
• However, the reverse traversal from permission to (implicit) compound resources is still performed. You can disable the implicit assignment for technical identities with the customer setting Skip implicit assignments for technical identities (RoPESkipImplAssnsForTechIdent).

Determining the account type(s) of a resource

When RoPE determines the account type(s) of a resource, it first checks if the resource states one or more account types itself.

If the resource does not state any account types, then RoPE checks if the resource folder states one or more account types. If neither the resource nor the resource folder states any account types, RoPE uses the default type set using the DefaultAccountType customer setting.

You can define permission resources for multiple account types, but you can only define account resources for a single account type.

Account type exceptions

Normally, a calculated assignment can only be for an account type that the resource allows. However, for a calculated assignment originating from an actual assignment in the ODW, an account type may be used although the resource does not allow it. This occurs if the ODW states that another one should be used. The reason for this is that RoPE attempts to represent the actual assignments as they are in the target systems.

Account names

Default account names

Identities that use the account type model have a default account name for the defined account resources. An identity's default account names must be unique amongst the account resources as an identity cannot have the same default account name for two account resources. Identities that do not use the account resource model do not have default account names.

Account name exceptions

Sometimes an identity has an account in a target system in which the account name differs from the identity's default account name. In these cases, the actual account name overrides the default account name.

If there is a resource assignment data object for an account resource that states an account name, it takes precedence over both the default account name, and the target system's account name. So, if you want to change an account name, you can do so by creating a direct resource assignment and explicitly stating the account name.

Another consequence of this behavior is that RoPE cannot calculate identities that have more than one account of the same type in a system, as this does not adhere to the account type model.

Account names on direct assignments

A Resource assignment data object for an account resource can state an account name. If it does, it takes priority over the identity's default account name.

Direct assignments for non-account resources cannot have an account name.

Actual Account Names

The Actual Account Name RoPE extension computes the actual account name for all calculated account resource assignments (CARAs).

The computed value will be available as an attribute named ACTUALACCOUNTNAME.

The value is picked from the actual state or the account name as it is recorded in the Omada Data Warehouse. If there is an unconfirmed actual (provisioning claim) and if this unconfirmed actual is newer than the actual assignment this value is used.

If there is no actual assignment and no unconfirmed actual, the value will be equal to the desired account name.

If you are using Omada Provisioning Service for provisioning, the value will be available for all account tasks as the property ROPE_ActualAccountName.

If you are using Microsoft Identity Manager for provisioning, the value will be available after refreshing the schema for the management agent.

Auto accounts

Omada Identity can automatically assign an account to an identity if it has a permission in the system but lacks an account. Auto accounts can be used for all types of systems.

Specifically, an auto account is assigned for systems where the Auto create accounts checkbox is checked (either on system or resource type data object) if an identity has a desired-state permission resource assignment (CPRA) in the system, and at the same time the identity has no desired-state account (CARA) in the system.

note

If you enable the auto-account for a system, it's advisable to make the account non-requestable and refrain from running any attestation on it, including removing or expiring all attestation verdicts associated with that particular system.

Auto accounts in trusted systems

If the Auto create accounts flag is enabled on a system, RoPE will only create auto accounts for a permission resource in the same system as the permission resource is in.

The flag is used when the account resource is in the same system as the permission resource, for example:

• Active Directory group membership that requires an Active Directory account
• Application role that require an account assignment to an application account resource

If the Auto create accounts flag is not enabled on the system and is set on the permission resource type, then RoPE will create auto accounts in trusted systems as well. Besides supporting auto accounts in trusted systems, the setting allows auto accounts on some resource types and not on other resource types.

Examples of use cases

Application role with child permissions in Active Directory groups. The application does not have account resources but instead, it trusts the Active Directory system.

Exchange shared mailbox resource types, for example, Exchange Shared Mailbox, have the auto account setting enabled. Those shared mailbox resources are designed for technical identities. For ease of use, the account is created automatically in Active Directory or Azure Active Directory.