# OpusR-Client — Security Model

## Übersicht

Der OpusR-Client ist für den Einsatz in hochsicheren z/OS-Umgebungen
(Banken, Versicherungen, Behörden) konzipiert. Sicherheit hat absolute
Priorität über Komfort.

## Authentifizierung

### Phase 1: Basic Auth über HTTPS
- User gibt RACF User/Password ein
- Credentials werden per TLS verschlüsselt an DDF geschickt
- Password wird nur im Speicher gehalten (SecretString mit Zeroize)
- Bei Programmende wird der Speicher überschrieben

### Phase 2: RACF PassTickets
1. Einmal-Login: User/Password → Login-Service auf z/OS
2. Login-Service prüft gegen RACF (ICHRIX02 / RACROUTE VERIFY)
3. Bei Erfolg: PassTicket generieren (IRRSGS00)
4. PassTicket zurück an Client (8 Byte, 10 min TTL)
5. Alle weiteren REST-Calls nutzen PassTicket statt Password
6. Refresh vor Ablauf (9 min Intervall)

### PassTicket Eigenschaften
- 8 Byte, kryptographisch generiert
- Gebunden an Applikationsname (PTKTDATA-Profil in RACF)
- Einmalig verwendbar (Replay-Schutz)
- 10 Minuten gültig
- Kein echtes Passwort verlässt nach dem Login den Client

## Transport
- TLS 1.2+ mandatory (DDF SECPORT)
- Zertifikatvalidierung standardmäßig aktiv
- `--danger-accept-invalid-certs` nur für Entwicklung
- Kundeninstallation: echtes Zertifikat im RACF Keyring

## Credential-Handling im Code
- `secrecy::SecretString` für Passwords und PassTickets
- Automatisches Zeroize bei Drop
- Debug-Output zeigt "[REDACTED]"
- Kein Logging von Credentials (auch nicht bei Fehlern)
- Kein Speichern auf Disk (kein Config-File mit Passwords)

## RACF-Voraussetzungen beim Kunden
1. DDF aktiv mit SECPORT (SSL)
2. RACF PTKTDATA-Profil für opusR-Applikation
3. User braucht EXECUTE auf das REST-Service-Package
4. Optional: Client-Zertifikat im RACF Keyring