When you manage objects, you automatically also manage attributes. On a very high level, you can group the world of attributes into two classes.
One of these classes is known as “reference attributes”. Ironically, I have no idea, what the name of the second class – the “non-reference attributes” – is.

I’m wondering whether there is one… I will call them “self-owned” attributes. If someone has a better idea for a name, please let me know…

So, what is the difference between these two attribute classes? The purpose of a self-owned attribute is to describe the characteristics of an object.

Examples for self-owned attributes are first name, last name, display name, etc. The information that is tracked in these attributes is owned by the object the values are assigned to. So, if your first name is Britta and your last name is Simon, the information “Britta Simon” is something that belongs to you – you own it.

Next to your self-owned information, it is also common to track relationships you have in form of the second class of attributes – the reference attributes. One example for a reference attribute is the manager attribute in Active Directory.

Here is a simple example for this:

In case of a reference attribute, you have a referencing object and the referenced object. In case of our example, Britta Simon is the referencing object and Jimmy Bischoff is the referenced object.

What is so special about these reference attributes?

One aspect of a reference attribute is that you need to look-up self-owned information from a different object. For example, when you want to know who Britta’s manager is, the information “Britta’s manager is 007” will not help you much. Something like “Britta’s manager is Jimmy Bischoff” is typically what you want to know.

This is also the information you find, when you look at Britta’s properties in Active Directory:

To display the information about Britta’s manager you care about, the directory service:

  • Takes the reference value that is tracked in the Britta object
  • Queries the directory for the referenced object
  •  Retrieves the value from this object

What is the benefit of using reference attributes?

One aspect is certainly the manageability of the data “up-to-dateness”. Jimmy Bischoff might have several direct reports that are managed by him.

If a self-owned attribute of Jimmy Bischoff changes, there is no need to also update attribute values on the referencing objects. For example, if you update Jimmy’s email alias, the referencing objects can always find the most recent information without the need to update them.

Another aspect of the data “up-to-dateness” is also the validity of the relationship information. For example, what if Jimmy leaves the company? In this case, his Active Directory account is deleted. However, to ensure data validity, the directory service also updates all referencing objects by clearing in our example the value of the manager attribute of the affected objects. This process is also known as referential integrity.

To implement referential integrity, a directory service or database system must be able to locate the objects a reference attribute points to. In other words, referential integrity ensures that reference attributes point to existing objects.

To implement referential integrity, the object type of the referencing and the referenced object doesn’t matter. You can implement relationships between apples and oranges as long as these objects are uniquely identified by a known value. In case of Active Directory, all objects are uniquely identified by a GUID. In this case, having a GUID value is good enough to establish a reference relationship between objects.

In FIM, the synchronization engine also enforces referential integrity. However, in order to do this, all referencing and the referenced objects must be in the same connector space:

This is necessary to enable the synchronization engine to resolve and translate reference values.

For example, to keep the referential relationship between Britta and her manager intact, the synchronization engine needs to:

  • Look up the relationship in the connector space
  • Read the metaverse GUID of Jimmy Bischoff
  •  Set the right value for Britta’s manager in the metaverse

The following picture outlines this process:

In case of our example, the manager value 007 in the connector space needs to be translated into 205 in the metaverse. What happens if the referencing object and the referenced object are not in the same connector space?

Let’s assume, Jimmy Bischoff is in an organizational unit that is outside of the configured partition and container filter. In this case, Jimmy would not be imported into the connector space. When FIM imports a reference to an object that has not been imported yet, it still creates an object in the connector space to describe the relationship.

Such an object – a referenced object that has not been imported yet – is known as placeholder. Placeholders can’t be projected into the metaverse. In case of our example, the synchronization engine can’t calculate a value for Britta’s manager in the metaverse, since there is no object the reference could point to.

The following picture illustrates this scenario:

To summarize:

  •  A reference attribute is a pointer to another object.
  •  To enforce referential integrity, the referencing object must be an existing object the service that implements referential integrity must be able to locate it.
  •  FIM enforces referential integrity and keeps automatically your reference relationships intact across the metaverse and the various connector spaces.

When dealing with reference attributes in the context of FIM, you need to differentiate between "defining" references and "calculating" references.

Is there a difference between these two terms?

The definition of a reference happens when someone sets Britta’s manager. As nice as it would be if you could as an employee pick and choose your manager, in real life this is not what happens. While you have sort of the option to change your manager by moving to a different department, the value is still set by your business rules. You can only indirectly choose your manager by joining the department a manager is responsible for. So, it is still true to say that the definition of a reference is defined by business rules. The synchronization engine can calculate a reference by reading the values of an existing reference during a synchronization run and transforming these values during a transition between the metaverse and other connector spaces.

In other words, it is not subject to the metaverse to define relationships!

If you need to define reference values, you should do this in the context of a separate data source. This can be an operational data source you only configure to define reference relationships. However, the main requirement to have referencing and referenced objects in the same connector space is still true.

What if you can’t for some reason fulfill this requirement?

There is one option you have – "dereferencing" reference attributes. What does this mean? In this case, you need to turn the reference attribute into a self-owned attribute. This means, from the look and feel perspective, the “end result” might still look the same.

You can define a string attribute for an object and store a GUID value in this attribute. In this case, the “look and feel” of this attribute is the same as a reference attribute – an attribute that contains a GUID value. However, technically, there is huge difference.

In case of a self-owned attribute that stores a reference value, the services that enforce referential integrity don’t apply this process to the related attributes. From the perspective of the services, such an attribute is just an attribute with a string value as opposed to an attribute that points to another object. If you dereference reference attributes, there is no need to have referencing and referenced objects in the same connector space. However, in this case, you own making sure that related values are accurate or better valid. A self-owned reference attribute can exist in the metaverse and the synchronization engine is capable of transforming a self-owned reference into a reference attribute during the metaverse to connector space transition.

I hope, this article helps to clarify some aspects in conjunction with reference attributes.

You can find more details on this topic in the "Design Concepts for Managing Reference Attributes".