Managing Provisioning
Managing the Provisioning system consists of the following tasks:
-
Managing users and user templates
-
Managing user facets, personas and functional users
-
Managing business objects
-
Managing tickets
-
Managing privileges (roles, permissions, and groups)
-
Managing policies (access policies, rules and operations, delegations)
-
Managing request workflows
-
Managing target systems
-
Managing audit and compliance
-
Managing certification campaigns
-
Managing domains
-
Configuring and managing the Provisioning Configuration
-
Managing states
-
Managing the attribute flow
This chapter gives a brief overview of each of these tasks, with more detailed information provided in the individual chapters on these tasks.
Managing Users
User management consists of two main tasks:
-
Maintaining an accurate and up-to-date directory of the users to be administered with DirX Identity
-
Assigning privileges to users (controlling user rights) either by hand or automatically with policies.
Administrators carry out these tasks manually with the DirX Identity Manager or automatically with one of the workflows of the Connectivity view.Alternatively the Web-based interface Web Center can be used to assign privileges to users.
Maintaining Users
User maintenance tasks include:
-
Adding users, deleting users, and changing the attributes of users to be administered with DirX Identity, especially the attributes associated with user lifetime and deactivation periods (if DirX Identity masters the user data)
-
Synchronizing the DirX Identity user with a corporate directory master (if a corporate directory masters the user data)
-
Creating and maintaining user templates (if DirX Identity masters the user data)
Assigning Privileges to Users
Assigning privileges to users is the main administrative function in DirX Identity.In the DirX Identity Provisioning Configuration, the administrator controls a user’s rights by assigning one or more privileges to the user.DirX Identity then resolves the assigned privileges to the appropriate groups in the target systems (privilege resolution).
Next, DirX Identity Connectivity distributes the user-group relationships to the appropriate target systems (privilege distribution).
The administrator can also assign one or more privileges to a user template.In this case, DirX Identity stores the user-privilege assignment in its identity store, but does not perform privilege resolution and distribution until the administrator uses the template to create a real user.
Managing User Facets, Personas and Functional Users
User facets, personas and functional users are special representations of users.A user represents a user in an identity management system.It is the main entry for this user and typically represents the personal accounts for this user.
A user facet is an alternative representation of a user that reflects the user’s different positions in an organization, for example, a student who works as a teaching assistant and as a tutor.The "tutor" and "teaching assistant" user facets model the privileges that derive from his capacity as a tutor and a teaching assistant, while the "student" user facet models the privileges that derive from the user’s position as a student.The main user, meanwhile, models all of these privileges with the resulting accounts.The lifetime of the user object typically comprises the lifetime of all associated user facet objects, and the lifetime of a user facet object can be shorter than the user lifetime.The user facet object offers a way to model different functions for a user within a single organizational unit.User facets allow you to model multiple privilege profiles that share the same accounts as the user.A user facet is related to a user via the owner attribute.In contrast to a functional user, the user facet object normally changes its status with the corresponding user object and is not re-assigned to another user.
A persona is an alternative representation of a user that reflects the user’s different functions in the company, for example, an administrator or a project manager.The accounts and the access rights for each representation may be quite different and auditing should be able to distinguish between the different representations for the user.The lifetime of the user object typically comprises the lifetime of all associated persona objects, and the lifetime of a persona object can be shorter than the user lifetime.The persona object offers a way to model different functions for a user that works in the same company but for different organizational units.A persona is related to a user via the owner attribute.In contrast to a functional user, the persona object normally changes its status with the corresponding user object and is not re-assigned to another user.
A functional user is a resource that is assigned to an identity.Examples are a global or group mailbox, a physical room with a phone or a working student entry.The user either manages these resources or is responsible for them.A functional user is related to a user via the sponsor attribute.In contrast to a persona, the functional user can survive the user and must be re-assigned to another sponsor (user) if the current user is deleted or is no longer responsible for the resource.
The following figure illustrates the relationships between user, user facet persona and functional user objects:
Managing User Facets
Since a user facet is a special representation of a user, maintaining user facets is closely related to maintaining users. User facet maintenance tasks include:
-
Adding user facets, deleting user facets, and changing the attributes of user facets to be administered with DirX Identity, especially the attributes associated with user facet lifetime and deactivation periods (if DirX Identity masters the user facet data).
-
Synchronizing the DirX Identity user facet with a corporate directory master, if the concept of different user representations is also supported by the corporate directory (if a corporate directory masters the user facet data). Otherwise, only the user object is synchronized, and the user facet is maintained in DirX Identity.
-
Assigning privileges to user facets, which you perform with same procedures and under the same rules as for user privilege assignment.
Managing Personas
Since a persona is a special representation of a user, maintaining personas is closely related to maintaining users. Persona maintenance tasks include:
-
Adding personas, deleting personas, and changing the attributes of personas to be administered with DirX Identity, especially the attributes associated with persona lifetime and deactivation periods (if DirX Identity masters the persona data).
-
Synchronizing the DirX Identity persona with a corporate directory master, if the concept of different user representations is also supported by the corporate directory (if a corporate directory masters the persona data). Otherwise, only the user object is synchronized, and the persona is maintained in DirX Identity.
-
Assigning privileges to personas, which you perform in the same way under the same rules as privilege assignment to users.
Managing Functional Users
Since a functional user is a special representation of a user, maintaining functional users is closely related to maintaining users.Functional user maintenance tasks include:
-
Adding functional users, deleting functional users, and changing the attributes of functional users to be administered with DirX Identity.
-
Maintaining the sponsor if the related user for the functional user changes.
-
Assigning privileges to functional users, which you perform with same procedures and under the same rules as for user privilege assignment.
Managing Business Objects
You can use business objects to keep common information in a centrally located individual object rather than in individual user entries, where it can become inconsistent over time.Examples of business objects include organizations, organizational units, countries, locations, and projects.Business objects have many uses:
-
You can use a business object to assign roles, permissions and groups referenced from the business object automatically to all linked users.
-
You can use business object data such as "address" or "street" in linked user attributes and master this data at the business object.
-
You can use business objects as sources for role parameters and proposal lists.
Business object management consists of the following tasks:
-
Defining a set of business objects that help you to maintain an accurate and up-to-date directory of central data that can be used by user entries.DirX Identity delivers a set of default business objects that you can customize to your needs, and you can define your own types of business objects as necessary.
-
Setting up event-based maintenance workflows that inherit privileges from business objects to users.
-
Setting up event-based maintenance workflows that propagate attribute changes from business objects to users.
-
(Optional) Setting up workflows to synchronize data from external data sources.
Managing Tickets
By default, DirX Identity processes updates to its identity management data immediately.For example, when an administrator changes a user’s department attribute, the change is applied right away (or when approval is obtained).In some cases, however, administrators may want to delay the application of a change and schedule it for a future date; for example, to process an employee transfer from one department to another.DirX Identity provides a built-in ticket system that allows administrators to specify the changes to an identity management object that should be made at a specified date in the future.The changes are then deferred and saved as temporary information in a ticket until the specified date arrives, at which point the DirX Identity Services layer processes them automatically.DirX Identity also allows for the integration of external ticket systems and provides other means for service management integration.
Ticket management tasks generally include:
-
Creating tickets in DirX Identity Web Center or Manager to schedule object changes
-
Viewing tickets to check their status and content
-
Making changes to tickets to correct errors in ticket data
Managing Policies
DirX Identity supports different kinds of policies:
-
Access policies, to control the access to objects in the Provisioning Configuration and for use for delegation and approval workflows.
-
Object policies for object related events, modification and deletion.
-
Rules and operations, to automate consistency checks and perform automatic provisioning.
-
Delegations, to propagate access rights from one user to another one (optionally with a time restriction).
Policy management for access management and delegation consists of these tasks:
-
Adding access policies, deleting access policies or maintaining access policies
-
Defining which access policies can be delegated and which ones cannot be delegated.
-
Creating and maintaining delegations via the DirX Identity Web Center
Policy management for consistency checking and automatic provisioning consists of these tasks:
-
Adding attribute policies, deleting attribute policies or maintaining attribute policies
-
Adding event policies, deleting event policies or maintaining event policies
-
Adding delete policies, deleting delete policies or maintaining delete policies
-
Setting up event-based and request workflows that are triggered by attribute, event and delete policies
-
Adding rules, deleting rules or maintaining rules
-
Adding operations, deleting operations or maintaining operations
-
Running rules against the database to check correctness
-
Setting up Tcl-oriented workflows to run these rules regularly.
Managing Roles, Permissions, and Groups
Managing privileges (roles, permissions, and groups) involves setting up and maintaining the privilege structure; that is, the roles and permissions and the role-permission-group relationships.Role management tasks include:
-
Setting up and maintaining the role structure
-
Creating, changing, and deleting roles
-
Building the role hierarchy (role-to-role relationships)
-
Defining role parameters and their application to roles
-
Creating, changing, and deleting permissions
-
Defining permission parameters and their application to permissions
-
Creating, changing, and deleting groups
Administrators carry out these tasks with the DirX Identity Manager.
Managing Request Workflows
Request workflows permit you to manage the life-cycle of objects in a controlled way including the necessary approval and certification steps.Management tasks include:
-
Configuring central parameters and services (for example, setting up e-mail forms for approval or certification requests)
-
Setting up and maintaining request workflow templates
-
Monitoring and maintaining request workflow instances
Managing Target Systems
Target system management tasks include:
-
Configuring the workflows that:
-
Perform the initial load of existing target system data - accounts, groups, and their relationships - into the Provisioning Configuration (this is a set-up task vs. a day-to-day task)
-
Load the Provisioning Configuration data into the target systems to synchronize them (either as event-based or scheduled privilege distribution)
-
Periodically reconcile the target system data with the Provisioning Configuration
-
Configuring name space rules, for example, naming rules for accounts or passwords
-
Adding and deleting target systems to and from the Provisioning Configuration
| Provisioning workflows are not needed for managing virtual target systems because the target system data is contained in the Provisioning Configuration. |
Administrators use DirX Identity Manager to configure the initial load, event-based privilege distribution, and scheduled validation workflows.
Managing Compliance
Compliance services provided in DirX Identity include:
-
Segregation of Duties (SoD)
-
Certification campaigns
-
Audit trail
-
Status reporting
Managing Segregation of Duties (SoD)
Segregation of duties - often called separation of duties or SoD - is a type of policy that can be applied to user-privilege assignments that constitute conflicts of interest and a mechanism for checking whether the privilege assignments granted to a user comply with that policy. The SoD policies define the conflicting privileges, while the SoD mechanism checks the user-privilege assignments for compliance with the policy and reports any discovered violations.
The section "Managing SoD Policies" describes the management tasks associated with SoD policies, while the section "Managing SoD" describes the internal and external features that DirX Identity provides for SoD policy definition and for SoD violation checking and resolution.
Managing Certification Campaigns
Certification campaigns let you regularly certify user-role assignments. A campaign manager uses Identity Manager to set up a campaign. This task mainly involves defining the set of users to be certified and the start and end of the campaign. DirX Identity’s Certification Campaign Controller workflow automatically starts and monitors the campaign.
When the start date is reached, the Certification Campaign Controller workflow creates a certification task for every user to be certified, determines the approver, and informs the approver via email. The approvers must either accept or reject each role assignment.
When the end date of the campaign is reached, the Certification Campaign Controller workflow removes all rejected assignments and notifies the affected users. The campaign manager can produce a report on the whole campaign.
The section "Managing Certification Campaigns" in the chapter "Managing Compliance" provides more information about this process, while the DirX Identity Use Case Document User Certification Campaigns gives a complete description.
Managing Auditing
DirX Identity’s audit trail mechanism can track all relevant identity management events, recording information such as the date/time the event occurred, the identity that initiated it, the users who approved it, and whether it was carried out by hand or automatically by a policy.
Auditing management tasks include:
-
Configuring domain-wide audit trail parameters.
-
Setting up audit policies for each object to be audited. DirX Identity supplies a set of pre-configured audit policies, and you can also define your own audit policies that address your company’s requirements.
Audit trails are archived in XML format to a central audit store for centralized visibility and traceability and can be optionally secured with a system-specific digital signature to make them tamper-proof. To extract and view the audit data, you can:
-
Configure the audit trail workflow to extract audit data to files, view them with third-party XML tools or move them to your audit database.
-
Install DirX Audit, set up the required plug-ins and view the audit data with the DirX Audit Manager.
The section "Managing the Audit Trail" in the chapter "Managing Compliance" provides more information about these tasks.
Managing Status Reporting
Status reporting is part of DirX Identity’s audit and compliance service.Status reports provide information about the current state of identity management data; for example, which users have which privileges, which privileges are unused, and which users have been given delegated administrative tasks.Administrators can generate status reports automatically or on demand.The section "Managing Status Reports" provides more details.
Managing Domains
A domain is a high-level segregation of Provisioning Configuration data that can be used to establish different policies and privilege models in a single Provisioning system.Domain management tasks include:
-
Setting up a domain
-
Setting up domain-specific parameters and flags
-
Generating information about a domain (reports)
-
Setting up a corresponding Connectivity domain
-
Maintaining Identity Store consistency by scheduling workflows to run all relevant rules
DirX Identity allows you to create multiple domains, which can be useful when a service provider runs one installation of DirX Identity that manages different customers; for example, company PQR and company XYZ.You can create separate domains for each customer, which allows the service provider to maintain a clear separation of each customer’s access rights and data.Use the DirX Identity Configurator to create domains.
You can also set up multiple tenants - like company PQR and company XYZ - within a single domain; the DirX Identity Use Case Document Using Domains provides more information about this configuration.
Setting up a Domain
Setting up a domain consists of the following tasks:
-
Changing the directory schema (using standard directory tools) and, as necessary, changing the object descriptions and property page descriptions of one or more of the following Provisioning objects: user, account, group, permission, role, business objects and sub-tree container
-
Defining the administrators for all objects and configuring their access rights using access policies using DirX Identity Manager
-
Adding the users to the DirX Identity Store (Provisioning Configuration) by hand with Web Center or DirX Identity Manager. Alternatively you can configure the workflows in the Connectivity domain to add and maintain them automatically (if you are going to import users from an external source)
-
Configuring the Identity Store workflows using DirX Identity Manager
-
Configuring the status report workflows using DirX Identity Manager
Managing Domain-Specific Information
Information management tasks consist of getting information from the Provisioning system.These tasks include:
-
Monitoring the Identity Store workflows with DirX Identity Manager and the Web Admin
-
Evaluating generated status reports
-
Adjusting the schema and administrator responsibilities and access rights as necessary
Managing the Provisioning System
Managing the Provisioning System consists of the tasks that are necessary to provide provisioning.These tasks include:
-
Creating a domain and specifying a domain administrator
-
Configuring access control for the Provisioning Configuration via access policies
-
Establishing general security settings, such as authentication requirements and settings for remote access
-
Defining domain-specific configuration parameters
Managing States
To understand DirX Identity, it is important to understand the concept of "state" for the various objects (users, accounts, groups) and their interrelationship (account-to-group memberships).
This section describes:
-
User states - the life-cycle and the possible states of users.
-
Persona states - the life-cycle and the possible states of personas.
-
Functional users states - the life-cycle and the possible states of functional users.
-
Account states - the life-cycle and the possible states of account objects.
-
Role states - the life-cycle and the possible states of role objects.
-
Permission states - the life-cycle and the possible states of permission objects.
-
Group states - the life-cycle and the possible states of group objects.
-
Assignment states - the life-cycle and the possible states of account-to-group assignments.
-
How privilege resolution works.
-
The relationship between the user and the account life-cycle.
The descriptions of DirX Identity states given in this section use the following notation conventions to keep the state diagrams as simple as possible:
-
The dxr prefixes are omitted from the attribute names: we use StartDate instead of dxrStartDate and EndDate instead of dxrEndDate.
-
Virtual states are used. For example, if a user with a passed StartDate and a passed DisableStartDate is entered into the Identity Store, the user shortly reaches the ENABLED state due to the StartDate. Because the DisableStartDate is also passed, the state switches immediately from ENABLED to DISABLED. In this case, the ENABLED state is not stable, thus the result state is the DISABLED state.
DirX Identity supports domain-specific timing parameters that control the setting of individual timing parameters at user, account and group objects. See the section "Timing" in the chapter "Domain Properties" of the context-sensitive help for more information about these timing parameters.
Several types of actors trigger the state transitions we describe in the next sections:
-
Administrators - Administrators perform actions via graphical user interfaces (DirX Identity Manager, DirX Identity Web Center). These actions result in requests to a built-in services layer that performs both simple and complex operations. An example of a simple operation is the change of a status attribute at a single object; an example of a complex action is a privilege resolution that may affect hundreds of objects.
-
Services - Services are either triggered by administrators, by schedules or by an event. An example of a service is the User Resolution workflow. It checks and resolves users, which may result in state changes of the user object and other related objects. Another example is a policy workflow, which performs consistency checks on some objects that can result in state changes. As described earlier, services can be part of a user interface operation.
-
Provisioning workflows - Accounts and groups are representations of the real objects in the connected systems. The initial load / validation and synchronization workflows adjust the TSState attributes.
| The creation workflows should not set and handle user state attributes directly. Instead, they should set the timing attributes like StartDate, EndDate, DisableStartDate, DisableEndDate and the To Be Analyzed (TBA) flag. The TBA flag triggers services that evaluate the user object and set the user states. This procedure guarantees that the state machine is always the same and not dependent on a special creation workflow logic. |
User States
User objects represent active identity objects. Templates are inactive users that are not yet resolved. A user can have the following states:
- TEMPLATE
-
the settings made for this user are used as a template for new users. Privilege assignments and attribute settings are not resolved for these user objects.
- NEW
-
a new user that can be used for 'in advance' provisioning. The user does not have any rights in the domain because all accounts are disabled with no EndDate set. All necessary group assignments exist for all privilege assignments that are valid, but they are not activated due to the disabled accounts.
'In advance' provisioning means that the administrators in the connected systems can perform all necessary additional preparative steps so that the user can work immediately when state ENABLED is reached. For a detailed discussion of this topic, see the section "How Privilege Resolution Works". - ENABLED
-
the user is established; the corresponding user object is up to date and valid, the privilege assignments are active.
All corresponding accounts are set to state ENABLED.
All necessary group assignments exist and are activated for all privileges that are currently valid. - DISABLED
-
the privilege assignments for this user are currently disabled, the user does not have any rights in the domain because all accounts are disabled. All necessary group assignments exist for all privilege assignments that are valid, but they are not activated due to the disabled accounts.
- TBDEL
-
the user object shall be deleted from the DirX Identity Provisioning system. This is done, when all assigned accounts in the connected systems are deleted or the end date for deletion is reached.
we chose to name this state TBDEL (to-be-deleted) instead of Deleted to indicate that the entry is assumed to be deleted but it still exists.
The following user attributes are related to these states (the LDAP attribute is shown in parentheses):
- StartDate (dxrStartDate)
-
the date at which the user enters the company (activation of the user).
- EndDate (dxrEndDate)
-
the date at which the user leaves the company or when he is scheduled to leave (deactivation of the user).
- DisableStartDate (dxrDisableStartDate)
-
the start date of a temporary deactivation phase (for example, a maternity leave).
- DisableEndDate (dxrDisableEndDate)
-
the end date of the temporary deactivation phase.
- DeleteDate (dxrDeleteDate)
-
the date at which a user in the TBDEL state is physically removed (the LDAP entry is deleted).
entries that still contain audit trail information are not deleted until this audit trail information is moved to an audit database.
The following figure illustrates the user states and how they function in conjunction with the user attributes described here:
As shown in the figure, the possible transitions are as follows:
(does not exist) → TEMPLATE - a new user object created with the "template" flag set results in the state TEMPLATE. No privilege resolution is performed; that is, privileges that are assigned are not yet resolved.
(does not exist) or TEMPLATE → NEW - a new user object or a template whose StartDate is not yet reached enters the state NEW. A privilege resolution is performed but all newly created accounts enter the state DISABLED. All necessary group assignments are made for all privilege assignments that are valid.
(does not exist) or TEMPLATE → ENABLED - a new user object or a template with StartDate reached enters the state ENABLED. A privilege resolution is performed and all newly created accounts enter state ENABLED. All necessary group assignments are made for all privilege assignments that are valid.
TEMPLATE → (does not exist) - you can simply delete templates.
NEW → ENABLED - when the StartDate is reached, the state changes from NEW to ENABLED. The state of all relevant accounts is changed to ENABLED.
NEW → TBDEL - when the EndDate is passed or an administrator deletes the entry with the user interface, the state changes from NEW to TBDEL. The DeleteDate of the user is set to 'today + maximumTimeToDeletaAnObject'. All accounts are set to state DISABLED, which results in inactive group assignments. The EndDate of all accounts are set to 'today + maximumTimeToDeleteAnObject'.
ENABLED → NEW - this state change occurs if the StartDate is not yet reached. The state of all relevant accounts is changed to DISABLED.
ENABLED → DISABLED - this state change occurs if either the DisableStartDate is reached or the entry is disabled by an administrator via the user interface. The DisableStartDate is set to today if not yet defined.
The state of all relevant accounts is changed to DISABLED. The EndDate is not set.
ENABLED → TBDEL - when the EndDate is passed or an administrator deletes the entry with the user interface, the state changes from ENABLED to TBDEL. The DeleteDate of the user is set to 'today + maximumTimeToDeleteAnObject'. All accounts are set to state DISABLED, which results in inactive group assignments. The EndDate of all accounts are set to 'today + maximumTimeToDeleteAnObject'.
DISABLED → ENABLED - this state change occurs if either the DisableEndDate is passed or an administrator enables the entry with the user interface. The state of all relevant accounts is changed to ENABLED.
DISABLED → TBDEL - when the EndDate is passed or an administrator deletes the entry via the user interface, the state changes from DISABLED to TBDEL.
The DeleteDate of the user is set to 'today + maximumTimeToDeleteAnObject'. All accounts are set to state DISABLED. This results also in inactive group assignments. The EndDate of all accounts is set to 'today + maximumTimeToDeleteAnObject'.
TBDEL → ENABLED - an entry in the TBDEL state can be reactivated by setting the EndDate to a date past the current date. DeleteDate is reset.
TBDEL → (does not exist) - this state change occurs if the DeleteDate is passed (or this attribute does not exist) and the entry does not contain any audit trail information.
All privilege assignments are removed.
|
A note about user and account lifetimes:
Accounts can exist for longer than their associated user. When the user reaches the TBDEL state, all the accounts change to the DISABLED state with an end date 'today + maximumTimeToDisableAnObject'. When the user’s DeleteDate has passed, the DirX Identity system physically removes it. When an account’s EndDate has passed, it switches to state DELETED with a new EndDate 'today + maximumTimeToDeleteAnObject'. DirX Identity only removes it from the DirX Identity Store when the corresponding account in the connected system disappears or its grace period defined by the EndDate is passed.
|
User Facet and Persona States
User facets and personas have the same states and state transitions as users. Since personas belong to the identity represented by the user, their life-cycle is related to the user’s life-cycle:
-
A user facet or a persona cannot outlive its related user.
-
Disabling a user also disables his related user facets and personas.
The consequence for the user facet and persona state handling is as follows:
-
As long as the related user is in the state DISABLED, the user facet and persona are also DISABLED, unless their state is TBDEL.
-
If a user’s state changes to TBDEL, the states of his user facets and personas also change to TBDEL, and their DeleteDates/account states are handled the same way as for the user.
Note that you can customize the state handling of user facets and personas by implementing your own state machine for them. See the section "Custom Status Modules" in the chapter "Customizing Program Logic" in the DirX Identity Customization Guide for details.
Functional User States
Functional users have the same states and state transitions as users. In contrast to a persona, a functional user’s life-cycle does not depend on his sponsor’s life-cycle. If its sponsor’s state changes to TBDEL, the functional user’s sponsor attribute is cleared and a request workflow Relink Functional User is started to assign a new sponsor to the functional user.
| You can customize the state handling of functional users by implementing your own state machine for functional users: See the section "Custom Status Modules" in the chapter "Customizing Program Logic" in the DirX Identity Customization Guide for details. |
Account States
Accounts represent identities in connected systems. Accounts may have an associated user. Account states depend on the states of the associated user and on the accounts in the connected system. An account can have these states:
- Imported
-
the account was created / exists in the connected system, but is not yet requested (handled) by DirX Identity Provisioning.
- Enabled
-
the account is to exist, be created in the connected system and be enabled.
- Disabled
-
the account is to exist, be created in the connected system and be disabled.
- Deleted
-
the account is to be deleted in the connected system.
- Reserved
-
the account is reserved with a specific name for a user. This is an intermediate state that occurs during assignment of a privilege.
The following account attributes are related to these states (the LDAP attribute is shown in parentheses):
- EndDate (dxrEndDate)
-
depends on the account’s state: If it is DISABLED, it defines the date at which the account’s state is changed to DELETED. If it is DELETED, it defines the date at which the account will be deleted.
- State in connected system (dxrTSState)
-
the state of the account in the connected system. Possible states are:
- ENABLED
-
the account exists in the connected system and is enabled.
- DISABLED
-
the account exists in the connected system and is disabled.
- DELETED
-
the object has been deleted in the connected system without DirX Identity Provisioning having requested it! This state is only set by the validation workflow together with a message in the ToDo (dxrToDo) attribute that reminds the administrator to inspect this situation.
- NONE
-
set when the object is created by the DirX Identity services.
Account State Transitions
The following figure illustrates the account states and how they function in conjunction with the account attributes just described:
As shown in the figure, the possible transitions of the account state are as follows:
(does not exist) → IMPORTED - the initial load or validation workflows create new accounts in the target system in state IMPORTED. The TSState is set according to the state in the connected system.
(does not exist) → RESERVED - if the first group is assigned in the DirX Identity Manager, an account is created in the temporary state RESERVED to prevent the same account from being created in another application in parallel. If the group assignment is aborted, the account is deleted. If the group assignment succeeds, the state changes either to ENABLED if the user is ENABLED or to DISABLED if the user is in state NEW or DISABLED.
| in DirX Identity Manager, the account state is always shown as ENABLED or DISABLED even if it is still in state RESERVED. In other applications (for example, Web Center), the state is shown as RESERVED. |
| due to a network error or an error in the account object description, the state can remain RESERVED. To solve this problem, find and correct the cause of the error and then re-run the privilege resolution service on the user. |
(does not exist) or RESERVED → ENABLED - if the user is in state ENABLED and the first group is assigned, the account enters the ENABLED state, too.
(does not exist) or RESERVED → DISABLED - if the user is in state NEW or DISABLED and the first group is assigned, the account enters the DISABLED state.
IMPORTED → ENABLED - if an account exists in the target system, the user is in state ENABLED and the first group is assigned, the account enters the ENABLED state.
IMPORTED → DISABLED - if an account exists in the target system and the user is in state DISABLED or DELETED, the account enters the DISABLED state.
IMPORTED → DELETED - if the account is deleted, it enters the state DELETED.
ENABLED → DISABLED - if a user is in state DISABLED or TBDEL, the account enters the DISABLED state (if the user is in state TBDEL, the EndDate of the account is set to 'today + maximumTimeToDisableAnObject'). If the resolution of an enabled user results in no assigned groups, the account is set to state DISABLED (the EndDate of the account is set).
ENABLED → DELETED - if the account is to be deleted and the TSState is not DELETED, the account enters state DELETED.
ENABLED → (does not exist) - if the account is to be deleted and the TSState is DELETED and there is no audit trail information present, the account is simply removed from the Identity Store.
DISABLED → ENABLED - if the user is ENABLED and the privilege resolution assigns the first group, the account enters state ENABLED.
DISABLED → DELETED - if the EndDate has passed, the account enters state DELETED. Alternatively, this state is reached if the account is deleted and the TSState is not DELETED.
DISABLED → (does not exist) - if the account is to be deleted and the TSState is DELETED and there is no audit trail information present, the account is deleted from the Identity Store.
DELETED → (does not exist) - the account is deleted from the Identity Store if the EndDate has passed, TSState is DELETED and no audit trail information is still present.
Provisioning Workflow State Handling
The provisioning workflows control the account TSState attribute: they change its value to the current situation in the connected system as follows:
-
The initial load workflow reads all entries from the connected system and imports them into the Identity Store. The state is set to IMPORTED and the TSState is set to ENABLED or DISABLED depending on the state in the connected system.
-
The validation workflow reads all entries from the connected system and imports the changes to the Identity Store. Note that the initial load and the validation workflows are almost identical. The only difference is that the validation workflow writes a ToDo message in cases where the administrator must be notified.
-
The synchronization workflow reads all necessary actions from the Identity Store, updates the connected system accordingly and then changes the TSState in the Identity Store. The synchronization workflows in the direction "connected system to Identity Store" usually operate on a delta-based scheme and therefore do not detect any unsolicited object deletions. Nevertheless, depending on the features of the connected system, the workflows may detect and acknowledge requested deletions.
The following figures and tables show all account state combinations (State, TSState) and the possible transitions that can occur during the import operation at the Identity Store.
-
In the figures, dashed lines indicate transitions that should not occur under normal circumstances but which can occur due to (illegal) administrator actions or other malfunctions. DirX Identity uses the dashed-line transition to solve the problem.
-
In the tables, bold states in the Resulting state / TSState column indicate that the state is changed.
-
In the tables, the following columns indicate the following information:
-
Previous State / TSState - represents the State/TSState in the Identity Store before the workflow is run.
-
Connected system account - shows the state of the account in the connected system before the initial load / validation workflow is started or the TargetSystem → IdentityStore part of the synchronization workflow runs.
-
Resulting State / TSState - represents the State/TSState in the Identity Store after the workflow completes.
Here is an example of how to read this diagram: the synchronization workflow reads all objects that are in state ENABLED and TSState NONE and then creates the corresponding accounts in the connected system. After successful creation, the TSState in the Identity Store is set to ENABLED, shown in the figure with the path ENABLED / NONE → Account enabled → ENABLED / ENABLED.
The following table describes these transitions (the account in the Identity Store is ENABLED):
| No | Previous State / TSState |
Connected system account | Resulting State / TSState |
Comments |
|---|---|---|---|---|
1 |
ENABLED |
does not exist |
ENABLED NONE |
The account has not yet been created in the connected system. The Identity Store and the connected system are synchronized. |
2 |
ENABLED |
is enabled |
ENABLED ENABLED |
The account exists or has been created by the synchronization workflow in the connected system and is enabled. The TSState in DirX Identity is set accordingly. |
3 |
ENABLED |
is disabled |
ENABLED DISABLED |
The account does not exist in the connected system; a connected system administrator created the account and then disabled it. The initial load / validation workflows detect the situation and set the ToDo field of the account to "Created in target system". The next synchronization workflow will enable the account. |
4 |
ENABLED |
is enabled |
ENABLED ENABLED |
The Identity Store and the connected system are synchronized. |
5 |
ENABLED |
is disabled |
ENABLED DISABLED |
The account exists in the connected system; a connected system administrator disabled it. The initial load / validation workflows detect the situation and set the TSState accordingly. The next synchronization workflow will enable the account. |
6 |
ENABLED |
does not exist |
ENABLED DELETED |
A connected system administrator has deleted the account in the connected system. The initial load / validation workflows detect the situation, set the ToDo field to "Deleted in target system" and set the TSState accordingly. An administrator should examine the situation and resolve it (for example, delete the object in the Identity Store). |
7 |
ENABLED |
is enabled |
ENABLED ENABLED |
A connected system administrator has disabled the account in the connected system. The synchronization workflow has enabled the account again and set the TSState accordingly. DirX Identity and the connected system are synchronized again. |
8 |
ENABLED |
is disabled |
ENABLED DISABLED |
The initial load / validation workflows have verified the situation but have not made any changes because the Identity Store and the connected system are synchronized. |
9 |
ENABLED |
does not exist |
ENABLED DELETED |
A connected system administrator has deleted the disabled account in the connected system by. The initial load / validation workflows detect the situation, set the ToDo field to "Deleted in target system" and set the TSState accordingly. |
10 |
ENABLED |
is enabled |
ENABLED |
A connected system administrator deleted the account in the connected system and then re-created it in the state ENABLED. The initial load / validation workflows detect the situation, set the ToDo field of the account to "Recreated in target system" and set the TSState accordingly. |
11 |
ENABLED |
is disabled |
ENABLED DISABLED |
A connected system administrator deleted the account in the connected system and then re-created it in the state DISABLED. The initial load / validation workflows detect the situation, set the ToDo field of the account to "Recreated in target system" and set the TSState accordingly. |
12 |
ENABLED |
does not exist |
ENABLED DELETED |
The account is deleted in the connected system and the synchronization workflow will never recreate it. Instead, the administrator must create this account in DirX Identity (either manually or by policies). A subsequent privilege resolution will create a new account. |
The following table describes these transitions (the account in the Identity Store is IMPORTED or does not exist):
| No | Previous State / TSState |
Connected system account | Resulting State / TSState |
Comments |
|---|---|---|---|---|
1 |
(does not exist) |
is enabled |
IMPORTED ENABLED |
Accounts that exist in the connected system but not yet in the Identity Store are created by an initial load / validation workflow. The TSState is set to ENABLED and the ToDo field is set to "Created in target system". |
2 |
IMPORTED ENABLED |
is enabled |
IMPORTED ENABLED |
Identity Store and connected system are synchronized. |
3 |
IMPORTED ENABLED |
is disabled |
IMPORTED DISABLED |
The connected system administrator has disabled the account. |
4 |
IMPORTED ENABLED |
does not exist |
IMPORTED DELETED |
The connected system administrator has deleted the account. |
5 |
(does not exist) |
is disabled |
IMPORTED DISABLED |
Accounts that exist in the connected system but not yet in the Identity Store are created by an initial load / validation workflow. The TSState is set to DISABLED and the ToDo field is set to "Created in target system". |
6 |
IMPORTED DISABLED |
is enabled |
IMPORTED ENABLED |
The connected system administrator has enabled the account. |
7 |
IMPORTED DISABLED |
is disabled |
IMPORTED DISABLED |
The Identity Store and the connected system are synchronized. |
8 |
IMPORTED DISABLED |
does not exist |
IMPORTED DELETED |
The connected system administrator has deleted the account. |
9 |
IMPORTED DELETED |
does not exist |
(does not exist) |
A consistency rule will delete the account after all audit trails are removed. |
The following table describes these transitions (the account in the Identity Store is DISABLED):
| No | Previous State / TSState |
Connected system account | Resulting State / TSState |
Comments |
|---|---|---|---|---|
1 |
DISABLED |
does not exist |
DISABLED |
The account has not yet been created in the connected system. The Identity Store and the connected system are synchronized. |
2 |
DISABLED |
is enabled |
DISABLED |
The account did not exist in the connected system: a connected system administrator created the account and then enabled it. The initial load / validation workflows detect the situation, set the TSState to ENABLED and the ToDo field of the account to "Created in target system". |
3 |
DISABLED |
is disabled |
DISABLED |
The account exists or has been created by the synchronization workflow in the connected system and is disabled. The TSState in DirX Identity is set accordingly. |
4 |
DISABLED |
is enabled |
DISABLED |
The account exists in the connected system and is ENABLED. The initial load / validation workflow verifies the situation. |
5 |
DISABLED |
is enabled |
DISABLED |
The account is enabled in the connected system. The synchronization workflow disables the account and sets the TSState accordingly. The Identity Store and the connected system are synchronized again. |
6 |
DISABLED |
does not exist |
DISABLED |
A connected system administrator has deleted the account in the connected system. The initial load / validation workflows detect the situation, set the ToDo field to "Deleted in target system" and set the TSState accordingly. |
7 |
DISABLED |
is enabled |
DISABLED |
A connected system administrator has enabled the account and it exists in the connected system. The initial load / validation workflows detect the situation and set the TSState accordingly. |
8 |
DISABLED |
is disabled |
DISABLED |
The Identity Store and the connected system are synchronized. |
9 |
DISABLED |
does not exist |
DISABLED |
A connected system administrator has deleted the account in the connected system. The initial load / validation workflows detected the situation, set the ToDo field to "Deleted in target system" and set the TSState accordingly. |
10 |
DISABLED |
is enabled |
DISABLED |
The account was deleted in the connected system and then re-created afterwards by a connected system administrator in the state ENABLED. The initial load / validation workflows detected the situation, set the ToDo field of the account to "Recreated in target system" and set the TSState accordingly. |
11 |
DISABLED |
is disabled |
DISABLED |
The account was deleted in the connected system and then re-created afterwards by a connected system administrator in the state DISABLED. The initial load / validation workflows detected the situation, set the ToDo field of the account to "Recreated in target system" and set the TSState accordingly. |
12 |
DISABLED |
does not exist |
DISABLED |
The Identity Store and the connected system are synchronized. |
The following table describes these transitions (the account in the Identity Store is DELETED):
| No | Previous State / TSState |
Connected system account | Resulting State / TSState |
Comments |
|---|---|---|---|---|
1 |
DELETED |
is enabled |
DELETED |
The account was deleted in DirX Identity and does not exist in the connected system: an administrator in the connected system created it and set it to ENABLED. The initial load / validation workflows detect this situation, set the TSState accordingly and the ToDo field to "Recreated in target system". |
2 |
DELETED |
is disabled |
DELETED |
The account was deleted in DirX Identity and did not exist in the connected system: an administrator in the connected system created it and set it to DISABLED. The initial load / validation workflows detected this situation, set the TSState accordingly and the ToDo field to "Recreated in target system". |
3 |
DELETED |
does not exist |
(does not exist) |
The account has been deleted in the connected system before or has never been created in the connected system. The workflows do not delete the account in the Identity Store. |
4 |
DELETED ENABLED |
is enabled |
DELETED |
The account is in state DELETED but still exists and is enabled in the connected system. The initial load / validation workflows detect this situation but do not change it. |
5 |
DELETED ENABLED |
is disabled |
DELETED |
The account is in state DELETED but still exists and was disabled by an administrator in the connected system. The initial load / validation workflows detect this situation and set the TSState accordingly. |
6 |
DELETED ENABLED |
does not exist |
DELETED |
The account is in state DELETED and existed in the connected system. The synchronization workflow deletes it and sets the TSState accordingly. It does not delete the account in the Identity Store. |
7 |
DELETED |
is enabled |
DELETED |
The account is in state DELETED but still exists and was enabled by an administrator in the connected system. The initial load / validation workflows detect this situation and set the TSState accordingly. |
8 |
DELETED DISABLED |
is disabled |
DELETED |
The account is in state DELETED but still exists and is disabled in the connected system. The initial load / validation workflows detect this situation but do not change it. |
9 |
DELETED DISABLED |
does not exist |
DELETED |
The account is in state DELETED and existed in the connected system but was disabled. The synchronization workflow deletes it and sets the TSState accordingly. It does not delete the account in the Identity Store. |
10 |
DELETED DELETED |
is enabled |
DELETED |
The account was deleted under control of DirX Identity and was then re-created by an administrator in the connected system and set to ENABLED. In this case, the ToDo field of the account is set to "Recreated in target system" and the TSState is set accordingly. |
11 |
DELETED DELETED |
is disabled |
DELETED |
The account was deleted under control of DirX Identity and was then re-created by an administrator in the connected system and set to DISABLED. In this case, the ToDo field of the account is set to "Recreated in target system" and the TSState is set accordingly. |
12 |
DELETED DELETED |
does not exist |
(does not exist) |
The Identity Store and the connected system are synchronized. The initial load / validation workflows detect this situation and do not change it. |
Role States
A role can have these states:
-
<empty> - the role is enabled and grants the related access rights.
-
Deleted - the role will be deleted. The state is used to store the role’s delete history in the role object. Once the History Agent removes its history, the role can be deleted manually or by a consistency rule.
-
Tbdel - the role is marked to be deleted with the next run of the Service Agent in Resolution or CheckConsistency mode. The state is used to delete the role in the Service Agent if deleting the object online is too time-consuming.
Permission States
A permission can have these states:
<empty> - the permission is enabled and grants the related access rights.
Deleted - the permission will be deleted. The state is used to store the permission’s delete history in the permission object. Once the History Agent removes its history is removed, the permission can be deleted manually or by a consistency rule.
Tbdel - the permission is marked to be deleted with the next run of the Service Agent in Resolution or CheckConsistency mode. The state is used to delete the permission in the Service Agent if deleting the object online is too time-consuming.
Group States
Groups represent access rights in connected systems. A group can have these states:
Enabled - the group shall exist and be created in the connected system.
Deleted - the group shall be deleted in the connected system.
Tbdel - the group is marked to be deleted with the next run of the Service Agent in Resolution or CheckConsistency mode. As a result, the group’s state will change to Deleted.
The following group attributes are related to these states (the LDAP attribute is shown in parentheses):
EndDate (dxrEndDate) - the date when the group will be deleted.
State in connected system (dxrTSState) - The state of the group in the connected system. Possible states are:
ENABLED - the group exists in the connected system.
DELETED - the object has been deleted in the connected system without DirX Identity Provisioning having requested it! This state is only set by the validation workflow together with a message in the ToDo (dxrToDo) attribute that reminds the administrator to examine this situation.
NONE - set when the object is created by the DirX Identity services.
Group State Transitions
The following figure illustrates the group states and how they function in conjunction with the group attributes just described:
As shown in the figure, the possible transitions are as follows:
(does not exist) → ENABLED - the initial load or validation workflows create new groups in the target system in the state ENABLED, set TSState depending on the state in the connected system and set the TsLocal Attribute is to true. Alternatively, an administrator can create a group by hand. In this case, the TSState is set to NONE and the TsLocal flag is reset.
ENABLED → DELETED - administrators can delete groups with TSState unequal to DELETED. The resulting state is DELETED, and the EndDate is set accordingly.
ENABLED → (does not exist) - if an administrator deletes a group with TSState DELETED and there is no audit trail information available at this group entry, the group is physically removed from the Identity Store.
DELETED → (does not exist) - if the EndDate has passed, TSState is DELETED and there is no audit trail information available at this group entry, the group is physically removed from the Identity Store.
Provisioning Workflow State Handling
The provisioning workflows control the TSState attribute of groups according to the description given in the section "Account States".
The following figures and tables show all state combinations (State, TSState) and the possible transitions:
-
In the figures, dashed lines indicate transitions that should not occur under normal circumstances but which can occur due to (illegal) administrator actions or other malfunctions. DirX Identity uses the dashed-line transition to solve the problem.
-
In the tables, bold states in the Resulting state / TSState column indicate that the state is changed.
-
The meaning of the columns is as follows:
-
Previous State / TSState - the State/TSState in the Identity Store before the workflow is run.
-
Connected system group - the state of the group in the connected system before the initial load / validation workflow is started or the TargetSystem → IdentityStore part of the synchronization workflow runs.
-
Resulting State / TSState - the State/TSState in the Identity Store after the workflow completes.
Here is an example of how to read this diagram: the synchronization workflow reads all groups that are in state ENABLED and TSState NONE and creates the corresponding group in the connected system. After successful creation, the TSState in the Identity Store is set to ENABLED. This is shown in the figure with the path ENABLED / NONE → group does not exist → ENABLED / ENABLED.
The following table describes these transitions (the group in the Identity Store is ENABLED or does not exist):
| No | Previous State / TSState |
Connected system group | Resulting State / TSState |
Comments |
|---|---|---|---|---|
1 |
(does not exist) |
exists |
ENABLED ENABLED |
Groups that exist in the connected system but not yet in the Identity Store are created by an initial load / validation workflow. The state and TSState are set to ENABLED, the TSlocal flag is set to TRUE and the ToDo field is set to "Created in target system". |
2 |
ENABLED NONE |
does not exist |
ENABLED NONE |
The group has not yet been created in the connected system. |
3 |
ENABLED NONE |
exists |
ENABLED ENABLED |
The group exists or has been created by the synchronization workflow in the connected system and is enabled. The TSState in DirX Identity is set accordingly. |
4 |
ENABLED ENABLED |
exists |
ENABLED ENABLED |
The Identity Store and the connected system are synchronized. |
5 |
ENABLED ENABLED |
does not exist |
ENABLED DELETED |
A connected system administrator has deleted the group in the connected system. The initial load / validation workflows detect the situation, set the ToDo field to "Deleted in target system" and set the TSState accordingly. |
6 |
ENABLED |
exists |
ENABLED |
The group was deleted in the connected system and then re-created by the connected system administrator. The workflows set the TSState accordingly. |
7 |
ENABLED |
does not exist |
ENABLED DELETED |
The group is deleted in the connected system. The initial load / validation target system workflows verify this situation but do not change anything. |
The following table describes these transitions (the group in the Identity Store is DELETED):
| No | Previous State / TSState |
Connected system group | Resulting State / TSState |
Comments |
|---|---|---|---|---|
1 |
DELETED |
exists |
DELETED |
The group was deleted in DirX Identity and did not exist in the connected system. It was created by an administrator in the connected system. The initial load / validation workflows detect this situation, set the TSState accordingly and the ToDo field to "Created in target system"'. |
2 |
DELETED |
does not exist |
DELETED |
The group has never been created in the connected system. The initial load / validation workflows detect this situation but do not change anything. They do not delete the group in the Identity Store. Instead, a consistency rule will delete it after all audit trail information is removed. |
3 |
DELETED ENABLED |
exists |
DELETED |
The group is in state DELETED but still exists in the connected system. The initial load / validation workflows detect this situation but do not change it. |
4 |
DELETED ENABLED |
does not exist |
DELETED |
The synchronization workflow deletes the group from the connected system. It sets the TSState accordingly. |
5 |
DELETED DELETED |
exists |
DELETED |
The group was deleted in the connected system. A connected system administrator created it in the connected system. The initial load / validation workflows detect this situation, set the TSState accordingly and the ToDo field to "Created in target system". |
6 |
DELETED DELETED |
does not exist |
DELETED |
The Identity Store and the connected system are synchronized. The initial load / validation workflows detect this situation and do not change it. |
7 |
DELETED DELETED |
does not exist |
(does not exist) |
The corresponding consistency rule will delete the group after all audit trail information is removed. |
Assignment States
The account-group membership is controlled by the DirX Identity resolution services and by the provisioning workflows. An assignment can have the following states:
ADD - the membership is created in DirX Identity, but does not yet exist in the connected system.
IMPORTED - the membership exists in the connected system, but is not requested by DirX Identity.
ENABLED – the membership is established both in DirX Identity and the connected system.
DELETED – DirX Identity requested to delete an existing membership. It still exists in the connected system.
IGNORE – a DirX Identity administrator explicitly accepted an imported membership. It is still not yet required by DirX Identity.
The graphical user interfaces may display an additional (virtual) state for groups: INACTIVE. Reasons for this state are as follows:
-
The end date of this assignment has passed.
-
The privilege is already assigned (for example, by the policy execution service), but a privilege resolution has not yet run. Run the privilege resolution to solve this problem.
The reason for this state is that the dxrGroupLink at the user is already populated, but the member attributes at the group or account are not yet populated.
Assignment State Transitions
The following figure illustrates the assignment state transitions:
Provisioning Workflow State Handling
The provisioning workflows, in cooperation with the resolution services, control the membership between accounts and groups and change the value to the real situation in the connected system:
-
The initial load workflow reads all memberships from the connected system and imports them into the Identity Store. The state is as shown in the figure and table below.
-
The validation workflow reads all memberships from the connected system and imports the changes to the Identity Store. Note that the initial load and the validation workflows are almost identical. The only difference is that the validation workflow writes a ToDo message in cases where the administrator needs to be notified.
-
The synchronization workflow first reads all memberships in state ADD and DELETE from the Identity Store and updates the connected system memberships accordingly. It then updates the Identity Store accordingly: it moves the ADD memberships to ENABLED and deletes the DELETE memberships).
The next figure shows the possible states of memberships and the possible transitions that can occur during the import operation at the Identity Store.
Here is an example of how to read this diagram: the synchronization workflow reads all memberships that are in state ADD and adds these memberships in the connected system. After a successful add operation (the assignment now exists), the state is set to ENABLED. This is shown in the figure with the path ADD → Assignment exists → ENABLED.
The following table describes these transitions (the account in the Identity Store is ENABLED):
| No | Previous State |
Connected system membership | Resulting State |
Comments |
|---|---|---|---|---|
1 |
ADD |
does not exist |
ADD |
The membership does not yet exist. |
2 |
ADD |
exists |
ENABLED |
The membership existed or was created by the synchronization workflow. The state is set accordingly. Identity Store and connected system are synchronized. |
3 |
ENABLED |
exists |
ENABLED |
The membership exists and is controlled by the Identity Store. |
4 |
ENABLED |
does not exist |
(does not exist) |
A connected system administrator deleted the membership. The synchronization workflow deletes the membership. |
5 |
DELETED |
exists |
DELETED |
DirX Identity requested to delete the membership. |
6 |
DELETED |
does not exist |
(does not exist) |
The membership is deleted from the Identity Store. |
7 |
(does not exist) |
exists |
IMPORTED |
The membership does not exist in the Identity Store but it exists in the connected system. It is created with state IMPORTED within the Identity Store. |
8 |
IMPORTED |
exists |
IMPORTED |
The membership exists but is not controlled by the Identity Store. |
9 |
IMPORTED |
does not exist |
(does not exist) |
The membership is deleted from the Identity Store. |
10 |
IGNORE |
does not exist |
(does not exist) |
The membership is deleted from the Identity Store. |
In the previous table:
-
Bold states in the Resulting state / TSState column indicate that the state is changed.
-
The meaning of the columns is as follows:
-
Previous State / TSState - the State/TSState in the Identity Store before the workflow is run.
-
Connected system membership - the state of the membership in the connected system before the initial load / validation workflow is started or the TargetSystem -> IdentityStore part of the synchronization workflow runs.
-
Resulting State / TSState - the State/TSState in the Identity Store after the workflow completes.
How Privilege Resolution Works
You can assign privileges either by hand or via provisioning rules. You can also set a start date and an end date for a manual assignment to restrict its duration. After new privileges are assigned, (and if an optional approval is granted) DirX Identity performs a privilege resolution. The privilege resolution process collects the assignments from associated user facets and then calculates the actual memberships and the necessary accounts for the user depending on these assignments and their attributes.
Calculating Account-To-Group Memberships
Account-to-group memberships can result from several sources, for example, a time-restricted user-to-group assignment or a role or permission assignment. The privilege resolution process calculates the duration period for each assignment. It can be defined for the future (period is FUTURE), it can be active (period is ENABLED) or it may have already passed (period is PASSED).
The privilege resolution process calculates the resulting period as a sum of all periods, where the priority is ENABLED → FUTURE → PASSED. It calculates the resolution result for the current time and sets the memberships accordingly (see below):
-
The resolution result is ENABLED if one or more of the assignments are in the ENABLED state.
-
The resolution result is in the FUTURE state if none of the assignments is in the ENABLED state but one or more assignments is in the FUTURE state.
-
Otherwise, the resolution result is in the DELETED state.
Note that these intermediate duration periods are not visible at the user interface. Only the resolution result is visible as the state of the account-to-group membership.
Calculating Account States
The sum of the account-to-group memberships and the user’s state define the state of the account. DirX Identity supports "in advance" provisioning; that is, privileges can be assigned for a future period or the user can still be in the NEW state. With "in advance" provisioning, DirX Identity provisions the connected systems with all the necessary accounts (but these accounts remain in the DISABLED state) and all the necessary account-to-group memberships to enable the connected system administrators to perform advanced additional provisioning tasks if necessary.
The calculation procedure runs as follows:
-
If a user is in the NEW state, all accounts are set to the DISABLED state and all account-to-group memberships are set to state ADD.
-
If a user is in the ENABLED state and has only "in advance" account-to-group memberships (period is FUTURE), the account is set to the DISABLED state. The account-to-group assignments are set to the ADD state.
-
If a user is in the ENABLED state and has mixed account-to-group assignments (some are in period FUTURE and some in period ENABLED), the account is set to the ENABLED state and only memberships with period ENABLED are generated in state ADD. All memberships with period FUTURE are not generated in state ADD.
-
If a user is in the ENABLED state, has only "in advance" account-to-group memberships (period is FUTURE) and one or more of these memberships enters the period ENABLED, the account is set to the ENABLED state. All account-to-group memberships in period FUTURE are set to the DELETED state and only the memberships in period ENABLED are set to state ADD.
User and Account Lifecycles
The lifecycle of users and accounts is closely related. This section explains a typical user lifecycle and the associated account lifecycle. The following figure shows a typical user lifecycle:
As shown in the figure:
-
After creation of the user, the Start Date is not yet reached. The user is in state NEW. In this phase privileges can be assigned that are not yet active in the connected systems.
-
Reaching the Start Date, the DirX Identity services change the status automatically to ENABLED. Now all accounts and group memberships are enabled if the corresponding privileges are active.
-
For some period defined by a Disable Start Date and a Disable End Date, the user is in state DISABLED. This means that the corresponding privileges and accounts are not active in the connected systems.
-
Reaching the Disable End Date, the DirX Identity services change the status automatically to ENABLED again. Now all accounts and group memberships are enabled again if the corresponding privileges are active.
-
If the End Date is reached (the user leaves the company), the DirX Identity services change the status automatically to TBDEL (to be deleted). A complex procedure that can last months or years is performed that is explained in the next section in more detail. This time is defined by the End Date + Maximum time to delete (defined at the domain object).
The account lifecycle and the user lifecycle are closely related, as shown in the following figure:
Until the user reaches the TBDEL status, the user is in status ENABLED. All associated accounts are in status ENABLED in the target systems of the Identity Store. The TS status in the target systems is also in ENABLED status. All related accounts in the connected system are also in ENABLED status.
The following steps are:
-
If the End Date is reached for the user entry (the user leaves the company), the DirX Identity services change the user status automatically to TBDEL (to be deleted). The Delete Date (User) is set to End Date (User) + Maximum time to delete (Domain). Note that the Maximum time to delete is taken from the domain object.
This results in immediate disabling of all accounts (state of accounts goes to DISABLED). The TS state is still in ENABLED state. The End Date of all accounts is set to End Date (User) + Maximum time to disable (TS or Domain). Note that the Maximum time to disable is taken from the target system and if not available from the domain object. -
Provisioning (synchronization) workflows are run that perform the disabling in the target system (state of the accounts goes to DISABLED).If this operation is successful, the TS state is in the target system is set to DISABLED to reflect the state in the connected system.If these workflows are run scheduled, this can last some time.If the workflows are run event-based, the change happens almost immediately.
Now the user is in state TBDEL and all account states are set to DISABLED, which means that the user is no longer active but not yet really deleted.This feature allows the user to be reactivated until the first account End Date is reached.The reason for this feature is that deleting the accounts instead of disabling them would mean that a reactivation of the user would require creation of the deleted accounts.In many systems, accounts have unique identifiers and security identifiers that are established by the connected system (for example, Active Directory).Creating an account again means that these identifiers are different.The user no longer has access to the resources he had before.So it is very important to keep the accounts in disabled state instead of deleting them. -
If the End Date of an account is reached, the DirX Identity services set the state to DELETED.In the target system the TS state is still in state DISABLED.
-
Next, a provisioning (synchronization) is run that deletes the account in the connected system physically.If successful, the TS state in the target system is set to DELETED.
The user is still in state TBDEL and after the defined time (Maximum time to disable for accounts) all account states are set to DELETED. -
Cleanup workflows (policy execution service with consistency rules) are run from time to time that try to delete accounts that are in state DELETED.If auditing is enabled, the deletion is only performed if all history information is removed from the entries.
-
Cleanup workflows (policy execution service with consistency rules) are run from time to time that try to delete users that are in state DELETED.If auditing is enabled, the deletion is only performed if all history information is removed from the entries.
Note: the user deletion is performed even if not all accounts are deleted.
Managing Attribute Flow
One of the most important aspects of identity management is synchronization of attributes to provide a consistent view of identities all over the identity domain.The next figure shows how attribute flow is achieved through the identity system.
In this example, identity data for a user comes from a source system (for example, an HR system).As illustrated in the figure, the attribute flow steps are as follows:
-
The Creation Workflow extracts the identity and its attributes from the Source System and transfers it to the Identity Store, where it creates the user entry.If attributes change, the Creation Workflow performs an update of these attributes.The Source System masters these attributes.For information on how to configure creation workflows, see the section "Configuring the Source Workflows" in the DirX Identity Application Development Guide.
-
If privileges are assigned to this user, accounts are created in target systems. In this example, Account A is created. You can use Naming Rules to transfer attributes from the user entry to the account. Naming rules are definitions within the attribute definition in the account object description. See the section "Properties and Property Elements" in the DirX Identity Customization Guide for more information.
-
Provisioning Workflows synchronize the account attributes to the corresponding account objects in the target systems. For information on how to configure Provisioning Workflows, see the section "Configuring the Target System Workflows" in the DirX Identity Application Guide for Java-based real-time provisioning and the section "Configuring the Provisioning Workflows" in the DirX Identity Application Development Guide for Tcl-based provisioning workflows.
-
In this example, attributes that are created in target systems need to be distributed to other parts of the identity domain. A good example is an email address or a telephone number. The target system masters these attributes.
-
Validation Workflows or Provisioning Workflows transfer these attributes to the representation of the account in the Identity Store. Validation Workflows update all accounts, whereas Provisioning Workflows only transfer information about specific entries that are handled during this synchronization. See the section "Configuring the Provisioning Workflows" in the DirX Identity Application Development Guide for more information.
-
Use Consistency Rules to copy the changed attributes from the account entries to the user entries in the Identity Store. For information on how to configure these rules, see the section "Managing Automatic Provisioning". Note that the event-based workflows for example the EventBasedAccountProcessing workflow provide alternative means to handle such tasks.
-
As in Step 2, you can use Naming Rules to transfer these attributes to the accounts in other target systems.
-
Provisioning Workflows synchronize the account attributes to the corresponding account objects in these target systems.
-
Update Workflows can synchronize this information back to Source Systems.
This example describes attribute mastering from source and target systems. Attributes can also be mastered directly from user entries in the Identity Store. In this case, you use the Web Center or the DirX Identity Manager to maintain these attributes. The update processes are analogous to the steps described here.