Migration RP-PEP vers STS

A l'avenir, la prestation eIAM 11 : Reverse Proxy Policy Enforcement Point (RP-PEP) ne sera plus proposée que pour des besoins spécifiques. Voir la description
Utilisation de Reverse Proxy
.
Les applications spécialisées existantes avec RP-PEP qui ne répondent pas à ces exigences devraient être migrées vers une implémentation standard (STS), ce qui permet de réduire la complexité dans l'exploitation courante, ainsi que les coûts courants pour le client eIAM (élimination de composants externes avec une automatisation accrue).

Mon application a-t-elle été implémentée avec un reverse proxy en amont ?

Si votre application est facturée avec l'article "eIAM-STD-RP-PEP", elle a été implémentée avec un reverse proxy. Si le matériel "eIAM-No-RP-PEP" est encore facturé, vérifiez dans l'inventaire des clients MLR si l'expression "STD-RP-PEP" figure derrière le nom de l'application dans le champ Référence. Ces applications n'ont pas encore été modifiées pour la facturation selon le modèle de prix eIAM 2022.

Si vous n'êtes pas sûr de votre estimation, veuillez contacter l'équipe d'intégration eIAM : eIAM-Integrations@bit.admin.ch

Informations commerciales

Pourquoi les applications "STD-RP-PEP" sont-elles plus chères ? ▼
×

  • Si un "STD-RP-PEP" est mis à disposition pour des intégrations à eIAM, cela entraîne des dépenses plus élevées pour le service. Cela ne concerne pas seulement les ressources telles que la mémoire, le CPU et l'espace disque, mais aussi les frais de configuration et de maintenance dans le cycle de vie.
  • Selon le modèle de prix eIAM 2022, le prix le plus élevé s'applique immédiatement aux applications intégrées à partir du 1er janvier 2022 (matériel eIAM-STD-RP-PEP).
  • Pour les applications intégrées avant le 1er janvier 2022, le prix plus élevé ne sera appliqué qu'à partir du 1er janvier 2024. A cette date, le matériel passera de eIAM-No-RP-PEP à eIAM-STD-RP-PEP dans la facturation.

Comment et quand le nouveau modèle de tarification eIAM a-t-il été communiqué ? ▼
×

  • Le modèle de prix eIAM 2022 a été présenté à tous les participants (clients, GI, AM, SLM, etc.) lors des réunions de planification de la MD en automne 2020 et en automne 2021.
  • De même, il a été communiqué que pour les applications existantes avec un PEP STD-RP, un délai de transition de 2 ans s'applique à partir du 1er janvier 2022.
  • A cet égard, les transparents des réunions de la FSD, les présentations LV-Info et les échanges de mails de la direction peuvent être mis à disposition sur demande.

Procédure pour une migration RP-PEP vers STS

Effets sur les applications spécialisées qui ont été implémentées avec un RP-PEP ▼
×

Aperçu des conséquences

Fonctionnalité
RP-PEP             STS          
Remarque
public / private paths
✅
❌
Peut être repris par l'application.
Analyse des accès de BV et d'Internet
✅
✅
Gestion des cookies
✅
✅
Contrôle des rôles PEP sur plusieurs rôles
✅
❌
Les contrôles de rôles possibles doivent être discutés avec eIAM SIE lors de la planification de la migration.
AuthLevel Step-Up via des chemins
✅
❌
Peut être repris par le client avec STS par QoA dans AuthnRequest.
Error Rendering (403, 502, etc.)                       
✅
❌
Peut être repris par l'application.
SSO-Realms
✅
✅
Objet de la consultation de migration

Comment dois-je déclencher une migration RP-PEP vers STS ? ▼
×

Le passage d'une application de RP-PEP à STS se fait par le biais d'une Remedy Change-Request (CRQ) et sur la base des adaptations applicatives qui doivent être saisies dans le dossier eIAM existant (ou nouveau) par le PL client/partenaire.
Procéder comme suit :
  1. Ouverture d'un CRQ eIAM "Commande client en général" par le IM du client (environ 30-50 heures). Instructions :
    Ouverture d'une CRQ Remedy

  2. PL Client/Partenaire : mise à jour d'un dossier eIAM existant pour l'implémentation eIAM standard (STS). S'il n'existe pas de dossier eIAM, un nouveau dossier doit impérativement être ouvert pour la migration.

Description sommaire du déroulement d'une migration RP-PEP vers STS.
Un scénario de migration individuel est élaboré pour chaque application client par demande Remedy CRQ sur la base des indications du dossier eIAM.

Étapes du processus selon la gestion du dossier eIAM

  1. création de nouvelles STS ou utilisation des STS existantes.
  2. échange de métadonnées (nous recevons des métadonnées SP, ils reçoivent des métadonnées IDP)
  3. Configuration de l'infrastructure eIAM (Loadbalancer, DNS, pare-feu, etc.)
  4. déploiement selon Customer-Change-Plan et en accord avec le SIE eIAM (System Integration Engineer)
  5. Support après le déploiement (REF/ABN/PROD)
  6. Démontage des composants d'infrastructure eIAM qui ne sont plus utilisés
.
Dans le cadre du traitement du dossier eIAM, le client/partenaire PL coordonne la mise à disposition de l'infrastructure nécessaire (Loadbalancer, DNS, pare-feu, etc.) avec ses parties prenantes pour toutes les instances (REF/ABN/PROD). Vous trouverez les informations nécessaires et les étapes de la procédure dans le dossier eIAM. L'eIAM SIE, qui vous est attribué pour les travaux de migration, vous soutient dans cette démarche.

A quoi il faut faire attention lorsqu'il est prévu de reprendre les loadbalancers d'eIAM existants par l'application. ▼
×

Nous vous recommandons de commander vos propres loadbalancers/WAF pour DNS. La reprise de loadbalancers eIAM existants par l'application implique une grande dépendance vis-à-vis de l'équipe de loadbalancers de l'OFIT en cours d'exploitation et complique les travaux de migration.

Les éléments suivants doivent être pris en compte lors de la reprise :

  • Le pool de serveurs loadbalancer doit être muté avec l'IP et le port de l'application.
  • Remarque pour les applications qui sont séparées par des chemins :
    • Un big bang doit avoir lieu ici si le FQDN doit être repris.
  • Contrôle des équilibreurs de charge autonomes ou des configurations d'alias (par ex. ALV-APPL, CCSAP).