enabler/update documentation and structure

developer/Technical Documentation/Architecture/Architecture Constraints.md

@@ -0,0 +1,28 @@
+# Architecture Constraints
+
+## General
+
+* Homogenous UI/UX design across all user facing elements.
+
+* Run anywhere: can be deployed as a docker image, e. g. on Kubernetes (platform-independent, cloud, on prem or local).
+
+* Modular design: core-components are loosely coupled.
+
+* Freedom of choice for technology components stops where UX is negatively impacted. (currently under revision by the overall catena architecture roundtable)
+
+* Multi Language: German and english to be supported as a minimum
+
+## Developer
+
+* OpenSource software first - FOSS licenses approved by the eclipse foundation has to be used. It could represent the initial set that the CX community agrees on to regulate the content contribution under FOSS licenses.
+
+* Coding guidelines for FE and BE are defined and are to be followed for all portal related developments. 
+
+* Apache License 2.0 - Apache License 2.0 is one of the approved licenses which should be used to respect and guarantee Intellectual property (IP).
+
+* Code Analysis, Linting and Code Coverage - Consistent style increases readability and maintainability of the code base. Hence, we use analyzers to enforce consistency and style rules. We enforce the code style and rules in the CI to avoid merging code that does not comply with standards.
+
+## Code analysis, linting and code coverage
+
+--comming soon---
+(Veracode; Eslinter, Sonarcloud, etc.)

developer/Technical Documentation/Architecture/Building block view.md

@@ -0,0 +1,15 @@
+# Building Block View
+
+The Portal as an overall product is a complex composition of several interacting solution building blocks, each comprised of a backend (including api and db) and frontend component, depicted in the following blackbox-illustration:
+
+<img width="1162" alt="image" src="https://user-images.githubusercontent.com/94133633/209236545-b8078e36-0ac6-472e-87c8-4da826e22e75.png">
+
+Beyond this view, the portal allows for component integration of other (sub-products) that need to expose user-faced ui-functionality to the Catena-X community members (company and user level).
+
+Currently integrated (or in the process of being integrated) products are:
+
+* Semantic Hub
+* BPDM
+* Self-Description Factory
+* Clearing House / Gaia-X
+* Digital Twin Registry

developer/Technical Documentation/Architecture/Context and scope.md

@@ -0,0 +1,8 @@
+# Content and Scope
+
+## Business Context
+Any uses-case, value stream, function within Catena-X can be exposed an accessed via the portal. It builds the foundation for x-company interaction and collaboration and further provides access to the overall value proposition of Catena-X.
+
+## Technical Context
+The provided components (see building block view) comprise the technical foundation for interaction, integration, authentication, authorization, provisioning, monitoring, auditing and further functionalities. They are state of the art in terms of technology portfolio, consist of open-source components whenever possible and are open-sourced themselves 100%.
+

developer/Technical Documentation/Architecture/Development Concept.md

@@ -0,0 +1,31 @@
+# Development Concept
+
+## Build, test, deploy
+Details to the build, test and deploy process can get found under following link/md file:  
+https://github.com/catenax-ng/tx-portal-assets/blob/945546d91065b8870aa8f69ce94b48eac7a5ade2/docs/Release-Process.md
+<br>
+<br>
+
+## Development Guidelines
+The portal is using following key frameworks:
+<br>
+* Javascript / React
+* .Net
+* i18n
+* Keycloak
+<br>
+<br>
+
+#### Swagger
+The API uses OpenAPI annotations to describe the endpoints with all necessary information. The annotations are then used to automatically generate the OpenAPI specification file, which can be viewed in the Swagger UI that is deployed with the application.
+<br>
+<br>
+
+## Migration
+To run the portal, migrations are needed to load the initial data inside the identity provider and the portal db to enable the portal to work.
+The migration will consist of an initial migration as well as delta migration files with future releases. As part of a new release, a migration file (if applicable) will get released and can get loaded via a delta load.
+<br>
+<br>
+
+## Configurability
+Portal configuration is mainly possible via the appsetting files as well as the static data migration files.

developer/Technical Documentation/Architecture/Requirements.md

@@ -0,0 +1,19 @@
+# Requirements overview
+
+## What is the Portal & Marketplace Product?
+
+The Portal & Marketplace Product combines 4 main components of the Catena-X core services:
+- Registration Front End
+- Portal & Marketplace Front End
+- Registration, Portal and Marketplace API services
+- Identity & Access Management
+
+## Requirements
+
+For Catena-X Member Companies
+|ID|Title|Requirement|
+|--------|--------|--------|
+|REQ-C-001|Easy Onboarding|Company Onboarding must be simple, transparent, reliable, and quick.|
+|REQ-C-002|BPN-Integration|Each member company is integrated with its global BPN the enable unified identification (also cross-network)|
+|REQ-C-003|Cross-Network|Companies already verified in other (supported/friendly) networks will receive fast-lane onboarding|
+|REQ-C-004|Identity Integration|Authentication is done vis IdP Federation to minimize administration overhead and to simplify logins. Authorization not included, this must be done Catena-X specific by the Central-IdP|

developer/Technical Documentation/Architecture/Solution strategy.md

@@ -0,0 +1,6 @@
+# Solution Strategy
+
+* The technology portfolio and development stack are kept simple, based on commodity and oss components and products.
+* APIs are always REST-based with token authentication.
+* OIDC is used for authentication and authorization.
+* IaC is fully realized via helm charts.

developer/Technical Documentation/Architecture/Whitebox Overall System.md

@@ -0,0 +1,42 @@
+# Whitebox Overall System
+
+
+## Summary
+<br>
+<img width="1000" alt="image" src="https://user-images.githubusercontent.com/94133633/209236685-6c7857c6-9b66-42e0-b796-59a34ae2ab9c.png">
+<br>
+<br>
+
+## Contained Building Blocks
+
+### Portal
+<br>
+Integration: Portal, Marketplace, Backend, Wallets, BPDM, SD Factory, AutoSetup, Discovery and more:
+<img width="600" alt="image" src="https://user-images.githubusercontent.com/94133633/209236749-3b0cafba-5a62-4d5e-b9ec-fe55f5a658df.png">
+<br>
+<br>
+
+### Registration (Company Onboarding)
+<br>
+<img width="450" alt="image" src="https://user-images.githubusercontent.com/94133633/209236789-8ebd1994-bef4-47c5-b802-6c1425eeae7a.png">
+<br>
+<br>
+
+### Central IdP & Shared IdP
+<br>
+<img width="600" alt="image" src="https://user-images.githubusercontent.com/94133633/209236881-be6bba4b-bafe-42ca-a098-8b71c45a5824.png">
+<br>
+<br>
+<img width="600" alt="image" src="https://user-images.githubusercontent.com/94133633/209236841-bfadebcd-d138-42ef-aeea-4cc8a5429bfa.png">
+<br>
+<br>
+
+### Marketplace
+<br>
+<img width="600" alt="image" src="https://user-images.githubusercontent.com/94133633/209236917-f5ab7bc9-f7c8-4732-a5ef-d8ed80caa53d.png">
+<br>
+<br>
+
+### Important Interfaces
+
+*** to be added ****

developer/Technical Documentation/Architecture/operational-concept.md

@@ -0,0 +1,30 @@
+# Operational concepts
+
+## Administration
+
+### Configuration
+The Portal can be configured using two methods:
+
+### appsettings.json
+If you build the Portal, you can modify the appsettings.json for each backend service, to individually configure to a certain extend. This file contains all possible config entries for the application.
+
+### Helm Chart
+The most relevant config properties are exposed as environment variables and must be set in the Helm chart so the application can run at all. Check the Portal Helm chart in Git for all available variables.
+
+### DB Migration File
+Static Data migration files provide a certain configuration possibility by adding or deleting static data records before the deployment. Be aware that touching static data files will always impact the application business process. It is suggested to always test the application with the planned changes carefully in INT before releasing to a productive env.
+
+## Disaster-Recovery
+Note: will be added soon
+
+## Scaling
+If the number of consumers raises, the IRS can be scaled up by using more resources for the Deployment Pod. Those resources can be used to utilize more parallel threads to handle Job execution.
+
+## Clustering
+Note: will be added soon
+
+## Logging
+The portal supports application and db logging. Details are stored here: https://github.com/catenax-ng/tx-portal-assets/blob/945546d91065b8870aa8f69ce94b48eac7a5ade2/docs/Technical%20Details/Auditing.md
+
+## Monitoring
+Note: Prometheus and Grafana are planned

developer/Technical Documentation/IdP/Email Configuration.md

@@ -0,0 +1,66 @@
+# IdP Email Configuration
+
+## Requirement
+tbd - setup will be needed
+
+
+## How to configuring email for a realm
+Keycloak can send emails to users for several different scenario
+
+* to verify the user email address
+* to recreate a password in case it was forgotten
+* or when an administrator needs to receive notifications about a server event
+<br>
+
+To enable Keycloak to send emails, SMTP server settings need to get configured by following steps:
+* <strong>Login</strong> to the respective Keycloak instance and open the relevant realm
+* Click <strong>Realm Settings</strong> in the menu.
+* Click the <strong>Email</strong> tab.
+* Fill in the fields and toggle the switches as needed.
+<br>
+<br>
+
+###### Host
+SMTP server hostname used for sending emails.
+<br>
+
+###### Port
+SMTP server port.
+<br>
+
+###### From
+Address used for the From SMTP-Header for the emails sent.
+<br>
+
+###### From Display Name
+Allows to configure a user friendly email address aliases (optional). If not set the plain From email address will be displayed in email clients.
+<br>
+
+###### Reply To
+Reply To denotes the address used for the Reply-To SMTP-Header for the mails sent (optional). If not set the plain From email address will be used.
+<br>
+
+###### Reply To Display Name
+Reply To Display Name allows to configure a user friendly email address aliases (optional). If not set the plain Reply To email address will be displayed.
+<br>
+
+###### Envelope From
+Envelope From denotes the Bounce Address used for the Return-Path SMTP-Header for the mails sent (optional).Enable SSL and Enable StartTSLToggle one of these switches to ON to support sending emails for recovering usernames and passwords, especially if the SMTP server is on an external network. You will most likely need to change the Port to 465, the default port for SSL/TLS.
+<br>
+
+###### Enable Authentication
+Set this to ON if your SMTP server requires authentication. When prompted, supply the Username and Password.
+<br>
+
+
+#### Catena-X Implementation
+
+smtp-host: smtp.office365.com
+smtp-port: 587
+Enable StartTLS
+Enable Authentication
+visible in https://catenaxdev003akssrv.germanywestcentral.cloudapp.azure.com/iamcentralidp/auth/admin/master/console/#/realms/CX-Central/smtp-settings
+<br>
+<br>
+it's mandatory the 'from' email-address and the smtp-username used to authenticate with the office365 mailing-service are identical. Therefor [email protected] is configured as email address.  
+This can get changed (if necessary) if a new login/account with the respective email is created.