Provisioning Task

This page specifies the technical principles of the Synchronization service "outbound" provisioning, i.e. managing target accounts on remote Applications, such as creating or updating an LDAP account. It is the counterpart of the "inbound" synchronization.

"Provisioning" is a kind of "synchronization task", but more specifically it designates the "outbound" relation with remote Applications, i.e. from the IDM to the remote Application accounts. An Application's "outbound" mapping is configured in Synchronization service’s Schema Mapping Configuration, see Schema Mapping Configuration.

Concepts

Provisioning obviously encompasses the management of user accounts on remote Applications, but also their group membership, or attribution of Application-specific privileges. Such Application-side notions other than user accounts are referred to as "Entitlements". Accounts are associated with Entitlements, e.g. a user is member of a group.

An Entitlement may represent a privilege, an access right, an application-side role or group or any similar concept. The entitlements are frequently used to represent groups. An Entitlement has its Shadow counterpart in Synchronization service’s repository.

Assignment

Assignment is a generic concept of associating IDM objects (such as Identities) with the things that they should have (or even belong to, like a group). Assignments thus associate Identities with Applications' remote accounts, or with Entitlements such as group membership.

An Assignment describes that an IDM object should have something. It represents a desired state. The actual state of the IDM object may be different. E.g. an LDAP account is assigned to a user, but the account cannot be created because the target LDAP server is currently down. The actual state of the system (the reality) is represented by "links" to Shadow objects. It is Synchronization service’s responsibility to reconcile the real state (links) with the desired state configured through Assignments.

An update of the configuration of Assignments won't trigger immediate actions on the remote accounts impacted by the Assignment change (such as creating or removing accounts). It's only when any sync task is executed (import, reconciliation, provisioning) that Assignments will be recomputed and accounts provisioned according to the new Assignment configuration. When an IDM change is detected (Synchronization service listens on IDM changes AMQP events), the Assignments recomputation and provisioning also occur.

Assignment configurations are regrouped into ApplicationProfiles (see section Application Profile).

When an ApplicationProfile is associated with an IDM object, the IDM object has all the Assignments contained within the profile. The ApplicationProfile is thus the configuration mechanism enabling to give Assignments to an IDM object.

Provisioning Overview

When an IDM object is created or modified (either via a Synchronization service import or via a direct IDM change on which Synchronization service listens), the IDM object is re-synchronized, i.e.:

all its Assignments are resolved (more on that later)
a list of target Entitlements (typically groups) is determined by the Assignments
the provisioning of the remote Application accounts and entitlements is performed according to the above configuration (i.e. writes occur on remote Applications)
for all successful account provisioning operations, the "owning" IDM object is "linked" to the account's Shadow

Application Profile

Assignments are configured and given to IDM objects through Application Profiles.

An ApplicationProfile targets a specific Application, e.g. the "Trade" Active Directory. Having an ApplicationProfile always implies having an account on the target Application (this is implicit), but the ApplicationProfile also configures all the "Entitlement" Assignments (e.g. the asset associations) that are possible for the Application, in terms of group membership and/or privilege attribution.

For example, if an Application internally manages a set of groups and/or privileges (i.e. Entitlements), a set of Assignments will be configured to represent the possible associations of user accounts with those entitlements:

ApplicationProfiles are conditionally associated with IDM objects, such as IDM Identities or IDM Organizations. A profile association is conditional; an IDM object must match an ObjectMatchingCondition to have the ApplicationProfile.

Associating Accounts with Entitlements

This section deals with the association of remote accounts to groups, or the attribution of privileges to an account.

Reminder: an Entitlement represents anything on a remote Application that is not a user account. An Entitlement may thus represent a privilege, an access right, an application-side role or group, or any similar concept. The entitlements are frequently used to represent groups. The primary purpose of an Entitlement is to be associated with Application's accounts (not IDM objects). E.g. an account can be added as a member of a group. Synchronization service can manage the relations between accounts and Entitlements, i.e. put an account into a group or give a privilege (i.e. Application-side right) to an account. An Entitlement resides on the Application, it has its Shadow counterpart in the Synchronization service repository. Associations are configured in Synchronization service, but instances of associations (e.g. "jdoe" is member of the group "sales-fr") are not stored in Synchronization service. They are always read directly from the Application. Therefore Synchronization service does not need to remember the associations. It can read it directly from the Application when a Shadow account is retrieved. Synchronization service fetches the Shadow from its local repository and it uses the identifiers stored in the Shadow to locate the remote account on the Application. Synchronization service retrieves the account object. Then Synchronization service looks for entitlement information in the account and processes any associations, i.e. Synchronization service ensures that the reality conforms with the configuration, i.e. "jdoe" is indeed member of the group "sales-fr" because the configuration says so.

Synchronization service may need to retrieve or search additional objects to fully process the associations. E.g. standard LDAP groups store the list of members in the group object therefore Synchronization service needs first to search the group objects to fully process the association information. Synchronization service does all that transparently. Regardless what kind of grouping and association mechanism is used Synchronization service presents the data in a unified form.

To define associations it is thus needed to configure:

how to represent/materialize the association between an account and an entitlement, i.e. for example configure the name of the attribute of the group holding the account identifiers (e.g. for an LDAP group of class groupOfUniqueNames it is the attribute uniqueMember)
which entitlement should be associated with the account, for example the account "jdoe" should be member of the group "sales-fr", or be given given the privilege "sales"

The configuration principles of associations are detailed below.

Configuring the Representation of an Association (Association Definition)

Associations of accounts and entitlements are defined in the ObjectSchemaMappingDefinition section, at the same level than inbound/outbound mappings. Both "object-to-subject" and "subject-to-object" association directions are supported, see below.

An Association is a relation between two parties: the "subject" and the "object". The subject is the party that receives the Entitlement (usually an account). The object is the Entitlement (usually a group). There are three important things that define the association:

direction: Specifies the direction of association, i.e. if the association point from object to subject or the other way around:
- subjectToObject: Subject has an attribute that contains object identifiers as its values. E.g. an account has a list of groups to which it belongs
- objectToSubject: Object has an attribute that contains subject identifiers as its values. E.g. a group has a list of members
associationAttribute: Name of the attribute which represents the association. This is the attribute that will be modified when the association changes. In object-to-subject associations this is the attribute of the object (e.g. group). In subject-to-object associations this is an attribute of the subject (e.g. account).
valueAttribute: Name of the attribute from which a value for association attribute is taken. The value is taken from this attribute and it will be stored in the association attribute. This attribute will not be modified when the association changes, it is only for reading. In object-to-subject associations this is the attribute of the subject (e.g. account). In subject-to-object associations this is an attribute of the object (e.g. group). This attribute usually contain identifiers.

The association is represented through the AssociationDefinition, whose content is:

name: a name given to the association representation, so that it can by referenced by Assignments using this name, e.g. "group" or "privilege"
target shadowKind, should always be "Entitlement"
target Entitlement's objectType, e.g. "group"
associationDirection: "object-to-subject" or "subject-to-object"
associationAttribute, e.g. "uniqueMember"
valueAttribute, e.g. "id"

The define how to create/update the target Entitlement (e.g. how to create a LDAP groupOfUniqueNames the user account is member of), the target Entitlement itself must possess its own standard ObjectSchemaMappingDefinition section, beside the account's one, so that its properties are known, namely:

the Entitlement's objectClass (e.g. "groupOfUniqueNames")
its objectType ("group" in the above example, or "privilege" if we are associating Application-specific rights), which is referenced by the AssociationDefinition
optional outbound mappings, that may help construct the target Entitlement if it does not exist yet (TODO develop this)

The corresponding Shadow object can thus be created inside Synchronization service’s repository with those information.

Assigning Entitlements

Once the representation of the Association account-entitlement has been configured (see previous section), it is now necessary to identify the target Entitlement instances (groups, privileges) that should be associated with the account. E.g. if an Assignment states that the account "jdoe" must be member of the group named "sales-fr", then there must be a configurable way to target the "sales-fr" Entitlement instance (and no other one) when processing the "jdoe" account.

Target Entitlements are configured inside the "ObjectConstruction" part of an Assignment (see Assignment), under the "Association" sub-configuration of the Assignment's construction.

There are 2 ways to target associated Entitlement instances:

direct (hard-coded), by configuring:
- the hard-coded Entitlement's id, e.g. "sales-group" (or cn="sales-fr,ou=groups,dc=example" for LDAP)
lookup (search), by configuring:
- a SearchExpression which can return one (or several) Entitlement(s)

Example of Assignment structure:

Assignment
Construction
applicationId: "trade"
kind: account
Association:
name: "group"
targetSearchExpression: cn=@VAR[applicationProfileName]-group + ",ou=groups"

If an assignment like this appears in an ApplicationProfile, the name of the profile will be used to determine a group name. Therefore if the name of the profile is foo, the association mechanism will look for the group with name group-foo.

Account Unassignment

Applications may be unassigned from IDM objects for several reasons:

the configuration of an ApplicationProfile is modified
an IDM object does not reference another IDM object anymore (e.g. an Identity is removed from an Organization)

When an Assignment is removed, the corresponding account can be:

deleted; the remote Application's account is removed. The deletion may be delayed via a custom Groovy script, see below
disabled; custom rules such as "delete the account if it has been disabled for more than a month" may be implemented (see Activation Configuration)
left untouched, if the "assignment enforcement policy" is lenient (see next section)

If the Assignment holds an Association, the association between the account and the Entitlement is also removed (e.g. an account is removed from a group).

Deleting and Disabling Remote Accounts

This section describes what may happen to remote accounts when their "owning" IDM objects are deleted or disabled. Deleting an IDM object obviously entails that all its Assignments no longer exist.

The usual reactions would be:

when an IDM object is deleted, its corresponding remote accounts are also deleted
when an IDM object is disabled, its corresponding remote accounts are also disabled

Those are indeed the default reactions.

Deleting Accounts

Accounts can be deleted regardless of their status.

This action will:

Deleted the remote account
Deleted account information from the reporting
Deleted the shadow from the local Domino repository

This action can be set up on a widget or done through the API. To delete an account via the API, make a POST request to api/sync/accounts with DELETE_APPLICATION_OBJECTaction.

The overall JSON structure

CODE

{
  "dominoApplicationId" : "applicationId",
  "accountId"           : "accountId",
  "accountClass"        : "accountClass",
  "action"              : "DELETE_APPLICATION_OBJECT",
  "shadowId"            : "shadowId"
}

Unlinking Accounts

Unlinking an account is only possible via the API and can only be done if the account is not an orphan.