Date: Fri, 29 Mar 2024 14:15:42 +0000 (UTC) Message-ID: <1266136783.5.1711721742945@33f76c91a0ec> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4_2026404582.1711721742945" ------=_Part_4_2026404582.1711721742945 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
All objects of any type (such as EmpowerID Persons, user account= s, and groups, etc.) managed by EmpowerID have an entry in a table of the E= mpowerID Identity Warehouse that corresponds to the object=E2=80=99s type. = Whenever you create a new object in EmpowerID, you are creating a new insta= nce of that object, which adds a new entry for that instance to the appropr= iate 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, wh= at 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 Empower= ID schema.
Extension: Properties that are provided for adding cust= om attributes. For example, if you=E2=80=99ve connected to an external dire= ctory with a user attribute not defined by the EmpowerID Schema, you can fl= ow that attribute to the EmpowerID Account and Person tables by using an ex= tension property on those objects.
When it comes to defining objects by object type, the EmpowerID Schema p= rovides the following components. These components make is possible to map = attributes in an external system to EmpowerID.
Object Attributes represent a catalog of abstract properties in EmpowerI= D that an object can have in any given system. Object attributes are concep= tual; they are not the actual name of properties in those systems. For exam= ple, =E2=80=9CLast Name=E2=80=9D is a concept. Each user has a Last Nam= e element in most directory systems. Depending on the system, this inf= ormation can be referred to as surname, FamilyName, l= ast_name and so on. Active Directory=E2=80=99s field to store this dat= a is simply labeled sn. EmpowerID has a single Object Attribute fo= r LastName to represent a user=E2=80=99s Last Name in each of thos= e systems.
Example object attributes
Object Attribute (EmpowerID) |
Object Attribute Type Name |
---|---|
AboutMe |
String |
AccountExpires |
DateTime |
Active |
Boolean |
LastName |
String |
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 th= at field each system. Security Boundary Attributes fulfill that role. Secur= ity Boundary Attributes are entries in EmpowerID that list any relevant pro= perties in a directory system =E2=80=93 including the EmpowerID directory = =E2=80=93 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=3D=3D'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 Secu= rity Boundary Attributes from four different systems (Security Boundary Typ= es). Each of these map to a specific Object Attribute in EmpowerID. This en= sures that attributes in external directories flow correctly to Person and = account records in EmpowerID at inventory and that any changes to those val= ues update when attribute flow is configured for those systems.
Add Attributes= to the EmpowerID Schema