What is Clarity?

Clarity Security is an Identity Governance platform built on a Decentralized Identity framework. Decentralized identity frameworks assert that while a Downstream Application may not accurately represent the users that should be active, they do accurately report on their local and federated users, entitlements, and service user entitlements (primary data). As such, Clarity looks to downstream applications as the system of record for its identity and access information. Direct connections to the downstream applications are established via API or automated reporting to ensure Clarity has a complete and accurate representation of identity information in (near) real-time.

How does Clarity Work?

Clarity Security fundamentally operates following the below steps:

1. Primary identity data stored on downstream applications is queried, imported, and written to an internal Clarity primary data store.
2. Internal data is processed by Clarity to perform fundamental operations such as creating a Universal Directory, clean-up of orphaned accounts and un-terminated identities, and generating Access Reviews campaigns.
3. The Universal Directory is leveraged to dynamically mine and establish a baseline role based access control structure.
4. Provisioning and Deprovisioning can be enabled for downstream applications allowing Clarity to directly grant and remove access to users on these apps.
5. Access Reviews coupled with deprovisioning enables an end-to-end Access Reviews campaign process - campaign generation, distribution to reviewers, tracking responses, automated remediation of findings, and logging of all actions in an AWS Quantum Ledger.
6. Life-Cycle Management is the culmination of the provisioning & deprovisioning, the Universal Directory, and Role Based Access Control. Life-Cycle Management starts with changes in the Universal Directory which triggers provisioning or deprovisioning actions based on the access granted by an identity's destination role.

Primary Data Imports

How do we connect to your applications?

Clarity Security application connectors use a range of secure authentication methods such as OAuth 2.0, Preshared API Keys, JSON Web Tokens, and other mechanisms as defined by the Downstream Application's available API endpoints. For authentication information on your tech stack see the Application Marketplace documentation.

Similar to the differing Clarity authentication methods, the API protocols and standards used to connect to downstream applications vary depending on the downstream application's internal architecture. The most common types are: REST, SCIM, GraphQL, an On-Premises Connection VM, and Reports as a Service.

What data is imported?

We import Service Users, Entitlements, Service User Entitlements, and Service User Attributes.

Example Service User object:

{
    "id": "d81fba0f6fc3c76d802e44d066e1693a", 
    "pmi": 2020072151, 
    "type": 2, 
    "email": "sam.mcclarity@claritysecuritydemo.io", 
    "status": "active", 
    "role_id": "2", 
    "language": "en-US", 
    "timezone": "America/Chicago", 
    "verified": 1, 
    "last_name": "McClarity", 
    "created_at": "2022-07-02T07:20:08Z", 
    "first_name": "Sam", 
    "job_title": "Systems Engineer",
    "department": "Information Technology",
    "manager": "Alexis Adkins",
    "last_login_time": "2023-01-30T:59:10Z", 
    "user_created_at": "2022-07-02T23:21:00Z"
}

Example Entitlement object:

{
    "name": "Reliable Internetwork Troubleshooting Agent",
    "id": "176e50df-8d23-3d8b-4d4d-1623e0602255",
    "licenses": null, 
    "groupTypes": ["Unified"], 
    "mailEnabled": true, 
    "securityEnabled": true
}

How is the data stored?

Primary data is imported and stored in a single tenant database. Each row in the primary data tables (service users, entitlements, and service user entitlements) contains an copy of the raw unprocessed data object (JSON, XML, etc) received from the application, and the relevant attributes used by Clarity are extracted from the data object and written to individual columns.

Initial Processing and Utilization of Primary Data

After Clarity finishes importing primary data, we perform light processing of the service user, entitlement, and service user entitlement data. The processing at this stage is limited to:

• Parsing the service user and entitlement objects into individual cells in the database
• Creating identities in the universal directory using the attributes associated with service users found in sources of truth
• Establishing relationships between service users and identities
• Generating alerts on anomalies or orphaned accounts.

Universal Directory

The first time primary data is manipulated beyond flattening JSON or XML objects is during the creation of the Universal Directory. Clarity first searches the Service User table for active users found in sources of truth. As these service users are identified, a workflow is triggered that automatically creates a Clarity Identity in the Universal Directory. The newly created identity is then populated with any known attributes associated with the service user. This identity is considered to be secondary data and is the first piece of data that cannot be directly queried for on a downstream application.

Once the Identity is created and the attributes have been applied, Clarity then searches the Service User table for Usernames, GUIDs, UUIDs, and Emails that match the identity's attributes. As these matching service users are found, Clarity forms a permanent link between the service user in a downstream app to the Clarity Identity.

Now that Clarity created the identity and has a link to each of its service users, it queries the Service User Entitlement table for Entitlements assignments. The identity is updated to reflect each Service User Entitlements pairing it finds.

After all of the primary data tables have been searched and correlated to an identity, the Universal Directory is complete.

For more information see Identities.

Access Reviews and Compliance

Access Reviews campaigns rely on the data being both Complete and Accurate. To ensure the campaign is a complete data set and an accurate representation of what an auditor would see in the downstream application, Clarity uses the primary data tables during campaign generation rather than data found in the Universal Directory or secondary data tables.

Generating Access Reviews campaigns using primary data provides auditors with two additional layers of evidence:

1. Eliminating any processed data from the review ensures that the data a reviewer certifies is a bit for bit clone of the data found in a downstream application.
2. As all API calls & DB queries Clarity executes are logged to an immutable ledger, the audit can manually run the same queries to recreate the exact data set Clarity is presenting to the reviewers.

For more information see Access Reviews.

Alerts and Data Clean Up

The final component of the initial data processing is automated and manual remediation of inconsistencies or Orphaned Accounts identified by Clarity. Some examples of inconsistencies that may be found are:

• Active service users are found in a non-source of truth application, but there is no corresponding Identity in Clarity.
• Active service user found in a non-source of truth application, but the corresponding identity is inactive.
• An active service user found in a non-source of truth application does not have a corresponding identity in Clarity, but a matching inactive service user was found in a source of truth.

As these inconsistencies are identified and an alert is generated, Admins are prompted to perform the remediations within the Clarity UI. The remediation options available in Clarity are:

• Automatically deprovision the service user in the downstream application.
• Merge the service user with a known identity.
• Create a new identity in Clarity using the service user as the starting attributes.

The relevance of each of these examples and information on the remediation options is explained in greater detail in the Alerts Section and x blog posts.

Secondary Processing and Automation

Role Based Access Control

Groups of access.

Provisioning and Deprovisioning

Granting and removing access to a downstream application.

Life Cycle Management

Automated provisioning and deprovisioning using roles (RBAC) and workflows