Relationships
Relationships are a key consideration in the identity model. You can use relationships in various ways to organize identities and to drive authentication and authorization policies. Relationships exist between users, between users and organizations, and between organizations.
| The Identity Cloud schema does not support custom relationships. You cannot create a new relationship between managed objects, whether those objects are standard or custom; however, you can make use of multivalued attributes to establish lightweight associations between objects. For example, by using a multivalued user property to store an array of related object identifiers. |
- Relationship-derived virtual properties
-
For those relationships that exist in the standard data object model, you should consider the use of relationship-derived virtual properties (RDVP) for any information that can be used for authentication or included in authorization tokens. For example, if you use an organizational property to determine whether to enforce multi-factor authentication at login, then it is more efficient to store a copy of that property in the profile of each member of the organization, rather than looking up the organization properties using the relationship each time.
The caveat is that each update to the organization properties triggers an update to the users belonging to that organization if you mirror the organization properties using an relationship-derived virtual property. This overhead is amplified if the RDVP is included in outbound synchronization to any external repositories.
- Relationship properties
-
In some cases, relationships are not completely binary in nature. For example, if a user belongs to multiple organizations, the relationship may be different for each organization. A user can be authorized to represent multiple organizations, but have a different role at each. You may also want to store additional information about the relationship. For example, a user can be an alumni of multiple educational establishments and have a start/end date for each one.
In this case, you can consider defining relationship properties in the data object model. One or more properties can be defined for the relationship itself, such as role, date range, privileges, and others. You can include these properties in authentication decisions and access tokens.
