Portalanalyse Udfordringer ved iFrame integrationsformen i forbindelse med FOBS løsningen

Baggrund Der er blevet identificeret en række udfordringer med iFrame integrationsformen i relation til den fællesoffentlige brugerstyringsløsning (FOBS). Analyse i regi af taskforcen med henblik på at afdække løsningsmuligheder og opdatere integrationsmodellen.

Overblik

Forudsætninger i analysen FOBS er en selvstændig løsning, der både supporterer alm. web applikationer og portaler. FOBS opfatter portalerne som enhver anden service provider (ingen speciel opførsel). FOBS hostes på et andet domæne end portalerne. FOBS har egen brugergrænseflade ved login. Det bør tilstræbes, at iFrame integration på portaler kræver minimale ændringer af applikationerne. OBS: Virk oplever måske ikke alle de beskrevne udfordringer endnu, da deres BRS løsning er tættere koblet til portalen. På sigt får de samme udfordringer, når de overgår til FOBS.

Problem 1: Framing af IdP GUI

P1: Løsningsforslag Portalen sørger for, at ”hovedvinduet” altid kræver logon før en framet applikation. Fordele –Interaktionen med IdP’en ifm. logon sker for hovedvinduet og ikke i frames. –Ingen ændringer af applikationer nødvendige Ulemper –Portalen skal holde styr på, hvornår det er tid til at logge brugeren på. Portal kan måske ikke vide hvornår en app. har behov for login?! –Prematur login kan forekomme afhængigt af portaldesign. –Kan have betydning for portalens design, herunder hvordan offentlige og private sider organiseres, links mellem dem etc. De framede applikationer bør yderligere (som en ekstra precaution) sætte parameteren IsPassive på SAML authentication request. Så ville IdP’en aldrig vise en GUI. Dette forudsætter, at applikationen ved, at den er framet.

Problem 2: IdP timeout Antag at IdP’ens session med brugeren er timet ud, men at portalens egen session med brugeren er gyldig. Hvis brugeren nu åbner en ny framet applikation i portalen, der også kræver login, har vi igen mulighed for at få framet IdP’ens GUI!

P2: Løsningsforslag Løs det via time-out policy dvs. tving serviceudbyderne til at forny deres session hos IdP’en selvom brugeren er aktiv lokalt. Fordele –Problemet løses effektivt: IdP’en timer aldrig ud så længe brugeren er aktiv hos en service provider. Ulemper –Kræver mere af serviceudbyderne: skal kunne holde brugerens request ”i luften”, mens der sker et roundtrip hos IdP’en, og derefter ”resume” sidste request med parametre og det hele.

Problem 3: Aktivering af single logout Normalt skal hver applikation i den fællesoffentlige føderation i sin brugergrænseflade have en mekanisme (knap / link) til aktivering af single logout. Det vil være uhensigtsmæssigt, hvis alle framede applikationer i en portal har egne knapper til SLO. Dels vil det give duplikering og dels vil det forvirre, hvis en log-ud knap i en frame logger brugeren ud af det hele.

P3: Løsningsforslag En applikation får at vide af portalen, når den er framet og undlader i givet fald at vise en knap / link til single logout. F.eks. via en parameter som medsendes i query string. Portalen viser en fælles single-logout side (og kvittering bagefter) Fordele: –Løser problemet samt issue om kvittering for SLO i en frame. Ulemper: –Applikationen skal opføre sig forskelligt afhængigt af, om den er framet eller ej. Det vurderes dog som værende simpelt at aktivere / deaktivere en knap baseret på en parameter.

Problem 4: Blokering af cookies Af hensyn privacy blokerer nogle browsere / anti-spyware løsninger for cookies til framede applikationer (third party cookies). Mange applikationer anvender cookies til at holde sessioner med brugeren. FOBS løsningen kræver, at serviceudbydere anvender en ”common domain cookie” til at opdage brugerens Identity Provider.

P4: Løsningsforslag Sørg for at cookies ikke blokeres ved at tilfredsstille browsernes privacy krav (P3P). Fordele –Applikationer skal ikke ændres. –Løser problemet for common domain cookie. –Pænere opførsel, at sites opfører sig ”privacy-aware” –Bedre DS-484 compliance?! Ulemper –Serviceudbydere skal beslutte, hvilken privacy policy de vil have, og hvordan de sikrer, at den overholdes (inkl. organisatoriske implikationer). –Ekstra arbejde med at konfigurere deres web server (formentlig minimalt).

Anbefalinger til nye krav i OIM’en Portaler skal sørge for, at ”hovedvinduet” altid kræver logon, før en framet applikation får brug for login. Applikationer får at vide, om de er framede. Framede applikationer bør sætte ”IsPassive” attributen på SAML authentication requests. Serviceudbyderne (inkl. portaler ) skal forny deres session via IdP’en selvom brugeren er aktiv lokalt. Obligatorisk for portaler og anbefalet for øvrige. En framet applikation bør undlade at vise en knap / link til single logout. Portalen viser en fælles single-logout side (og kvittering bagefter). Service Providere, der anvender iFrame integrationsformen, skal sørge for at cookies ikke blokeres ved at tilfredsstille browsernes privacy krav via P3P.

Mere om P3P