# UDiTH Portal Overview

UDiTH Portal is a server-based centralised platform that contains multiple optional submodules:

### Central Model Repository

Centrally manage and version UDiTH models. Models are imported into the repository and made available across your organisation. Each model can have multiple versions, and storage is fully managed by Portal.

### Search (Tag Register)

Extract model attributes into a searchable tag register. This allows users to find model objects, both 3D and PID, across multiple models through Portal search.

### Model Import

Import models into the Central Model Repository, either manually through the web interface or automatically by placing files in an import folder. Automated imports can be configured through a `modelDefinition.json` file.

### Browser-Based Viewing

View UDiTH models in a lightweight browser. Rendering is carried out on a separate machine. This requires render servers and TURN servers.

## Architecture Overview
![](media/Portal_traffic.png)

The solution consists of multiple components. The image above contains a reference architecture. This is only one possible setup; the product is very flexible and can be deployed in many different configurations to suit your environment. Clients connect to a DMZ that hosts the Portal/MSSQL access server, the ICE server, and the Keycloak authentication server, while the render servers are placed in the internal network.

The components are split across two network zones, both of which may be hosted in the cloud or on-premises:

- **DMZ** — the client-facing zone. It hosts the Portal access server (UDiTH Portal / MSSQL connection and access portal), the ICE server (CAXturn on Windows or Linux, or coturn on Linux), and the Keycloak authentication server. Clients from all networks reach these components directly.
- **Internal Network** — hosts the render servers (Windows). Render servers are not exposed to clients directly. They connect outwards to the Portal for management, to the ICE server for relayed streams, and provide the direct (peer-to-peer) stream to clients where possible.

The diagram also distinguishes the types of traffic that flow between these components:

| Traffic       | Description                                                                 |
|---------------|-----------------------------------------------------------------------------|
| Request       | The initial client request to the Portal access server.                     |
| Direct Stream | The peer-to-peer WebRTC stream from a render server to the client.          |
| Relay Stream  | The WebRTC stream relayed through the ICE server when no direct (peer-to-peer) connection can be established. |
| Authentication | Client and component authentication handled by Keycloak.                   |
| Management    | Control traffic between the Portal and the render servers.                  |

Keycloak is used to handle user authentication and authorisation and can be extended to integrate with different OpenID Connect authority providers.

An MSSQL database handles the persistence layer. It can be hosted on the same server or on an additional server.

The ICE server is used as a proxy server for WebRTC connections between the render servers and clients if no peer-to-peer connection can be established.

CAXperts provides the deployment files. The operational aspects and infrastructure must be handled by the customer.

Portal, ICE, Keycloak, and SQL Server are often combined, and this is an approved hosting setup.

## Requirements

For component requirements, including ports, supported versions, and database notes, see the [Requirements](/UDiTH%20Portal/Requirements) page.

## Licensing

UDiTH Portal is licensed.

Please contact sales if you are interested.

Licence operation requires an active internet connection to our licensing server.