Dimensions and Attributes
When Access Control syncs with your Directory Source, we look at all of the users fetched from the API to determine all of the possible keys and values, also referred to as “unique” keys and values. These are used to populate drop down selection menus and are used for database relationships between users and their respective attributes.
You’re likely already familiar with the key/value strings on a user profile in Google Workspace or Okta. It’s difficult to perform complex rationship mappings off of JSON arrays with lots of metadata. Access Control takes each key/value string and creates a database record for it and create a many-to-many database record mapping for each attribute that a user is associated with.
Dimensions
In Access Control, we use the terminology of Directory Dimensions and Directory Attributes. You can think of a dimension as a metadata key (ex. division) and attributes as all of the possible values for that key (ex. sales is one of the possible values).
We automatically create a Dimension database record in for each of the unique metadata keys that exist across all of the user profiles in the vendor’s API response.
For example, in Okta this includes all of the standard attributes and any custom profile attributes that your organization uses.
These keys include specific business contact info about the user (name, email, phone number, status), and organization org chart data (job title, department, division, cost center, etc). For data safety reasons, we do not import the postal address information at the street, city, or postal code level. we do import the province/state and country code since some systems (ex. HR benefits applications) are specific to where each user lives.
We haven’t saved the values of these keys in the Postgres database yet, they are only temporarily cached as arrays in Redis that are encrypted in transit and at rest.
Enabled Dimensions
Although we know all of the dimensions that exist, we do not create PostgreSQL database records for the attributes unless you enable the dimension. This allows you to opt-in to how much data is stored in Access Control.
Each dimension record in the database has an attributes_enabled boolean flag that is false by default. If true, we aggregate a list of all of the unique values for each key (during each sync job) across all users and create an Attribute database record for each of them with a parent foreign key for dimension_id. This allows us to dynamically import data into your database without manual input.
When your Source is synced for the first time, the dimensions are checked against a list of sensible default attributes to enable for the respective vendor.
For Okta, the following dimensions have attributes enabled by default:
organizationtitledivisiondepartmentcostCentercountryCodetimezone
You can see a preview of all of the unique attributes for a dimension before enabling it to ensure that it contains useful data for policymaking with manifest conditions.
Dimension Deprecation
When a dimension is no longer detected in the API, we do not want to cause an unexpected breaking change.
We use the expires_after_days value for the dimension to set the expires_at value on the dimension and all child relationships including attributes, rules, and conditions.
This has the benefit of providing a log alert, notice period in the UI, and allows administrators time to update impacted rules.
If administrators need more time, you can update the expires_at for the dimension. You can also convert the dimension from a source dimension to a custom dimension and preserve the existing attributes and attached users, however keep in mind that there is no longer a source of information so data is frozen in time unless you manually make changes.
After the expires_at has been reached, the dimension and all attributes, rules, and conditions will be deactivated (soft deleted). You can reactive (soft restore) these records if needed.
Relational Database Benefits
The benefits of using a relational database record for each dimension and attribute instead of a JSON array or document with strings are starting to become apparent with how we can now start doing pivot calculations and get all users for specific values without full JSON array parsing for recursive to the nth manifest calculations.
For example, the following API endpoints are available:
/api/v1/directory/dimensions/api/v1/directory/dimensions/{ulid}/api/v1/directory/dimensions/{ulid}/attributes/api/v1/directory/attributes/{ulid}/api/v1/directory/attributes/{ulid}/users/api/v1/directory/users/api/v1/directory/users/{ulid}/attributes