Adapter Overview
Overview
Adapters are the components of UNIFYBroker that present the data from the connected sources to the Identity Management engines. They are known as adapters as they adapt (or transform) the classes of identities that come from a connected source into a form required by the Identity Management Engine. This is necessary because the data in connected sources usually has an impedance mismatch with the kind of data required in the Identity Management engines. As an example, a HR application may store data in multiple tables or locations, whereas a target LDAP directory may require the data in a flattened format.
Configuration
Adapters initially require the following by way of configuration:
Name | Description |
---|---|
Adapter Name | This is the display name of the adapter. It is used to describe the adapter throughout UNIFYBroker. |
Container Name | The LDAP name that the data for the adapter will be contained in (underneath DC=IdentityBroker ).
|
Object Class | This is the object class that will be denote each entity in an adapter. |
Base Connector | The base connector for this adapter. |
Base Connector
Each adapter has a Base Connector that they are related to. By default, an adapter will have the same schema as its base connector. A more complex adapter may involve joining identities from multiple connectors, or performing additional processing to extend or alter the schema to prepare entities for the target Identity Management engine. This process is described in Adapter Transformations.
The decision for which connector should be the base can be determined by which information is read-only; the Add, Update or Delete Entities operations of an adapter will only update the base connector. All relational data is considered read-only.
Distinguished Name Generator
Each adapter entity has a distinguished name (DN) attributed to it. The format of an entities distinguished name is
[RDN],OU=[Container Name],DC=IdentityBroker
The value of the RDN is defined by the Distinguished Name Generator of the adapter, which is configured during adapter creation. It can also be edited by clicking Edit adapter DN template from the Adapter Menu. See Distinguished Name Templates for more information on using the Distinguished Name Generator.
Schema
The entity schema of an adapter describes the structure of data to be made available to foreign identity management services. This schema is calculated by taking the schema of the base connector and updating it with the transformations of the adapter.
In order to more easily comply with field name restrictions within classes in Identity Management engines, UNIFYBroker has restrictions on the names of attributes in adapters.
Attribute names are restricted to those that comply with RFC 2849, which specifies the LDIF standard. If UNIFYBroker detects fields exist in the final adapter schema, it will provide a quick link for the addition of a Rename transformation that corrects any names that do not meet the standard.
If running in single-schema-mode (not the default), attribute names must also be unique across all enabled adapters. If an adapter has a attribute will the same name as another, enabled adapter, it will not be permitted to start until the offending attribute has been renamed. The warning message provides a quick link for the creation of a Rename transformation which appends the adapter name to the start of the non-uniquely named attributes.
Transformations
The structure of entity data required by identity management engines may not reflect the available structure of data in the source identity stores.
To put this in terms of UNIFYBroker - foreign identity management engines might not be able to directly work with the entity schema of a connector.
Adapters can update this schema through a series of transformations to close this gap; transformations are used to calculate the entity schema of an adapter. Each transformation can make zero-to-many changes against the base connector schema of the adapter. These can include such changes as:
- Adding a field from another connector and making it available for reading in the adapter. (e.g. Join, Group)
- Renaming or copying an existing field of the base connector
- Merging a series of multi-valued fields into one larger multi-valued field
- For more information on the available contributions to the adapter schema, refer to the currently available transformations.
Additionally, transformations can define special ways of calculating changes for an adapter.
Change Reflection
After an adapters associated connector performs a Full Import or a Polling Import, any changes to source data will begin being reflected into the adapter space. Reflection can be triggered for all entities on an adapter's connector with the Generate Changes option from the Adapter Menu while the adapter is running.
Operations
Each adapter keeps an internal state maintaining the last values it has worked with, commonly referred to as an adapter's entities, stored in the adapter entity repository. The entities of a connector are visible from that adapter's entity search.
Import
An import all operation from a foreign identity management service will request all entities which satisfy a search query.
Import Changes
An import changes operation from a foreign identity management service will request all changes made since a certain point in the past.
Delete Entities
This operation will execute a delete entities operation against the base connector. This will not remove entities from the adapter space until change reflection takes place.
Clear Entities
This operation is called when a base connector is cleared. When the adapter is enabled, this operation can be run manually by clicking the Clear Entities Clear button or the Clear Precalculated Entities option from the Adapter Menu while the adapter is running.
Add Entities
This operation will execute an add entities operation against the base connector. This will not add entities to the adapter space until change reflection takes place.
Update Entities
This operation will execute an update entities operation against the base connector. This will not modify entities to the adapter space until change reflection takes place.
Adapter Enablement
Like connectors, adapters can be enabled or disabled in order to make configuration changes and for other outage periods. When an adapter is disabled, external systems will not be aware of its existence and will most likely fail if an operation is run against it. Disabling an adapter prevents change reflection from taking place.
Adapters are somewhat different to connectors in that external forces are able to cause the adapter to disable itself, for safety and consistency reasons. The following scenarios will cause the adapter to become disabled:
- Disabling the base connector
- Disabling any of the relational connectors
Using an adapter
An adapter makes UNIFYBroker data available to foreign identity management services and other software which can interact with any configured gateways. See Gateways for details on configuring gateways.
Entities in adapters are uniquely identified within UNIFYBroker and to external systems using a Distinguished Name (DN). For more information, refer to Distinguished Name Templates.
Adapter Groups
Series of adapters can be grouped into individual adapter groups. Unlike connector groups, adapter groups are only used for display purposes.
Field name restrictions
In order to more easily comply with field name restrictions within classes in Identity Management engines, UNIFYBroker has restrictions on the names of attributes in adapters.
Attribute names are restricted to those that comply with RFC 2849, which specifies the LDIF standard. Therefore, attribute names must meet the following format:
AttributeType = ldap-oid / (ALPHA *(attr-type-chars)) attr-type-chars = ALPHA / DIGIT / "-" ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9
If UNIFYBroker detects that the adapter schema does not meet these requirements, it will prompt for the addition of a Rename transformation to make the field names LDIF compliant.
Customer support service by UserEcho