Inhaltsverzeichnis

Hochverfügbarkeit

Beispiel-Setup der DFN-Geschäftsstelle

Es gibt viele Möglichkeiten, ein ausfallsicheres Setup aufzubauen. Dies als Beispiel dafür gedacht, wie man ohne Loadbalancer-Appliance, den IdP redundant aufsetzen kann.

Loadbalancer

Links zu HAProxy

Bei Fragen zu HAProxy konsultieren Sie bitte deren Dokumentation oder deren User Forum!

Dies ist ein beispielhafter Auszug aus /etc/haproxy/haproxy.cfg. Bitte denken Sie daran, dass der Loadbalancer im Abschnitt global eine sichere TLS-Konfiguration bekommt! Dabei hilft Ihnen z.B. der Mozilla SSL Configuration Generator.

frontend idp_frontchannel
    mode http
    option httplog
    bind <IPv4 Service-IP Ihres IdP>:80
    # Die key.pem-Datei muss ALLES enthalten: Private Key, Server-Zertifikat, Intermediate und Root-Zertifikat!
    bind <IPv4 Service-IP Ihres IdP>:443 ssl crt /etc/ssl/private/key.pem alpn h2,http/1.1
    bind <IPv6 Service-IP Ihres IdP>:80
    bind <IPv6 Service-IP Ihres IdP>:443 ssl crt /etc/ssl/private/key.pem alpn h2,http/1.1
    http-request deny if HTTP_1.0
    option forwardfor
    redirect scheme https if !{ ssl_fc }
    default_backend idp_frontchannel
 
# Bei Backchannel-Kommunikation wird teilweise ein Client-Zertifikat verwendet.
# Reichen Sie daher den Traffic einfach auf Layer 4 durch.
frontend idp_backchannel
    mode tcp
    option tcplog
    bind <IPv4-Adresse Ihres IdP>:8443
    bind <IPv6-Adresse Ihres IdP>:8443
    default_backend idp_backchannel
 
backend idp_frontchannel
    # Hier wählen Sie die Loadbalancing-Strategie:
    balance           roundrobin
    timeout check     10s
    # Hier präzisieren Sie, dass der Health Check ein HTTP-Check gegen die Statusseite sein soll:
    option httpchk  GET /idp/status HTTP/1.1\r\nHost:\ idp.beispiel-uni.de
    # Hier definieren Sie, wie das Cookie gesetzt wird:
    cookie BEISPIELUNI-IDP insert secure
    # Hier definieren Sie die realen Hosts, auf denen die IdPs laufen.
    # Jeder setzt ein Cookie mit dem Hostname.
    # Zu jedem wird der Traffic erneut verschlüsselt.
    # Die Health Checks erfolgen ohne DNS, direkt auf der Host-IP über TLS mit Server Name Indication. (Die ist wichtig, wenn auf den Real Servern mehr als eine Shibboleth-Instanz läuft und die separat geprüft werden sollen, z.B. Dev-Instanz und Produktiv-Instanz.)
    server idp1 <IPv4-Adresse 1. IdP-Host>:443 ssl sni str(idp.beispiel-uni.de) ca-file <das CA-File, mit dem verschlüsselt werden soll> cookie idp1 check check-ssl addr <IPv4-Adresse 1. IdP-Host> port 443 check-sni idp.beispiel-uni.de downinter 10s on-marked-down shutdown-sessions
    server idp2 <IPv4-Adresse 2. IdP-Host>:443 ssl sni str(idp.beispiel-uni.de) ca-file <das CA-File, mit dem verschlüsselt werden soll> cookie idp2 check check-ssl addr <IPv4-Adresse 2. IdP-Host> port 443 check-sni idp.beispiel-uni.de downinter 10s on-marked-down shutdown-sessions
 
backend idp_backchannel
    balance           roundrobin
    timeout check     10s
    # Legen Sie auf den IdPs eine Prüfdatei unter http(s)://idp.beispiel-uni.de/httpchk ab und schützen Sie sie ggf. gegen Zugriffe von außen.
    option httpchk /httpchk
    mode tcp
    server idp1 <IPv4-Adresse 1. IdP-Host>:8443 check addr <IPv4-Adresse 1. IdP-Host> port 80 downinter 10s on-marked-down shutdown-sessions
    server idp2 <IPv4-Adresse 2. IdP-Host>:8443 check addr <IPv4-Adresse 2. IdP-Host> port 80 downinter 10s on-marked-down shutdown-sessions

IdP-Hosts

Datenbank

In einem ersten Schritt könnten Sie einen Standalone Datenbank-Server hinter die beiden IdPs stellen. Um die Datenbank auch ausfallsicher zu machen, ist eine Möglichkeit ein Galera Cluster.