---
# System prepended metadata

title: Serverkonfig

---

## Serverkonfig:
**dns:** x.web.de
**Dir:** /var/www/x
Das **Zert** befindet sich in /certs/x.pem
**Key:** /certs/x.key

**Loesung:**
```
server {
    listen 443 ssl;
    server x.web.de;
    root /var/www/x;
    cert /certs/x.pem;
    key /certs/x.key;
}
```

## Datenpakete skizzieren:
**x.web.de:** 2.3.4.5
**Browser:** 4.4.4.5
https://x.web.de/bilder/klasse.html
### Request:
```
Ethernet| Inet    | tcp | tls | http                    | Daten
Macs    | 4.4.4.5 |2727 |     | dns: x.web.de           |
        | 2.3.4.5 |443  |     | GET /bilder/klasse.html |
(! Client bekommt eine freie Portnr > 1023)

```

### Response:
```
Ethernet| Inet    | tcp | tls | http               | Daten
Macs    | 2.3.4.5 |443  |     | Content-Type: html | <html>...
        | 4.4.4.5 |2727 |     |                    |
```

## Server auf Webdienst weiterleiten
**Server:** y.web.de
**Webdienst:** http://localhost:3456
 
```
server{
  listen 443 ssl;
  server y.web.de;
  location /  => http://localhost:3456;
  cert /certs/y.pem;
  key /certs/y.key;
 }
```

# Probe Sa
Webserver verwenden das Protokoll **http**. Dieses Protokoll ist **zustandslos**. Was bedeutet dies? 
*Es wird bei jedem Zugriff eine neue Verbindung aufgebaut, der Zustand der alten Verbindung ist unbekannt.*

Wie kann eine http-Anwendung einen Zustand bekommen: 
*SessionId in cookie speichern*

Auf Ihrem Webserver besteht eine Zwangsumleitung fuer alle http-Anfragen. Was bedeutet dies?
*Jede http Anfrage wird auf https umgeleitet, damit alles verschluesselt ist*

Was steht in so einem Zertifikat?
*Dns-Name <=> publicKey, TC-Signatur, Gueltigkeitsdauer...*

Was ist ein Wildcard-Zertifikat?
*Gilt fuer alle Namen in einer (sub)domain*

Was ist Wildcard-DNS:
*alle SubDomains eines Namens haben im DNS die gleiche Ip.
A.b11b.de b.b11b.de,... haben alle die ip 4.5.6.8*

Fuer was sind die Wildcard-Teile nuetzlich? 
*Fuer vHost, revProxys*

Handelt es sich bei Ihrem zert um ein Wildcard Zertifikat?
*Ja*

Erstellen Sie eine Konfig fuer einen vHost. Anfragen an https://x.b11b.de werden aus dem Verzeichnis /www/x beantwortet
```
server {
    listen 443 ssl;
    server x.b11b.de;
    zert /z.b11b.zert;
    key /z.b11b.key;
    root /www/x;
}
```

Das Programm rest1.exe beantwortet auf Port 6789 Rest-Anfragen
Wie koennen Sie erreichen, dass das Prog ueber die URL https://rest1.b11b.de erreichbar ist?
```
server {
    listen 443 ssl;
    server rest1.b11b.de;
    zert /z.b11b.zert;
    key /z.b11b.key;
    Location /=> http://localhost:6789/;
}
```

Hans hat die Ip 4.5.6.7.
Hans gibt im Browser obige Url ein. Skizzieren Sie ein Datenpaket.

| Inet | tcp | tsl | Http | Daten |
| -------- | -------- | -------- | --- | --- |
| 4.5.6.7 | 4569  | (version)  | Rest1.b11b.de | |
|4.5.6.8|443||GET /| |

Skizzieren Sie das Datenpaket der Antwort des Servers
| Inet | tcp | tsl | Http | Daten |
| -------- | -------- | -------- | --- | --- |
| 4.5.6.8 | 443  | (version)  | Rest1.b11b.de | {"daten":"???"} |
|4.5.6.7|4569||Content-Type: apllication/json| |

Was bedeutet SSL-Terminierung?
*Der Transport vom Browser zum revProxy wird TLS verschluesselt, der Weg zum rest1-Programm (interner Server) ist unverschluesselt*

Hans hat das Prog rest1.exe in ein docker-image hans/rest1 verpackt, starten Sie 2 Container von diese Image:
*docker run -d -p 6789:6789 hans/rest1
docker run -d -p 6790:6789 hans/rest1*

Hans will jetzt einen Datenschatz ({"titel":"sa2"}) ueber die restApi beim Endpunkt /buch einfuegen Skizzieren Sie das Datenpaket:
| Inet | tcp |Http | Daten |
| -------- | -------- | -------- | --- |
| 4.5.6.7 | 4569  | Rest1.b11b.de | {"titel":"sa2"} |
|4.5.6.8|6789|POST /buch| |
|||Content-type:application/json|

Mit welchem http-Befehl sollte nach dem Rest-Prinzip eine Ressource geaendert werden?
*PUT*

Eerklaeren SIe die Bestandteile einer Url:
*Protokoll: http, ws, imap (optional mit tls)
Server/Domain/ServerIp
UrlPfad
optional user/passwd*
http://user:passwd@server/pfad

Warum darf ein Javascript in der Webseite http://engel.net nciht mit Rest-Befehlen auf http://engel.rest/kfz zugreifen?
*SOP:Javascript darf nur auf Resourcen zugreifen die vom gleichen Server wie die Webseite kommen, ausserdem muessen beide das gleiche Protokoll verwenden http oder https*


# Webserver
## Ablauf
1. Der Client gibt im Browser http://www.schule.de/info/klasse.html ein => ein GET Request wird an den Server gesendet
2. Der http-Server holt aus dem DocumentRoot die Datei info/klassen.html und
3. sendet deren Inhalt an den Browser . Der rendert und stellt das htm huebsch dar.

| Internet H | Transportschicht H | http Header | Daten |
| -------- | -------- | -------- | --- |
| 3.3.3.3 | >1023 | www.schule.de |  |
|4.4.4.4|80|GET /info/klasse.html|


## Begriffe
### Url 
Aufbau protokoll://dnsName/Urlpfad
- protokoll: http, ftp, https
- dnsName des Servers (steht im http-Header)
- Urlpfad: Pfad zur gewuenschten Datei im Documentroot

### DocumentRoot
Verzeichnis in dem der Webserver die Datei des Urlpfades sucht

## Virual Host (vHost)
Ein Server mit 1 offiziellen iP und vielen dns-Namen, kann pro dns-Name einen virtuellen Host einrichten. Dies ist die Zuordnung DNS-Name => DocumentRoot. D.h. je nach dns-Name werden die html-Name werden die html-Dateien aus einem anderen DocumentRoot geholt. Bzw. je nach dns-Name sieht der Client einen anderen Webserver.

| Internet H | Transportschicht H | http Header | Daten |
| -------- | -------- | -------- | --- |
| 3.3.3.3 | >1023 | www.schule.de |  |
|4.4.4.4|80|POST /save.php|
|||Content-type: application/json|

| Internet H | Transportschicht H | http Header | Daten |
| -------- | -------- | -------- | --- |
| 3.3.3.3 | 80 | Content-type: application/json | "{'status':'ok'}" |
|4.4.4.4| >1023||

## Reverse Proxy
- beliebige Programme, die ueber das http-Protokoll ansprechbar sind ueber https erreichbar machen
- die Progs funktionieren meist nach dem Rest-prinzip
- die Progs sind ueber 127.0.0.1:???? erreichbar
- sinnvoll: Wildcard-Dns: z.B. ?.x.dvs.de zeigt auf die IP 1.2.3.4
- pro Prog wird ein dnsname zu dessen Port weitergeleitet
- statt dem root-Eintrag: proxy-Direktiven

# Rest
kein Protokoll, sondern ein Prinzip: Eine Resource wird durch eine Url dargestellt. Durch einen Endpunkt wird eine Resource angesprochen: https://server/Endpunkt

## Datenpakete
![image](https://hackmd.io/_uploads/HyJ-euMZR.png)


# Auth Webanwendungen
## Token
**Bearer-Token** = Inhaber - Token => der Inhaber des Tokens - auch ein Dieb - ist authentifiziert. Entweder enthaelt der Token keine weiteren Infor oder es wird ein JWT verwendet
**JWT** Json Web Token. Dieser enthaelt - vom Server signierte - Infos (Name, Gruppe, Gewicht, ...)
**Hardware Token**: smardcard, fido2 usb-stick, PIN-Generator

![image](https://hackmd.io/_uploads/r14a-ufWC.png)

![image](https://hackmd.io/_uploads/ByRTW_MWA.png)


![image](https://hackmd.io/_uploads/HkyyzOG-A.png)

**SAML:**
- SAML steht für Security Assertion Markup Language.
- Es ist ein XML-basiertes Protokoll.
- Ermöglicht sicheres Austauschen von Authentifizierungs- und Autorisierungsinformationen.
- Benutzer können sich einmal anmelden und ihre Identität sicher mit anderen Websites oder Diensten teilen.

**oauth2:**
- OAuth 2.0 ist ein Autorisierungsprotokoll.
- Es ermöglicht Benutzern, Drittanwendungen Zugriff auf ihre geschützten Ressourcen zu gewähren.
- Benutzer müssen ihre Anmeldeinformationen nicht direkt an die Drittanwendung weitergeben.
- OAuth 2.0 bietet einen sicheren und standardisierten Weg für die Autorisierung und den Zugriff auf Ressourcen über das Web.
![image](https://hackmd.io/_uploads/rkDyMOGbA.png)
**oidc:**
- OpenID Connect (OIDC) ist eine Authentifizierungs-Protokoll.
- Es baut auf OAuth 2.0 auf und erweitert es um Identitätsinformationen.
- OIDC ermöglicht es Benutzern, sich sicher bei verschiedenen Diensten anzumelden, ohne bei jedem Dienst separate Anmeldeinformationen verwenden zu müssen.
- Es ermöglicht auch die sichere Übertragung von Benutzeridentitätsinformationen zwischen verschiedenen Anwendungen und Diensten im Internet.