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.
-
As a result of an assignment policy, RoPE assigns the AD group HR document readers to the identity John Smith.
-
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.
-
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.
The account type property on a direct assignment and on an assignment policy sets the scope of the accounts being assigned to the resources.
For instance, a direct assignment with the Administrative account type for a particular permission resource will only grant permission to the Administrative account, and not the Personal account.
The scope also applies to child resources to directly assigned roles and to roles in assignment policies. Child resources are only granted to accounts with an account type in the scope.
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 selected (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.
If auto account creation is enabled for a system or resource type, it will not create an account if an existing account for that identity and system already exists and has no defined desired state. This can cause an issue if the existing account is disabled, as the auto account would generate an enabled account.
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.
If the Auto create accounts flag is enabled both on the system and the permission resource type, the system-related path is used, as if the flag was enabled on the system only.
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 Microsoft Entra ID.