You are viewing an earlier version of the admin guide. For the latest version, please visit EmpowerID Admin Guide v7.211.0.0.
About the EmpowerID Schema
- Phillip Hanegan
All objects of any type (such as EmpowerID Persons, user accounts, and groups, etc.) managed by EmpowerID have an entry in a table of the EmpowerID Identity Warehouse that corresponds to the object’s type. Whenever you create a new object in EmpowerID, you are creating a new instance of that object, which adds a new entry for that instance to the appropriate table. The properties or attributes of the object determine the table where these can be inserted.
The EmpowerID schema defines which objects can have which properties, what values those properties can have and how users might interact with them. EmpowerID has two types of attributes:
Built-in: Properties that are predefined by the EmpowerID schema.
Extension: Properties that are provided for adding custom attributes. For example, if you’ve connected to an external directory with a user attribute not defined by the EmpowerID Schema, you can flow that attribute to the EmpowerID Account and Person tables by using an extension property on those objects.
When it comes to defining objects by object type, the EmpowerID Schema provides the following components. These components make is possible to map attributes in an external system to EmpowerID.
Object Attributes
Object Attributes represent a catalog of abstract properties in EmpowerID that an object can have in any given system. Object attributes are conceptual; they are not the actual name of properties in those systems. For example, “Last Name” is a concept. Each user has a Last Name element in most directory systems. Depending on the system, this information can be referred to as surname, FamilyName, last_name and so on. Active Directory’s field to store this data is simply labeled sn. EmpowerID has a single Object Attribute for LastName to represent a user’s Last Name in each of those systems.
Example object attributes
Object Attribute (EmpowerID) | Object Attribute Type Name |
|---|---|
AboutMe | String |
AccountExpires | DateTime |
Active | Boolean |
LastName | String |
Security Boundary Attributes
In order to relate fields, such as the last name field in a given system to EmpowerID objects, there needs to be a way to describe whether a system supports the concept of a last name, and if so, to specify the name for that field each system. Security Boundary Attributes fulfill that role. Security Boundary Attributes are entries in EmpowerID that list any relevant properties in a directory system – including the EmpowerID directory – and provide actual native names for that type of system.
Example Security Boundary Attributes
Security Boundary Attribute | Security Boundary Type | Object Attribute (EmpowerID) | Attribute Type |
|---|---|---|---|
AboutMe | Microsoft SharePoint | AboutMe | String |
accountExpires | Active Directory Domain Services | AccountExpires | DateTime |
address[?(@.type=='work')].streetAddress | Azure AD SCIM | StreetAddress | String |
last_name | ServiceNow | LastName | String |
The above table demonstrates the relationship between Object Attributes and Security Boundary Attributes. In the table, there are four example Security Boundary Attributes from four different systems (Security Boundary Types). Each of these map to a specific Object Attribute in EmpowerID. This ensures that attributes in external directories flow correctly to Person and account records in EmpowerID at inventory and that any changes to those values update when attribute flow is configured for those systems.
Next Steps
Add Attributes to the EmpowerID Schema