Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
devel:documentation:systems:dev:system-mapping [2019/05/06 10:29]
svandav [Connector pool configuration] 		devel:documentation:systems:dev:system-mapping [2021/03/26 10:32] (current)
svandav [Send additional attributes with password]
Line 1: Line 1:
 ====== Connector configuration and attribute mapping ====== ====== Connector configuration and attribute mapping ======
-{{tag>connector mapping system configuration }}+{{tag>connector mapping system configuration merge authoritative skip excluded }}
  
 ===== Connector configuration ===== ===== Connector configuration =====
 +{{tag>connector configuration}}
 Creation of a newly connected system will be demonstrated on a database connector (ConnIdDBBundle). Creation of a newly connected system will be demonstrated on a database connector (ConnIdDBBundle).
 Firstly, we will create a new system named **Table** and choose the database connector. Firstly, we will create a new system named **Table** and choose the database connector.
Line 12: Line 13:
  
 ==== Connector pool configuration ==== ==== Connector pool configuration ====
 +{{tag>connector pool}}
  
 **The connector pool** is a very useful feature that avoids unnecessarily creating a new connector instance each time a connector is called. Typically, each connector instance also creates a connection to that target system. It is effective to maintain these connections for **longer periods and for multiple calls**. **The connector pool** is a very useful feature that avoids unnecessarily creating a new connector instance each time a connector is called. Typically, each connector instance also creates a connection to that target system. It is effective to maintain these connections for **longer periods and for multiple calls**.
Line 35: Line 37:
  
    
 +==== Additional connector configuration ====
 +{{tag>operation options}}
 +
 +The additional connector configuration tab lets you configure so called operation options for each type of connector. These options are then passed to each invocation of given connector. This enables us to further tweak connection paramters for each system, such as list of attributes, which should be returned from target system.
 +
 +Each system has its own set of operation options. By default, only PAGE_SIZE and ATTRS_TO_GET is available for each connector, but you can easily add other options using corresponding form definition.
 +
 +=== Example operation options: ===
 +
 +  * **PAGE\_SIZE** - Number of records returned in paged search operation. This option is used for example in LDAP/AD connector
 +  * **ATTRS\_TO\_GET** - List of attributes, which should be returned from system
 +
 +<note tip>Operation options are persisted in EAV attributes and use form definition with code "operation-options-connector-configuration-CONNECTOR_FULL_NAME_AND_VERSION".</note>
 +
 +{{ :devel:documentation:systems:dev:operation_options.png |}}
  
 ===== System scheme ===== ===== System scheme =====
 +{{tag>system scheme}}
 When the connector is configured correctly, we can move on to the **System scheme** tab. There, we will create the scheme either manually or we will use the scheme which will be returned by the connector itself (according to the filled-in configuration). When the connector is configured correctly, we can move on to the **System scheme** tab. There, we will create the scheme either manually or we will use the scheme which will be returned by the connector itself (according to the filled-in configuration).
  
Line 52: Line 70:
  
 ===== Attribute mapping ===== ===== Attribute mapping =====
 +{{tag>attribute mapping}}
  
 When the system scheme is created, we can move on to attribute mapping in the **Attribute mapping** tab. Mapping serves two basic purposes: When the system scheme is created, we can move on to attribute mapping in the **Attribute mapping** tab. Mapping serves two basic purposes:
Line 90: Line 109:
  
 <note tip>Configuration is effective for all target systems. All target system will be using one configured way (configuration per-system is not implemented, coming soon).</note> <note tip>Configuration is effective for all target systems. All target system will be using one configured way (configuration per-system is not implemented, coming soon).</note>
 +
 +=== Send attribute only on password change ===
 +Since version **11.0.0** a new flag **Send only on password change** was added to the attribute detail.
 +
 +If is this flag checked, then the attribute will be send to the system only during change of password operation. It means that this attribute will be ignored in standard provisioning operations (create/update).
 +<note important>This checkbox can be use only if attribute has checked flag **Send additional attributes with password**.</note> 
  
  
Line 121: Line 146:
  
 ====== Mapped attribute strategy ====== ====== Mapped attribute strategy ======
 +{{tag>attribute strategy}}
  
 The attribute strategy defines how will the attribute and primarily its value be dealt with during provisioning and synchronization. The attribute strategy defines how will the attribute and primarily its value be dealt with during provisioning and synchronization.
Line 152: Line 178:
  
 ==== AUTHORITATIVE_MERGE (Authoritative merge) ==== ==== AUTHORITATIVE_MERGE (Authoritative merge) ====
 +{{tag>authoritative merge}}
  
 This strategy (identically to MERGE) alters the logic of calculating attributes and their values. With the other strategies applies the following: if there are more occurrences of the same strategy for the same attribute (more overloaded attributes in more roles), the one with the highest priority is found (according to role priorities or their names). The resulting value going into provisioning is calculated on the basis of this one attribute only. This strategy (identically to MERGE) alters the logic of calculating attributes and their values. With the other strategies applies the following: if there are more occurrences of the same strategy for the same attribute (more overloaded attributes in more roles), the one with the highest priority is found (according to role priorities or their names). The resulting value going into provisioning is calculated on the basis of this one attribute only.
Line 166: Line 193:
  
 ==== MERGE (Merge) ==== ==== MERGE (Merge) ====
 +{{tag>merge controlled}}
  
 <note warning>Since version **9.3.0** was provisioning merge completely reimplemented!</note> <note warning>Since version **9.3.0** was provisioning merge completely reimplemented!</note>
Line 192: Line 220:
 That persisted 'cache' is evicted when definiton for that attribut is changed on the role (SysRoleSystemAttribute). That persisted 'cache' is evicted when definiton for that attribut is changed on the role (SysRoleSystemAttribute).
  
-The evicted cache is **recalculated** by using the **AttributeControlledValuesRecalculationTaskExecutor** task, which is run after each save of attribute mapping on a role. In this case, this task recalculates the cache for all evicted attributes of the provisioning mapping.+The evicted cache is **recalculated** by using the **AttributeControlledValuesRecalculationTaskExecutor** task. This task recalculates the cache for all evicted attributes of the provisioning mapping. 
 + 
 +<note important>Since version **9.7.5** is recalculation of evicted attribute **not starts on save a attribute** (SysRoleSystemAttribute)! Attribute on the system is **marked as evicted only**. Recalculation will be processed during first using of controlled values. This is typically on first **update provisioning**. **Beware** if new account is created and create provisioning is executed, then recalculation is not executed, because in this situation are controlled values not needed!</note> 
 + 
 +<note important>The merge attribute value must be a **constant**. For performance reasons, all system merge values are cached and this cache is recalculated only if the corresponding **role attribute changes**! **If the value is dynamic, the cache will not contain the correct data!**</note>
  
 {{ :devel:documentation:systems:dev:controlledvaluestask.png |}} {{ :devel:documentation:systems:dev:controlledvaluestask.png |}}
Line 216: Line 248:
  
 <note important>Final values merge from roles is set, **all duplicates will be removed**. For example: if you have two roles with merge mapping for same attribute and value for this attribute is same, to end system will be send only one.</note> <note important>Final values merge from roles is set, **all duplicates will be removed**. For example: if you have two roles with merge mapping for same attribute and value for this attribute is same, to end system will be send only one.</note>
 +
 +==== Skip merged value if contract is excluded ====
 +
 +{{tag>merge skip exclude contract}}
 +
 +Since version **9.7.0** was added new feature enabling skip of value defined in merge attribute, if contract (on witch is role assigned) will be excluded.
 +
 +For enable this feature you need to check the option **'Skip value when contract is excluded'**.
 +
 +**Value will be skipped only if**:
 +  - Attribute has strategy type sets to **MERGE** or **AUTHORITATIVE_MERGE** (only for this options will checkbox shows).
 +  - Feature is **enabled** on the role mapping.
 +  - Identity has assigned this role/s to the **excluded contract/s**. If identity has assigned more same roles on different contracts, then for skipping of the value must be **all** connected contracts excluded.
 +
 +<note important>**If all roles which defines the account will have skipped values, then account will not be deleted!**</note>
 +
 +{{ :devel:documentation:systems:dev:skip_m.png |}}
  
 ==== Additional characteristics of strategies ==== ==== Additional characteristics of strategies ====
  • by svandav