«GPW airport scenario» Exemple de participation à un testbed OGC

1. «GPW airport scenario» Exemple de participation à un testbed OGC

2. Call for Participation • Choix d’une thématique • Réponse à projet (en anglais) • Retours et suggestions OGC (répartition des tâches) • Acceptation et signature du contrat

3. Environnement de collaboration • Wiki : https://portal.opengeospatial.org/twiki/bin/view/OWS6/GpwAirportScenario • Conférences téléphoniques • hébergement des services chez sois (infrastructure distribuées)

4. GWP Airport Scenario

5. Incendie dans un Aéroport • Un incendie se déclare • Les pompiers interviennent • Ils doivent travailler au mieux malgré des restrictions d’accès aux données liées à des contraintes en matière de sécurité

6. 3 niveaux de sécurité • Local Authority domain • Airport Authority domain • Federal Level domain

7. Etape 1: intervention • Départ des pompiers sur zone • En chemin, accès aux données de la zone (WMTS) et aux données sur les habitations (WFS profil CityGML) • Les pompiers analysent les paramètres environnementaux, et constatent que le vent pousse la fumée vers les pistes

8. Etape 2 : Analyse in-situ • Les pompiers contactent le centre opérationnel et font part de leurs besoins en matière de données: • Informations détaillées sur les infrastructures de l’aéroport • Dernières données météorologiques disponibles • Imagerie Très Haute Résolution

9. Etape 3 : recherche de données • Le centre opérationnel recherche les informations dans leur catalogue de métadonnées, et constatent que: • AA -> Données détaillées sur les infrastructures • AA -> Données météo à jour • AA -> Modèle de dispersion atmosphérique • FL -> Données détaillées sur les infrastructures • FL -> raster THR

10. Etape 4 : récupération des données • Le centre opérationnel contacte AA et FL pour demander un accès direct aux données • Une authentification est nécessaire • AA accepte ensuite un accès à ses données • FL accepte pour les données Raster mais refuse de communiquer directement les informations sur les infrastructures • Ayant les accréditation suffisantes, AA peut servir d’intermédiaire (données infra)

11. Etape 5 : Filtrage spatial • AA met a disposition toutes les données dans un rayon de 200m autour du foyer • AA fournit seulement une partie des données situées dans un rayon de 500m du foyer • Après analyse des données communiquées, le Centre Opérationnel constate qu’une citerne d’hydrocarbures est présente dans la zone des 200m et demandent un raster THR de la zone à FL

12. AA : Après authentification Seules les couches et entités géographiques non sécurisées sont visibles Hors Zone : Rien n’est visible AA : Après authentification tout est visible Autorisation d’accès aux informations en fonction d’un périmètre donné

13. Mise en oeuvre des standards • L’architecture de sécurisation repose sur les standards OASIS (PEP, PDP, XACML, PIP etc. ...) • l’OGC souhaite enrichir le standard pour prendre en compte la dimension spatiale • GeoXACML sera substitué à XACML dans l’architecture OASIS

14. Architecture «RBAC» simplifiée

15. Architecture «LBAC» simplifiée

16. Comment structurer le SI ?

19. Conclusions • Pas assez de temps/ressources pour la sécurisation du WPS (calcul et exploitation du panache de fumée) • XACML 1.0 à montré ses limites lorsqu’il faut filtrer/masquer un résultat (clip du résultat d’un WMS à partir d’une couche WFS) • XACML 2.0 semble plus approprié car moins coûteux en terme de flux

20. Perspectives • Possibilité de standardiser les flux PEP/PDP pour un contexte OWS (profil OWS pour XACML) • Expérimenter la sécurisation des services WPS • Expérimenter la sécurisation de flux pour les infrastructures SWE

21. Questions ?