1 / 14

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?

barbie
Download Presentation

Parameteroverførsel i OIM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Parameteroverførsel i OIM Mellem portal og serviceprovider

  2. 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.

  3. Løsning 1: HTTP GET med QueryString

  4. 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

  5. Løsning 2: HTTP POST

  6. 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

  7. Løsning 3: HTTP GET med Fragment Identifier

  8. 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

  9. Løsning 4: Back Channel

  10. 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

  11. Konfidentialitet

  12. 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.

  13. Standard parametre • Løsningsspecifikke parametre • Fragment identifier kommandoer • http://www.myndighed.dk#resize;width=192;height=200

  14. 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.

More Related