Migration RP-PEP zu STS

Zukünftig wird die eIAM Leistung 11: Reverse Proxy Policy Enforcement Point (RP-PEP) nur noch für spezielle Anforderungen angeboten. Siehe Beschreibung
Einsatz von Reverse Proxy

Bestehende Fachapplikationen mit RP-PEP, welche diese Anforderungen nicht erfüllen, sollten auf eine Standard Implementierung (STS) migriert werden, wodurch die Komplexität im laufenden Betrieb, wie auch die laufenden Kosten für den eIAM Kunden reduziert werden können (Eliminierung externer Komponenten mit erhöhter Automation).

Wurde meine Applikation mit einem vorgeschaltetem Reverse Proxy implementiert?

Wenn Ihre Applikationen mit dem Material «eIAM-STD-RP-PEP» verrechnet wird, wurde sie mit einem Reverse Proxy implementiert. Falls noch das Material «eIAM-No-RP-PEP» verrechnet wird, dann im MLR-Kundeninventar prüfen ob hinter dem Applikationsnamen der Ausdruck «STD-RP-PEP» im Feld Referenz steht. Diese Anwendungen wurden gemäss eIAM-Preismodell 2022 für die Verrechnung noch nicht umgestellt.

Sollten Sie bei Ihrer Einschätzung unsicher sein, wenden Sie sich bitte an das eIAM Integrations-Team: eIAM-Integrations@bit.admin.ch

Kommerzielle Informationen

Wieso sind «STD-RP-PEP» - Applikationen teurer? ▼
×

  • Wird für Integrationen an eIAM ein «STD-RP-PEP» bereitgestellt, dann verursacht dies höheren Aufwand für den Service. Dies betrifft nicht nur Ressourcen wie Memory, CPU und Disk-Space, sondern auch der Konfigurations- und Pflegeaufwand im Life-Cycle.
  • Gemäss dem eIAM-Preismodell 2022 kommt für Applikationen welche ab dem 1. Januar 2022 integriert wurden der höhere Preis sofort zur Anwendung (Material eIAM-STD-RP-PEP).
  • Für Anwendungen, welche vor dem 1.Januar 2022 integriert wurden wird der höhere Preis erst auf den 1. Januar 2024 zur Anwendung kommen. Auf diesen Zeitpunkt wird das Material in der Verrechnung von eIAM-No-RP-PEP auf eIAM-STD-RP-PEP umgestellt.

Wie und wann wurde das neue eIAM-Preismodell kommuniziert? ▼
×

  • An den LV-Planungsveranstaltungen im Herbst 2020 und Herbst 2021 wurde allen Beteiligten (Kunden, IMs, AMs, SLM, etc.) das eIAM-Preismodell 2022 vorgestellt.
  • Ebenso wurde kommuniziert, dass für bestehende Applikationen mit einem STD-RP-PEP eine Übergansfrist von 2 Jahren ab dem 1. Januar 2022 gilt.
  • Hierzu können auf Anfrage die FSD Sitzungsfolien, LV-Info Präsentationen und Mailverkehr der Geschäftsleitung bereitgestellt werden.

Vorgehen bei einer RP-PEP Migration zu STS

Auswirkungen auf Fachapplikation welche mit einem RP-PEP implementiert wurden ▼
×

Übersicht der Auswirkungen

Feature
RP-PEP             STS          
Bemerkung
public / private paths
✅
❌
Kann von der Applikation übernommen werden.
Auswertung von Zugriffen von BV- und Internet-Zugriff
✅
✅
Cookie-Management
✅
✅
PEP-Rollenprüfung auf mehrere Rollen
✅
❌
Die möglichen Rollenprüfungen müssen zusammen mit eIAM SIE bei der Migrationsplanung besprochen werden.
AuthLevel Step-Up über Pfade
✅
❌
Kann vom Kunden mit STS per QoA im AuthnRequest übernommen werden.
Error Rendering (403, 502, usw.)                       
✅
❌
Kann von der Applikation übernommen werden.
SSO-Realms
✅
✅
Gegenstand der Migrationsberatung

Wie muss ich eine RP-PEP Migration zu STS anstossen? ▼
×

Die Umstellung einer Applikation von RP-PEP zu STS erfolgt über einen Remedy Change-Request (CRQ) und auf Basis der applikatorischen Anpassungen, welche im bestehenden (oder neuen) eIAM-Dossier vom PL Kunden/Partner erfasst werden müssen.
Gehen Sie wie folgt vor:
  1. Eröffnung eines eIAM-CRQ "Kundenauftrag allgemein" durch den IM des Kunden (ca. 30-50 Stunden). Anleitung:
    Remedy CRQ eröffnen

  2. PL Kunde/Partner: Update eines bereits bestehenden eIAM-Dossier für die Standard eIAM-Implementierung (STS). Sollte kein eIAM-Dossier bestehen, muss für die Migration zwingend ein neues eröffnet werden.

Grobe Ablaufbeschreibung einer RP-PEP zu STS Migration
Ein individuelles Migrationsszenario wird für jede Kundenapplikation pro Remedy CRQ Anfrage auf der Basis der eIAM-Dossier Angaben erarbeitet.

Ablaufschritte gemäss der eIAM-Dossier Führung

  1. Erstellung neuer STS oder Verwendung bestehender
  2. Austausch Metadaten (wir erhalten SP Metadaten, sie erhalten IDP Metadaten)
  3. Konfiguration der eIAM Infrastruktur (Loadbalancer, DNS, Firewall u.a.)
  4. Deployment gemäss Customer-Change-Plan und in Absprache mit dem eIAM SIE (System Integration Engineer)
  5. Support nach Deployment (REF/ABN/PROD)
  6. Abbau der nicht mehr verwendeten eIAM Infrastruktur Komponenten
Im Rahmen der eIAM-Dossier Bearbeitung koordinieren der PL Kunde/Partner die notwendigen Infrastruktur Bereitstellung (Loadbalancer, DNS, Firewall u.a.) mit ihren Stakeholder für alle Instanzen (REF/ABN/PROD). Die notwendigen Informationen und Vorgehensschritte finden Sie im eIAM-Dossier. Der eIAM SIE, welcher Ihnen für die Migrationsarbeiten zugeteilt wird, unterstützt Sie dabei.

Was beachtet werden muss, wenn die Übernahme bestehender eIAM-Loadbalancer durch die Applikation geplant ist. ▼
×

Wir empfehlen Ihnen die Bestellung eigener Loadbalancer/WAF für DNS. Die Übernahme bestehender eIAM-Loadbalancer durch die Applikation birgt eine grosse Abhängigkeit zum Loadbalancer-Team des BIT im laufenden Betrieb und erschwert die Migrationsarbeiten.

Folgendes muss bei der Übernahmen berücksichtigt werden:

  • Loadbalancer-Server-Pool muss mit Applikations-IP und Port mutiert werden.
  • Hinweis für Applikationen, die über Pfade getrennt sind:
    • Hier muss ein Big Bang stattfinden, wenn der FQDN übernommen werden soll.
  • Prüfung eigenständige Loadbalancer oder Alias-Konfigurationen (bspw. ALV-APPL, CCSAP).