Suggested Changes in ConnId Related to Associations

Last modified 25 Jul 2024 17:55 +02:00

There are two new concepts there:

Reference attributes
Embedded objects

Reference Attributes

Besides having simple attributes, like strings, integers, timestamps, and so on, ConnId now provides reference attributes. They have values of ConnectorObjectReference type.

Each value of such attribute points to a specific connector object; either "by value", i.e., by embedding that object, or "by reference", i.e., by referencing that object using one or more identifiers.

Schema Support

These attributes are described in the schema by the following:

Item Description

Item	Description
`referencedObjectClassName`	Object class of referenced objects. Optional. The connector may not have this information, or sometimes, there may be more than a single object class that can be referenced by the attribute. (For example, `member` attribute on the `group` object can reference accounts, groups, and other kinds of objects.)
`roleInReference`	The role of an object in the relationship (provided by specific reference attribute). Optional.
`subtype`	If present, it contains the connector-wide identification of the reference. This is important especially for bi-directional relations (like the group membership), where the client might be interested that the reference attribute (e.g.) `group` on the `user` object is bound to the reference attribute (e.g.) `member` on the `group` object. Optional.

referencedObjectClassName

Object class of referenced objects.

Optional.

The connector may not have this information, or sometimes, there may be more than a single object class that can be referenced by the attribute. (For example, member attribute on the group object can reference accounts, groups, and other kinds of objects.)

roleInReference

The role of an object in the relationship (provided by specific reference attribute).

Optional.

subtype

If present, it contains the connector-wide identification of the reference.

This is important especially for bi-directional relations (like the group membership), where the client might be interested that the reference attribute (e.g.) group on the user object is bound to the reference attribute (e.g.) member on the group object.

Optional.

Roles in the reference:

Role Description

Role	Description
`subject`	The holder can be considered a subject of the relationship. It is the usual source (starting point) of relationship navigation, i.e. we usually ask "what objects does the subject hold", not the way around. Typical example: account or other type of group member (when regarding group membership relation).
`object`	The holder can be considered an object of the relationship. It is the usual target (ending point) of relationship navigation. Typical example: the group that has some members (when regarding group membership relation).

subject

The holder can be considered a subject of the relationship. It is the usual source (starting point) of relationship navigation, i.e. we usually ask "what objects does the subject hold", not the way around.

Typical example: account or other type of group member (when regarding group membership relation).

object

The holder can be considered an object of the relationship. It is the usual target (ending point) of relationship navigation.

Typical example: the group that has some members (when regarding group membership relation).

The subtype (type name of type type of the reference) is currently not used in ConnId framework in any way. I considered removing it from ConnId; but that would probably require reworking the definitions structure on midPoint side. So I suggest keeping it as is; I suppose it could be useful in the future.

MidPoint currently requires:

roleInReference; this is hard to guess, so I suggest to provide it by connector now.
subtype; this is required as well, although, in theory, it can be generated by midPoint - if really needed.
referencedObjectClassName; but only for those references that are not defined from both sides (linked via subtype + roleInReference).

Behavior

Reading

When reading, it is currently up to the connector how it will deal with referenced objects, i.e., whether it will provide only object identification, or full data.

A reasonable behavior would be to provide embedded objects (see below) in full, while regular ones by identification.

Adding Values

If a referenced object is passed by value, the connector is allowed to create the respective object on the resource. This is reasonable especially for embedded objects.

Deleting Values

For embedded objects, one could expect that the connector will delete the object when the corresponding value is deleted from the resource. But the specific behavior is up to the connector.

Embedded Objects

An object class can be marked as embedded. Currently, this has no meaning within the ConnId framework itself; it is just an indication for the clients.

Open Questions, Future Work

"Embedded Objects" Term

Can we think of a better name instead of embedded object class?

UID and Name for Embedded Objects

Sometimes, embedded objects do not have any natural key that could be used as UID or name. For example, access can be defined simply as a triple (subject, object, access level), without the need of any extra identifiers. So, we’d need a concept of alternative identifiers here.

I thought of removing the need of having a UID and name for embedded objects. While this is easy to do in ConnId, it would require some follow-up work in midPoint, which is hard to do now.

Complex Attributes

Embedded objects are quite close to complex (structured) attributes. We could explore this direction.

Controlling Fetching of Referenced Objects

Client could request whether to fetch referenced objects in full, or not; and if full, what specific attributes should be provided. And recursively, regarding objects referenced from that referenced object. A generalization of "attributes to get" options (e.g., to paths) comes to mind.

Updating Embedded Objects

It should be possible to update embedded objects, in a way more intelligent than the current "delete old object + add new one".

Rich Specification of Referenced Object Candidates

Currently, when the client wants to look up objects that are suitable as reference attribute target, it can use referencedObjectClassName information. In the future, the connector could supply more specific information - if relevant - like a filter that narrows the set of applicable objects.

In a related way, how to specify multiple candidate object classes? (The proposed use of subtype to denote reference type could help, assuming that there is the other side of the relationship defined.)

Object Class Information in References

What if the connector does not know the object class of referenced object? E.g., for LDAP member attribute, what if it knows only the object name, without the object class?

Was this page helpful?

YES NO

Thanks for your feedback