Migration RP-PEP to STS

In future, eIAM service 11: Reverse Proxy Policy Enforcement Point (RP-PEP) will only be offered for special requirements. See description
Use of Reverse Proxy

Existing specialist applications with RP-PEP that do not fulfil these requirements should be migrated to a standard implementation (STS), which can reduce the complexity of ongoing operations and the ongoing costs for the eIAM customer (elimination of external components with increased automation).

Has my application been implemented with an upstream reverse proxy?

If your application is billed with the material "eIAM-STD-RP-PEP", it has been implemented with a reverse proxy. If the material "eIAM-No-RP-PEP" is still billed, then check in the MLR customer inventory whether the term "STD-RP-PEP" appears after the application name in the Reference field. These applications have not yet been converted for billing in accordance with the 2022 eIAM pricing model.

If you are unsure about your assessment, please contact the eIAM integration team: eIAM-Integrations@bit.admin.ch

Commercial information

Why are "STD-RP-PEP" applications more expensive? ▼
×

  • If an "STD-RP-PEP" is provided for integrations to eIAM, this causes higher costs for the service. This not only affects resources such as memory, CPU and disc space, but also the configuration and maintenance effort in the life cycle.
  • According to the eIAM pricing model 2022, the higher price will be applied immediately for applications integrated from 1 January 2022 (material eIAM-STD-RP-PEP).
  • For applications integrated before 1 January 2022, the higher price will not apply until 1 January 2024. On this date, the material will be converted from eIAM-No-RP-PEP to eIAM-STD-RP-PEP.

How and when was the new eIAM pricing model communicated? ▼
×

  • At the LV planning events in autumn 2020 and autumn 2021, the 2022 eIAM pricing model was presented to all stakeholders (customers, IMs, AMs, SLM, etc.).
  • It was also communicated that a transition period of 2 years from 1 January 2022 applies to existing applications with an STD-RP PEP.
  • On request, the FSD meeting slides, LV-Info presentations and mail correspondence from the management can be made available.

Procedure for RP-PEP migration to STS

Effects on specialised applications that were implemented with an RP-PEP ▼
×

Overview of the effects

Feature
RP-PEP             STS          
Remark
public / private paths
✅
❌
Can be adopted by the application.
Evaluation of access from BV and Internet access
✅
✅
Cookie management
✅
✅
PEP role check for multiple roles
✅
❌
The possible role checks must be discussed together with eIAM SIE during migration planning.
AuthLevel Step-Up via paths
✅
❌
Can be adopted by the customer with STS via QoA in the AuthnRequest.
Error rendering (403, 502, etc.)                       
✅
❌
Can be adopted by the application.
SSO-Realms
✅
✅
Subject of the migration consultation

How do I have to initiate an RP-PEP migration to STS? ▼
×

The migration of an application from RP-PEP to STS takes place via a Remedy Change Request (CRQ) and on the basis of the application-specific adjustments that must be entered in the existing (or new) eIAM-Dossier by the PL customer/partner.
Proceed as follows:
  1. Open an eIAM-CRQ "Customer order general" by the IM of the customer (approx. 30-50 hours). Instructions:
    Remedy CRQ Opening

  2. PL customer/partner: Update of an existing eIAM-Dossier for the standard eIAM implementation (STS). If no eIAM-Dossier exists, a new one must be opened for the migration.

Rough process description of an RP-PEP to STS migration
An individual migration scenario is developed for each customer application per Remedy CRQ request based on the eIAM-Dossier details.

Process steps according to the eIAM-Dossier management

  1. -Creation of new STS or use of existing ones
  2. Exchange metadata (we receive SP metadata, you receive IDP metadata)
  3. Configuration of the eIAM infrastructure (loadbalancer, DNS, firewall, etc.)
  4. Deployment according to Customer-Change-Plan and in consultation with the eIAM SIE (System Integration Engineer)
  5. Support after deployment (REF/ABN/PROD)
  6. Dismantling of eIAM infrastructure components that are no longer used
As part of the eIAM-Dossier processing, the PL customer/partner coordinates the necessary infrastructure provision (Loadbalancer, DNS, firewall, etc.) with their stakeholders for all instances (REF/ABN/PROD). The necessary information and procedure steps can be found in the eIAM-Dossier. The eIAM SIE, which is assigned to you for the migration work, will support you in this.

What needs to be considered if the application plans to take over existing eIAM loadbalancers. ▼
×

We recommend that you order your own loadbalancers/WAF for DNS. The takeover of existing eIAM loadbalancers by the application entails a high level of dependency on the BIT loadbalancer team during operation and makes migration work more difficult.

The following must be taken into account during the takeover:

  • Loadbalancer server pool must be mutated with application IP and port.
  • Note for applications that are separated by paths:
    • A big bang must take place here if the FQDN is to be adopted.
  • Check independent loadbalancers or alias configurations (e.g. ALV-APPL, CCSAP).