Download
1 / 14
140 likes | 248 Vues
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?
E N D
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: 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: 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: 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: 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
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
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.
