Parameteroverførsel i OIM
14
Parameteroverførsel i OIM Mellem portal og serviceprovider
description
Parameteroverførsel i OIM. Mellem portal og serviceprovider. Formål. Hvordan overføres parametre teknisk mellem portal og serviceprovider for Link og iFrame? Krav til serviceprovider for at kunne modtage parametre? Krav til portal for at kunne afsende parametre? - PowerPoint PPT Presentation
Transcript of Parameteroverførsel i OIM
Parameteroverførsel i OIM
Mellem portal og serviceprovider
Formål
• Hvordan overføres parametre teknisk mellem portal og serviceprovider for Link og iFrame?
• Krav til serviceprovider for at kunne modtage parametre?
• Krav til portal for at kunne afsende parametre?• Begrænsninger (f.eks. i fht. størrelsen på og antallet
af – parametre)?• På hvilke områder det ikke er muligt at
standardisere?• Hvad skal der indføjes i OIM?• Om muligt afklare et kernesæt af parametre der skal
stilles til rådighed for en serviceprovider fra en portal.
Løsning 1: HTTP GET med QueryString
App. A
App. B
App. A UI
Velkommen til portalen X
Browser Vindue A
GET http://spa.dk?p1=v1&p2=v2
HTML App. A
GET http://spb.dk?p3=v3&p4=v4
HTML App. B
Link
Browser Vindue B
Velkommen til App. B
XHT
ML
porta
lside
Hent
por
talsi
de
Løsning 1: Fordele, ulemper og krav
• Fordele:– Ukompliceret og anvender standard HTML
• Ulemper:– For link er parametre direkte synlige i browserens vindue og
kan dermed let manipuleres.– Parametre overføres via brugerens browser og er dermed
direkte læsbare.– Browsere har øvre grænse for længde af URL (2048 bytes
for IE)• Krav til serviceudbyder:
– Ingen ud over at kunne modtage almindelige GET parametre• Krav til portal:
– At kunne konfigureres til at medsende GET parametre på bestemte requests
Løsning 2: HTTP POST
App. A
App. B
App. A UI
Velkommen til portalen X
Browser Vindue A
POST http://spa.dk
HTML App. A
POST http://spb.dk
HTML App. B
Link
Browser Vindue B
Velkommen til App. B
XHT
ML
porta
lside
Hent
por
talsi
de
Javascript: når siden er læst, skriv form i iframe og POST den til serviceprovider
Javascript: når linket klikkes, POST skjult
form til serviceprovider
Løsning 2: Fordele, ulemper og krav
• Fordele:– Der er ingen øvre grænse på størrelsen af parametre.
• Ulemper:– Mekanismen er knapt så simpel at implementere som
almindelig GET.– Parametre overføres i begge scenarier via brugerens
browser og er dermed direkte læsbare.• Krav til serviceudbyder:
– Ingen ud over at kunne modtage almindelige POST parametre
• Krav til portal:– At kunne benytte Javascript til at medsende POST
parametre på bestemte requests
Løsning 3: HTTP GET med Fragment Identifier
App. A
App. A UI
Velkommen til portalen X
Browser Vindue A
GET http://spa.dk#par1=val1
HTML App. A
X
HTM
L po
rtalsi
de
Hent
por
talsi
de
Javascript: læser #-delen af URL’en for parametre og reagerer på dem.
Javascript: læser #-delen af URL’en for parametre og reagerer på dem.
Løsning 3: Fordele, ulemper og krav
• Fordele:– Kommunikation fra portal til serviceprovider og fra
serviceprovider til portal– Kommunikationen er ikke begrænset til initialisering, men
kan forekomme på vilkårlige tidspunkter.• Ulemper:
– Kompliceret (men kendt) Javascript.– Giver kun mening i iFrame integrationer.– Samme ulemper som HTTP GET med querystring.
• Krav til serviceudbyder og portal:– At skulle indlejre Javascript bibliotek til at læse og sætte
parametre– At skulle definere et sæt kommandoer til at kommunikere
med den anden part
Løsning 4: Back Channel
App. A
App. B
App. A UI
Velkommen til portalen X
Browser Vindue A
GET http://spa.dk?p1=ref1
HTML App. A
GET http://spb.dk?p2=ref2
HTML App. B
Link
Browser Vindue B
Velkommen til App. B
X
HTM
L po
rtalsi
de
Hent
por
talsi
deGET ref1
p1=v1,p2=v2
p3=v3,p4=v4
GET ref2
Løsning 4: Fordele, ulemper og krav
• Fordele:– Parametre sendes ikke via brugerens browser og bliver dermed
mindre sårbare– Der kan anvendes almindelig HTTP GET med querystring parametre
som reference• Ulemper:
– Serviceprovideren skal foretage et ekstra kald direkte til portalen.– Portalen skal udstille en service til at afhente parametre
• Krav til serviceudbyder:– At kunde kalde og fortolke (web) service på baggrund af modtaget
reference• Krav til portal:
– At stille (web) service til rådighed– At kunne konfigureres til at medsende reference til parametre på
bestemte requests – At holde sessionstilstand med parametre på vegne af reference +
rydde op
Konfidentialitet
App. A
App. B
App. A UI
Velkommen til portalen X
Browser Vindue A
GET http://spa.dk?Yfh2irfnf!
HTML App. A
GET http://spb.dk?Ifne4Jd7
HTML App. B
Link
Browser Vindue B
Velkommen til App. B
X
HTM
L po
rtals
ide
Hent
por
talsi
de
Kryperting af parametre
Dekryperting af parametre
Dekryperting af parametre
Kryptering: Fordele, ulemper og krav
• Fordele:– Parametre er ikke direkte læsbare og nøglen uhyre vanskelig at
knække• Ulemper:
– Der skal udveksles nøgler inden kommunikationen kan pågå– Parterne skal kunne håndtere kryptering og dekryptering med PKI.
• Krav til serviceudbyder:– At kunne dekryptere en URL med egen private nøgle
• Krav til portal:– At kunne modtage et certifikat til brug ved kryptering f.eks. ved
service registrering.– At kunne kryptere en URL med den offentlige nøgle i et certifikat.
• Relevans:– Ikke noget reelt behov. Benyt i stedet token fra SSO til videre opslag.
Standard parametre
• Løsningsspecifikke parametre• Fragment identifier kommandoer
– http://www.myndighed.dk#resize;width=192;height=200
Parameter Beskrivelse
Kilde Hvor kommer kaldet fra (Borger.dk, Virk.dk)
Integrationsform iFrame / Link
Myndighedsnummer Id på den i borger.dk valgte kommune
Anbefalinger
• Der ikke er behov for store datamængder og at parametre vil kunne rummes i en URL, hvorfor løsningsmodel 1 (GET med querystring) anbefales tilladt
• Der er behov for kommunikation begge veje og det anbefales derfor at løsningsmodel 3 (GET med fragment-identifier) tillades.
• Der ikke er behov for at sende følsom information og det derfor ikke er nødvendigt at kryptere parametre.
• Der er meget få kandidater til standardparametre, som det dog anbefales at standardisere.
