Custom Attributes Ownership
Custom Attribute Ownership (CAO) enables developers to build apps with custom attributes across multiple applications within OS1. OS1 consists of various objects, including Participants, Containers, and Entity, each with predefined attributes that dictate their properties. In addition to these system-defined attributes, developers can also create custom attributes tailored to their specific use case.
In a multi-app environment, developers may have several applications that utilize a single object. To maintain security and data integrity, developers can regulate read and write access to an object’s attributes in one application, preventing unauthorized modifications by other applications.
Imagine a tenant organization (T1) with three distinct applications (App1, App2, and App3). Allowing each application the authority to create or update any custom attribute within the ecosystem could raise security and consistency concerns. For example, if App1 creates a “phone number” attribute, App2 and App3 could potentially modify it without limitations.
CAO addresses this issue by granting tenant control over every attribute in their environment, regardless of the application. By implementing this framework, a tenant can effectively manage custom attribute access, enhancing security and ensuring data consistency across all applications.
The ObjectTypeOwner (OTO) and CustomAttributeOwner (CAO) apps are integral components in managing object types and custom attributes within OS1. The OTO app is responsible for creating and maintaining object types, while the CAO app is in charge of managing custom attributes for specific object types. Both apps work together to ensure proper control and permissions over object types and their associated custom attributes, thus enhancing data security and collaboration between different apps.
The OTO app is designed to establish and manage object types and designating ownership, such as a Vehicle being a participantType of the Participant object or a box being a containerType of the Container object. Using the application example above, when App1 uses the Participant API to create an Vehicle object type, it becomes the OTO for Vehicle and gains control over any custom attributes added to it. As the OTO, App1 can grant read/write permissions to other apps for the Vehicle’s custom attributes, ensuring secure data access and collaboration.
The CAO app focuses on creating and managing attributes for object types. For instance, if App1 (OTO for Vehicle) grants App2 permission to create custom attributes, and App2 creates the Registration No. attribute for the Vehicle object type, App2 becomes the CAO for Registration No. and controls read/write permissions for this attribute. Similarly, if App1 creates the Model attribute for Vehicle, it also becomes the CAO for Model.
Under this framework, the tenant has the following controls:
- The OTO App controls the addition of new custom attributes, preventing irrelevant or duplicate attributes.
- The CAO App defines access levels to control information sharing between apps.
- All read/write requests for data should go through the OTO App, rather than directly interacting with OS1, to maintain secure data management.
The OTO grants permission to an application to create custom attributes using an offline procedure. App developers can include a request for this permission in the access control YAML file as part of their app submission. Once the app is deployed, it will have access to the required APIs for creating new attributes.
Once the application has been granted the appropriate permissions, it can create custom attributes using the existing /config/attribute PUT endpoint to add a custom attribute for a specified objectType.
While adding a Custom Attribute, the CAO can define what apps can read the Custom Attribute. To provide read permissions to other apps, use the PUT /config/attribute endpoint. Keep in mind that write access remains exclusively available to the CAO. By default, the OTO app has read access to any Custom Attributes defined by other apps.
To specify whether a Custom Attribute is publicly readable, include the isReadPublic parameter when creating attributes. See the example request body below:
In this context, the isReadPublic parameter can have the following values:
- true: Grants read access to all apps for the Custom Attribute
- false (default): Restricts read access to the CAO only.
To define custom attributes for participantType ,containerType, and entityType, refer to the following How-To guide: