Skip to content
English
More support Sign in
Contact us
  • There are no suggestions because the search field is empty.

Unify Integrations - Unify API Strict Schema

Living Security's Unify API has the ability to consume JSON objects based on a Strict Schema to emit activities to your Unify Tenant.

📚 Overview

Leveraging the Strict Schema via the Unify API will allow your organization to emit events directly to the Unify platform via a Unify API endpoint. 

In order to leverage this functionality, your organization will need to leverage some form of solution that has data transformation capabilities.

It is best to engage your organization's infrastructure and/or data transformation team to understand how your organization handles ETL requirements for strict schemas.

👤 Identity Updates

If you are seeking to leverage the strict schema to provide updates for identities within your organization, an IDENTITY.UPDATE event can be leveraged to apply attribute and alias updates to entities within your tenant. See below example of a strict schema payload for applying an IDENTITY.UPDATE event:

{  
    "id": "9ae591c7-6980-4330-b823-903eea4958c9", <- Must be a Unique GUID
    "timestamp": "YYYY-MM-DDTHH:MM:SSZ",
    "event_types":
        [  
            "IDENTITY.UPDATE"
        ],
    "identities": [
        {  
        "event_role": "TARGET",
        "entity_type": "user",
        "identity":
            {  
                "first_name": "XXXXX",
                "last_name": "XXXXXXXXXXXXXXX",
                "department": "XXXXXXX",
                "title": "XXXXXX",
                "office_location": null,
                "business_unit": null,
                "employee_level": null,
                "employee_type": "XXXXXXX",
                "employee_work_status": null,
                "organization": null,
                "city": null,
                "country": null,
                "region": null,
                "aliases":
                [  
                    {
                        "value": "XXXXXXXXXXXXXXX",
                        "type": "DIRECTORY_IDENTIFIER"
                    },
                    {
                        "value": "XXXXXXXXXXXXXXX",
                        "type": "SERVICE_IDENTIFIER"
                    },
                    {
                        "value": "xxxxxxx.xxxxxxxxx@livingsecurity.com",
                        "type": "EMAIL"
                    }
                ]
            }
        }
    ],
    "endpoints": null
}

Values that are required to perform an IDENTITY.UPDATE event are below, all other fields are optional and can be excluded from the JSON object to reduce payload sizes:

"id" It is recommended that a GUID method generate this ID to ensure a unique identifier of the object is generated
"timestamp" A timestamp of when the object was submitted is required to align the IDENTITY.UPDATE Event with your submission. 
"event_types" This tells the Unify Ingestion service what we need to apply to the system as far as events go. As this is an identity update, we would ensure the submitted identities.user values are updated.
"identities.user" This is used to resolve the update(s) of identity values to a resolvable identity within the Unify Platform. Only one is required, and it is recommended you use an alias from your source of truth in Unify. 

🏗️ Event Activities

Before leveraging this feature, data discovery is highly recommended to be performed between your organization and Living Security. This will ensure that all event types that should be accounted for would be leveraged in effective ways.  

If you are leveraging a data lake, or some form of middleware that allows you to transform your raw alerts/events from a data source, you can submit simple events to Unify like the one below:

{
    "id": "2e77c1bd-fe23-4610-9c1c-ba657ac885bd",
    "timestamp": "2024-01-30T21:41:50Z",
    "event_types": 
        [  
            "SERVICE.AUTHENTICATION.FAILED"
        ],
    "identities": 
        {
            "event_role": "SOURCE",
            "entity_type": "user",
            "identity":
                {
                    "aliases":
                        [
                            {
                                "value": "XXXXXXXXXXXXXXXXXXXXXX",
                                "type": "SERVICE_IDENTIFIER"
                            },
                            {
                                "value": "xxxxxxx.xxxxxxxxx@livingsecurity.com",
                                "type": "EMAIL"
                            },
                            {
                                "value": "XXXXXX XXXXXXXX",
                                "type": "DISPLAY_NAME"
                            }
                        ]
                }
        },
    "endpoints": null
}

All fields required triggering a Unify event can be found below:

"id" It is recommended that a GUID method generate this ID to ensure a unique identifier of the object is generated
"timestamp" A timestamp of when the object was submitted is required to align the event with your submission. 
"event_types" This tells the Unify Ingestion service what we need to apply to the system as far as events go. 
"identities.user" This is used to resolve the update(s) of identity values to a resolvable identity within the Unify Platform. Only one is required, and it is recommended you use an alias from your source of truth in Unify.