12.1 Configuring Application Definitions
Key Takeaways
A connector is the template for talking to a kind of system; an application is a configured instance with its own name, connection parameters, and schema.
Marking an application Authoritative makes aggregation create an identity for each account; non-authoritative accounts are correlated to existing identities.
The application owner reviews access in owner certifications and approves entitlement requests by default; the Revoker, if set, receives revocation work instead.
Maintenance Enabled skips the application in aggregations and returns retry status for provisioning until the window ends.
Application names cannot start with a number or exceed 31 characters, and XML edits should be made on an exported copy, not in the Debug pages.
Configuring Application Definitions
Objective 5.1 asks you to configure application definitions. Every system IdentityIQ governs, such as HR, Active Directory, a database, or a SaaS application, is represented by an Application object, configured on Applications > Application Definition.
Connectors vs. Applications
- A connector is a template for talking to a type of system. It knows how to connect, read, in many cases write, and turn source data into normalized ResourceObjects.
- An application is a configured instance of a connector. It has a unique name, connection parameters for one specific system, and a specific schema.
You can create many applications from one connector. For example, ten Delimited File applications can each read a different file with a different schema. Applications can be read-only or read-write, depending on whether the connector supports provisioning. IdentityIQ also has activity-type connectors that collect activity data instead of accounts.
The Details Fields
| Field | What it controls |
|---|---|
| Name | Unique name. It cannot start with a number or exceed 31 characters. |
| Application Type | The connector. This decides which configuration options appear. Some connectors may not be enabled in your instance. |
| Owner | The business owner, an identity or preferably a workgroup. It reviews access in application owner and account group certifications and, by default, approves entitlement requests for the application. |
| Revoker | Receives revocation requests from certifications and policy violations. If blank, the owner gets them. |
| Description | Can be multi-language when enabled (section 11.3) |
| Proxy Application | Another application that aggregates and provisions on this one's behalf, for example multiplexed applications split by a build map rule, legacy provisioning systems, or a Cloud Gateway for a remote network |
| Profile Class | Groups applications for role modeling, so one role profile can match privileges on any application with that class |
| Scope | Only visible when scoping is enabled. Only the owner or users controlling the scope can work with the application. |
| Authoritative Application | Aggregation creates an identity for every account |
| Case Insensitive | Case-insensitive comparison of account attribute values when evaluating provisioning policy |
| Native Change Detection | Detects changes made directly on the target, by chosen operations and attributes (entitlements or user-defined). Feeds Native Change lifecycle events. |
| Maintenance Enabled / Expiration | Takes the application offline. Aggregations skip it with a warning, and provisioning returns retry. With no expiration, maintenance lasts until someone clears it. |
Authoritative vs. Non-Authoritative
An authoritative source, typically HR, is the most trusted record of who people are. Aggregating it creates identity cubes and supplies attributes such as name, department, manager, and status. A non-authoritative source, such as Active Directory or an ERP, has accounts that must be correlated to existing identities. An organization can have several authoritative sources, for example employees from HR and contractors from a vendor system. When a non-authoritative account matches no identity, it becomes an uncorrelated account. You can fix correlation logic or manually correlate it on the Identity Correlation page. Manual correlations are kept permanently and are not changed by later aggregations.
The Edit Application Tabs
| Tab | Purpose |
|---|---|
| Configuration | Settings (connection, partitioning, merging, delta), Schema, Provisioning Policies, and object types (section 12.2) |
| Correlation | Attribute-based and condition-based account correlation, plus manager correlation |
| Accounts | The aggregated accounts, after the application is saved |
| Risk | Application risk score components |
| Activity Data Sources | Collectors that read activity logs |
| Unstructured Targets | Permission targets such as file shares |
| Rules | Aggregation, provisioning, schema, and connector rules (sections 13.2 and 13.3) |
| Password Policy | Password rules for this application, such as length, character types, history, dictionary, and identity-attribute checks |
| Tiers | Logical applications only |
The documentation warns: do not edit the same application in multiple browser tabs. Saving in one can overwrite changes made in the other.
Correlation Configuration in Brief
- Attribute-based – for example, the account attribute
mailequals the identity attributeemail. This is the usual approach. - Condition-based – for accounts without identifying attributes, such as a Unix
rootaccount assigned to the application owner. These configurations can be saved and shared across applications. - Rules – a Correlation rule for complex logic (section 9.2).
- Manager correlation – pairs an application attribute, such as
managerEmail, with an identity attribute, such asemail, to set each identity's manager.
Onboarding Checklist for a New Application
- Pick the connector type and create the application with a clear name, an owner workgroup, and a revoker if different.
- Fill in the connection settings and run Test Connection.
- Define or discover the account schema (and group schema), and set the identity, display, entitlement, and managed attributes (section 12.2).
- Configure correlation, for accounts and managers.
- Add provisioning policies if the application is read-write.
- Create an Account Aggregation task (and Account Group Aggregation), run it in a sandbox, and review uncorrelated accounts.
- Add rules only where configuration cannot do the job (sections 13.2 and 13.3).
- Optionally, hand business onboarding to Rapid Setup (section 12.3).
Changing an Application Safely
- Reconfigure changes an application's type without losing history. For example, a Delimited File application for AD can become Active Directory – Direct, or a JDBC application can become a direct connector. It works best when account and group identity attributes have the same format in both types.
- XML edits. Some connector options exist only in the application XML. The documentation advises checking out the single application (
checkout application "<name>" file.xml), editing it outside IdentityIQ, testing it, and importing it. Avoid direct Debug-page edits, which have no rollback.
A company aggregates contractors from a vendor-management system and wants each contractor account to create an identity cube, just as HR accounts do for employees. What should be configured?
Mark the vendor-management application as Authoritative, since IdentityIQ supports several authoritative sources.
Set the vendor application's Proxy Application to the HR application.
Enable Native Change Detection on the vendor application.
Give the vendor application a Profile Class of HR.
An application is placed in maintenance with no expiration date. What happens to a certification revocation targeting that application?
It is permanently cancelled.
It is sent to the connector anyway.
It is converted into a policy violation.
Provisioning returns a retry status, and a retry Request is created until the application leaves maintenance.
Who receives certification revocation requests for an application if the Revoker field is left blank?
The IdentityIQ System Administrator
The application owner
The certification owner
The identity whose access is revoked
An engineer needs to change a connector option that exists only in an application's XML. Which approach does the documentation recommend?
Edit the XML directly in the Debug pages in production.
Export all Application objects with export and edit the whole file.
Create a new application and delete the old one.
Check out the single application with the console, edit and test it outside IdentityIQ, then import it.
Sections you finish are checked off in the contents.