Assignment policy
In Omada Identity, RoPE uses assignment policies for assigning resources to identities.
An assignment policy defines that a set of identities should be assigned to a set of resources. You can define the identities in scope by specifying one or more business contexts and/or using an identity view.
An assignment policy does not need to be scoped on both using a view and business context(s): You can scope both or only one of the two.
We recommend to keep the number of used scoping views low, as it adds an extra load on RoPE when many scoping views are used.
Assignment Policies and Account Types
When creating an assignment policy using an Application role (personal account only) with a child resource (called resource below), take into consideration the following cases:
| If the Assignment policy is assigned to... | And the Resource is for... | Then... |
|---|---|---|
| Personal | Admin | Nothing is assigned. |
| Personal | Admin and Personal | If the identity has a personal account or if auto-account is enabled, then an assignment is made for personal account. |
| Personal and Administrative | Admin and Personal | The resource is assigned to both admin and personal accounts if the identity has such account or it auto-account is enabled. |
Account type handling for child resource of account resources
There is a business rule for direct assignments as well as assignment policies that the configured account type (on the direct assignment and on the policy) applies for the referenced resource(s) meaning that the resource will only be assigned to an account of that type.
However, this is different for roles. The account type of a role (resource) does not define a filter for child resources to only apply to that parent account type. It only defines which account is required for that role.
Enabling child resources on, for example, account resource types and thereby having permissions as a child resource to accounts, does not change that behavior - the child resource defines its own account types.