Current implementation As reported, virtual attributes are attributes whose ownership is not of Syncope but of one or more external resources; such resources are said to be the linking resources for the given attribute. A virtual attribute needs to be explicitly assigned, e.g. instantiated from a given virtual schema, to a given user (or group or any object). Virtual attributes can be part of mapping for one or more resources:
- in propagation -> to set value(s) on the linking resources or other resources
- in synchronization -> to set value(s) on Syncope from linking resources
At operation level:
- values must be fetch when reading users (groups, any objects) via REST - if mapped
- effective read invocation on the underlying connectors is reduced by using cache
- virtual attributes are populated into users (group, any objects) exclusively by
VirAttrHandler , only when strictly required
- user (group, any object) update is often problematic: virtual attributes to be removed and updated need explicit management in
PropagationManager
- when the same attribute is mapped for different resources (linking or not), a list of values is generated and it is not clear where the ownerships come from
Refactoring proposal When defining a virtual schema, it is mandatory to define the linking resource(s); virtual attributes are not assigned any more to users (groups, any objects) |