Support Branding Preferences in Thunder

[thiva-k]

Below are some of the design decisions we need to take regarding supporting branding preferences in Thunder.

Levels of Branding

Thunder's model naturally supports two levels of branding:

1. Application-level branding for individual applications
2. Organizational unit (OU)-level branding for OUs

In addition to these, we could also support organization-level branding, which would serve as the default branding for all applications and OUs under an organization.

We would need to decide who has permission to configure organization-level branding, how this branding is initially set up (during organization creation, via branding API, etc.), and whether organization-level branding can be overridden or if it's always inherited as a base configuration.

API

We need to decide on the API endpoint structure for retrieving and managing branding configurations.

Option 1: Query Parameter Approach (Similar to IS)

GET /branding?type=ORG
GET /branding?type=OU&id={ou_id}
GET /branding?type=APP&id={app_id}

Option 2: Resource-Based Path Approach

GET /branding/organization
GET /branding/organization-units/{ou_id}
GET /branding/applications/{app_id}

We should also support the /resolve endpoint for these respective endpoints for getting branding preferences with the resolution logic applied.

Governance

In Thunder's model, an application will be owned by/associated with an OU (the owner OU) but can be accessed by users from other OUs (participating OUs).

• Should we allow only certain branding attributes to be overridden by participating OUs while restricting others to the owner OU (aligning with resource model planned for Thunder), and if so, which attributes should be modifiable?

• Else, should participating OUs inherit the owner OU's branding as a base and customize, similar to Identity Server's approach?

Storage

• If we are to allow only certain branding attributes to be overriden by participating OUs, we should ideally separate owner-governed attributes and OU-specific attributes.
  Branding should also be considered when thinking about two levels of configuration for Thunder's resources.

• Also, what level of flexibility should we provide for storing branding preferences - fully dynamic JSON with minimal validation for flexibility, a strict schema for data consistency, or a hybrid approach with core attributes strictly validated while allowing custom attributes as flexible JSON?

Resolution

How should branding be resolved when an application is accessed by a user from a specific OU? Should the resolution follow a fallback chain such as:

• App-level branding→ participant OU-level branding → owner's App-level branding -> owner's OU branding → organization-level branding (if exists).

We may not need to follow's Identity Server's zig-zag pattern in Thunder's model.

Also, what should be the ultimate fallback if no branding is configured at any level - should there be a system default branding(which could be organizational-level branding), or should the API return an error or empty branding configuration?

Please, let know your suggestions and comments on the above topics.

[darshanasbg]

Are the contents of branding resource same for the all three levels (org, ou, app)?

[thiva-k]

Yes. They should be able to fallback from one level to another, if not configured. But we can have some elements configurable only by the owner OU, etc if needed.