Prosessdokumentasjon. Rapporten består av flere kapitler. For å få en fullstendig forståelse bør rapporten leses fra start til slutt.

Transkript

1 Forord Denne rapporten tar for seg selve prosessen vi har vært igjennom i løpet av prosjektet. Dette dokumentet viser hvordan vi har arbeidet, hvilke utviklingsmetoder vi har brukt, rammebetingelsene til prosjektet, krav, utviklingsverktøy, utfordringer og problemer, samt beskrivelse av hvordan vi har løst disse. Rapporten er i hovedsak skrevet for oppdragsgiver, sensor og veileder. Rapporten består av flere kapitler. For å få en fullstendig forståelse bør rapporten leses fra start til slutt. Side 1

2 Innholdsfortegnelse 1. Innledning Om bedriften Dagens situasjon Mål Endringer Rammebetingelser Planlegging og metode Generelt Fremdriftsplan og arbeidsplan Retningslinjer Valg av utviklingsmetode Valg av teknologi OpenID SAML Security Assertion Markup Language OAuth Tilbakemeldinger Om utviklingsprosessen Fasene i prosjektet Forprosjektet Kompetansetilegning Programmeringen Utfordringer i prosjektgjennomføringen OAuth C#.NET RESTful API JSON - JavaScript Object Notation DotNetOpenAuth Unik identifisering av bruker Bruk av Scrum Kravspesifikasjon Generelt Endringer i kravspesifikasjonen Oppsummering/Konklusjon Oppsummering Hva kunne vært bedre? Ønsker for fremtiden Figurliste Kilder Side 2

3 1. Innledning I forprosjektet startet vi å planlegge hvordan vi skulle utføre hovedprosjektet. Vi satte opp mål og krav til løsningen i samråd med vår veileder hos Infront. Bedriften satte også noen ønsker til oss som at de anbefalte oss å bruke Microsoft- produkter for utvikling. I oppstartfasen leste vi oss opp på mulige sikkerhetsløsninger og kom fram til to mulige verktøy for å løse oppgaven vår. 1.1 Om bedriften Infront ble startet i 1998 og har flere kontorer i Oslo, København og Stockholm. De har over 80 ansatte og vokser seg stadig større. Infront tilbyr markedsdata, nyheter, analyser og spesialdata som dekker over 50 børser over hele verden alt via deres program, Infront Terminal og mobile applikasjoner. Infront Connect gjør det mulig at banker og meglerhus kan tilby sine kunder kostnadseffektiv elektronisk handel gjennom Infronts programvare. 1.2 Dagens situasjon Infront Terminal henter markedsdata og kobler seg, via Infront Connect, til bankens handelssystem. Kunden har to sett med brukernavn og passord; ett hos Infront og ett hos sin bank. Slik deres arkitektur er i dag må kundene logge inn to ganger - én gang med hvert sett av brukernavn og passord for å få tilgang til alle tjenester. Problemet de ønsket å løse i første omgang var implementasjon av single sign- on (SSO) for at kundene deres skulle slippe innlogging to ganger. Det viste seg etter hvert at de måtte endre på hele arkitekturen sin for å løse dette problemet. De hadde også i lengre tid ønsket seg en gratisutgave av mobilapplikasjonene deres med eksklusiv registrering via Facebook eller en annen tredjepart såkalte identitetstilbydere. Da det viste seg at en slik SSO- løsning ikke ville være mulig å utføre i denne omgang, ble fokuset endret til gratisregistrering med mobilapplikasjonene. 1.3 Mål Med dette prosjektet skal vi lage en Auth Server(autentiseringsserver) som en del av ny arkitektur hos Infront i sammenheng med mobilapplikasjonen som skal lanseres. Denne serveren skal kunne lagre samt hente ut tokens til brukere registrert på Facebook og kunne returnere info om brukeren til webserveren tilknyttet den nye applikasjonen slik at brukeren kan registreres (første gang) og deretter identifiseres og logges inn Endringer I første omgang var hovedformålet med oppgaven, enkelt formulert å lage en sikker SSO- løsning for Infront, slik at brukerne kunne logge inn kun én gang hos Infront og dermed autoriseres til å få tilgang til både markedsdata og bankens handelssystem på en sikker måte. Side 3

4 I uke 10 ble oppgaven omdefinert litt med tanke på hvordan dette skulle løses, der vi og veileder hos Infront ble enige om at vi skulle sette opp Auth Server som håndterer tokens og federation av brukere fra LinkedIn og Facebook med Infront sitt IAS (Infront Authentication Service). I uke 15 ble oppgaven igjen omdefinert med tanke på hva som skulle gjøres. Etter arbeidet vårt med de første målene kom vi fram til at om alt dette skulle implementeres hos Infront så måtte store deler av deres interne arkitektur endres, og store deler av bedriften måtte bli inkludert. Dette gjorde vi veilederen vår hos Infront oppmerksom på. Det ble tatt opp til diskusjon hos Infront, men de hadde ikke tid eller ressurser til å gjøre dette i denne omgang. Et annet hinder var at bankene har veldig strenge retningslinjer for sikkerhet. I korte trekk, betyr dette at bankene må stole på at Infront autentiserer deres brukere, og dette ville de naturligvis ikke gå med på uten å bli involvert i prosessen. Resultatet av dette er at de istedenfor påbegynte en mobilapplikasjon med en gratisversjon av noen av tjenestene de kan tilby. I denne løsningen skal brukeren autentiseres via Facebook/LinkedIn for både registrering og innlogging for å gjøre registreringen enklest mulig for sluttbruker. Resultatet av dette er at produktet vårt blir noe mindre enn først antatt, men det vi har laget på nåværende tidspunkt kan, med noen tilpasninger og utvidelser, brukes i denne løsningen. Dette kan også brukes som utgangspunkt hvis de i ettertid bestemmer seg for å endre arkitekturen og implementere en fullverdig SSO- løsning i alle ledd. 1.4 Rammebetingelser Oppdragsgiver ønsket at løsningen skulle være sikker og bruke med OAuth 2.0, SAML eller OpenID som teknologi for autentisering. Det var også et ønske fra Infront at løsningen skal være laget for Windows- plattformen og da være utviklet i C#.NET. 2. Planlegging og metode I dette kapittelet tar vi for oss planleggingen av prosjektet med tanke på styringsdokumenter, arbeidsmetoder og evalueringen av de ulike teknologiene som var aktuelle til vårt prosjekt. 2.1 Generelt Vi ble enige om sammensetning av gruppa veldig tidlig. Dette var veldig enkelt da alle sammen har kjent hverandre og samarbeidet tidligere - helt siden første semester på dataingeniørlinjen. Det at vi tidlig hadde fastslått gruppa gjorde at vi kunne bruke god tid til å finne oss en oppdragsgiver og en oppgave som passet vårt ønske. Gjennom bekjente fikk vi kontakt med Infront, som tidlig virket Side 4

5 interessante. Etter at vi fikk diskutert hva slags problem som skulle løses endte vi opp med de som oppdragsgiver. Vi visste tidlig at vi måtte gjøre mye research for å tilegne oss den nødvendige kunnskapen, spesielt rundt SAML-, OpenID- og OAuth 2.0- standardene, noe som også ble tilfelle. Dette førte til at det ble mye lesing, prøving og feiling i starten. 2.2 Fremdriftsplan og arbeidsplan Det at omfanget av hvor mye vi faktisk måtte sette oss inn i var delvis uklart, gjorde at vi valgte å ikke sette opp en fremdriftsplan i starten av prosjektet. Etter hvert som vi fikk bedre oversikt over hva som skulle gjøres, ble fremdriftsplan og arbeidsplan opprettet sammen med et overordet dokument som ble kalt "retningslinjer". Sistnevnte beskriver kort hva slags avtaler som er gjort innad i gruppa med tanke på forsentkomming, oppbygging av møter, ansvar for møtereferater og generelt ting som ikke var hensiktsmessig å ta med i arbeids- eller fremdriftsplan. 2.3 Retningslinjer Møter Et hovedmøte vil bli holdt mandag klokka hver uke for å diskutere og evaluere fremgang, og for å planlegge neste arbeidsuke. Arbeidsmøter vil bli holdt hver tirsdag og onsdag klokka for å jobbe sammen om prosjektet. I starten av møtene planlegger vi hva hver enkelt skal gjøre i løpet av dagen. På mandag skjer dette etter evalueringen, ellers i starten. Godkjenning Ved kommunikasjon med veileder(e) skal minimum én fra hver del av prosjektet godkjenne hva som skal skrives og sendes. Dette for å kvalitetskontrollere og for å unngå uklarheter. Om gruppemedlemmer er borte fra møtet skal det godkjennes via telefon eller Facebook. Referater Vi skriver hva vi har gjort i et felles dokument i form av en logg. Fravær 1. Obligatorisk oppmøte på alle planlagte møter. 2. Fravær er OK så lenge det meldes senest én time før møtet. Facebook og SMS er gyldige informasjonskanaler. 2.4 Valg av utviklingsmetode Vi bestemte oss på et tidlig stadium i prosjektperioden at vi ønsket oss en smidig utviklingsmetode, som betyr at vi jobber med å utvikle produktet vårt hele tiden i stedet for å lage en ny løsning og så forkaste den. Dette til tross for at kravene for oppgaven var definert, så hadde vi kun et vagt bilde av hvordan den ferdige Side 5

6 løsningen skulle se ut. Ved å bruke en smidig utviklingsmetode kunne vi ta høyde for om noe rundt oppgaven skulle endres. Scrum var noe vi alle i gruppa hadde tidligere erfaring med. I denne utviklingsmetoden defineres ulike mål for prosjektet og legges i en produktlogg. I hver sprint velger man ut mål herfra som legges i en sprintlogg i prioritert rekkefølge. Om det ikke er tilstrekkelig med tid til å løse alt blir det tatt med i neste sprint. Noen fordeler med Scrum som utviklingsmetode er at det er enklere å tilpasse endrede eksterne faktorer, samt mindre behov for oppfølging og styring. I tillegg kan kunde/oppdragsgiver involveres i stor grad i utviklingsprosessen. (SCRUM, 2013). Derfor falt valget vårt på Scrum med tilpasninger slik at det passer vårt prosjekt. 2.5 Valg av teknologi Etter møter og diskusjoner med veileder hos Infront kom vi frem til at det var tre teknologier som kunne benyttes: OpenID, SAML og OAuth 2.0. Side 6

7 2.5.1 OpenID En åpen standard som gjør det mulig for brukere og autentiseres av bestemte sider/tjenester ved hjelp av en tredjepartstjeneste. I praksis betyr dette av hvis du er registrert på hos en tjeneste som bruker OpenID, kan du logge inn på andre tjenester som bruker denne standarden uten å måtte registrere deg på nytt. Eksempler på kjente tjenester som bruker OpenID: Flickr, Google, Yahoo, MySpace og AOL. (OpenID, 2013). Figur 1: OpenID flyt Side 7

8 2.5.2 SAML Security Assertion Markup Language XML- basert åpent dataformat for å utveksle autentiserings- og autorisasjonsinformasjon mellom parter. Det generelle bruksmønsteret det er ment å løse er når brukeren ber om en tjeneste fra en tjenestetilbyder. Dette løses ved at tjenestetilbyderen forespør en identitetstilbyder om identiteten. Ut fra svaret som kommer tilbake kan tjenestetilbyderen utføre tilgangskontroll, altså tillate eller avslå at brukeren får tilgang. (SAML, 2013) Figur 2: SAML flyt Side 8

9 2.5.3 OAuth 2.0 Åpen standard for autorisasjon og autentisering som tilbyr en metode for klienter å aksessere servertjenester på vegne av en ressurseier. Figur 3: OAuth 2.0 flyt Etter å ha lest om teknologiene (OAuth 2.0, SAML, OpenID) bestemte vi oss sammen med veileder hos Infront for å bruke OAuth 2.0 i vår løsning. Dette fordi OAuth 2.0 er svært utbredt og det finnes mange eksempler og mye stoff på Internett. OpenID har ikke et omfattende nok spekter når dette er noe som blir brukt hovedsakelig til autentisering og ikke autorisasjon, mens OAuth 2.0 dekker begge. OpenID har som funksjon å kunne si, dette er meg mens OAuth 2.0 bruker tokener, og disse kan brukes videre til å autentisere seg med beskyttende ressurser. SAML er også tokenbasert, Men det finnes ingen open source biblioteker for SAML til.net og arbeidsgiver har foreløpig ingen planer om å bruke penger på et bibliotek. Vi vurderte å utvikle et selv, men konkluderte med at det ville bli en for omfattende oppgave for dette prosjektet. OAuth 2.0 har open source biblioteker som DotNetOpenAuth til C#.NET. Å bruke open source biblioteker gjør det mer sikkert når kildekoden er offentlig, og derfor også mange som bruker det som gjør at man lett kan finne eksempler og hjelp på Internett. OAuth 2.0 er veldig utbredt og støttes blant annet av store tilbydere som Yahoo, Google, LinkedIn, Facebook og Twitter. I tillegg foregår all kommunikasjon via SSL, noe som bidrar til å gjøre standarden robust og sikker. (OAuth 2.0, 2013) Side 9

10 2.6 Tilbakemeldinger Gruppa og veileder hos Infront har hatt god kontakt helt fra prosjektstart. Kommunikasjonen har foregått i form av e- postutveksling og møter på lokalet hos Infront. Ettersom oppdragsgiver ønsket oppfølging underveis, ble e- post kommunikasjonskanalen for dette. E- postutvekslingen var noe sporadisk, da disse ble sendt når vi hadde nådd et delmål eller hadde noe annet å melde. Møtene ble brukt til veiledning og når vi skulle vise hva vi hadde gjort. Da startfasen hadde hovedvekt på vurdering av teknologier, ble møtene brukt til veiledning. Senere i prosjektfasen har møtene blitt brukt til diskusjon rundt det å finne en sikker løsning og få praktisk veiledning av sikkerhetseksperten Andrew Gubanov hos Infront. 3. Om utviklingsprosessen I delkapitlene nedenfor tar vi for oss de forskjellige aspektene av utviklingen, og beskriver videre standarder vi bruker i prosjektet samt utfordringer i gjennomføringen. 3.1 Fasene i prosjektet Forprosjektet Før prosjektet hadde vi kontakt med veileder hos Infront på mail i tillegg til et møte for å få definert best mulig hva bedriftens ønsker med produktet var. Siden alle programmene deres fra før er Windows- basert, var det også ønskelig at prosjektet skulle utføres i C#.NET. Veilederen vår hos Infront kom også med tre forslag til standarder som kunne brukes for å utvikle SSO; OpenID, SAML og OAuth 2.0, hvor vi i samarbeid med bedriften endte på sistnevnte Kompetansetilegning To av gruppemedlemmene hadde kjennskap til utviklingsspråket C#.NET gjennom kurset Webapplikasjoner, men ingen på gruppen hadde erfaring med OAuth 2.0- standarden. Vi har derfor selv måtte ta ansvar for å lære oss det nødvendige av de nye teknologiene. Da våre kunnskaper rundt OAuth 2.0 var begrenset, fant vi det hensiktsmessig å finne et bibliotek for å hjelpe oss. Vi vurderte å utvikle et selv, men det ville blitt for omfattende, samt gitt en risiko for sikkerhetshull. Valget falt på DotNetOpenAuth, et nøye testet, godt dokumentert og gratis OAuth 2.0- bibliotek tilgjengelig for C#. OAuth 2.0 er åpen standard for autorisasjon som kan brukes til å løse forskjellige typer scenarioer. Dokumentasjonen er meget stor og kompleks, uten konkrete eksempler. Dette til tross for at OAuth 2.0 skal være en stor forenkling fra de foregående standardene, OAuth 1.0 og OAuth 1.0a. På grunn av dette har mye av Side 10

11 tiden på prosjektet foregått i form av å lære om OAuth 2.0 og hvordan vi skulle bruke det for å nå målene våre Programmeringen Etter hvert som vi fikk en viss teoretisk forståelse av OAuth 2.0, begynte vi programmeringen parallelt for å få litt mer praktisk forståelse. Det ble derfor satt opp et dummy- miljø med en egen side hvor du kunne logge inn via Google, som da hentet ut de første ti kontaktene fra kontaktboken til brukeren hos GMail. På den andre sprinten så ble det laget innlogging med LinkedIn og Facebook der det ble hentet ut ID og annen sentral informasjon om brukeren som ble lagret i en database. I denne sprinten ble det brukt XML for å hente ut informasjon fra LinkedIn og JSON fra Facebook. Mer om Scrum sprintene våre kommer under punkt 3.3. Etter hvert som prosjektet begynte å ta form valgte vi å innføre versjonskontroll i form av Git, i hovedsak som en sikkerhetsmekanisme. Siden dette var noe alle på gruppa hadde kjennskap til fra før, var det raskt å komme i gang med. 3.2 Utfordringer i prosjektgjennomføringen Det har gjennom hele prosjektet dukket opp flere utfordringer i form av nye teknologier og løsninger vi har måtte satt oss inn i med forskjellig omfang og betydning for sluttproduktet. I hovedsak OAuth 2.0 kombinert med Infront sin arkitektur. Vi har for eksempel brukt tid på å sette oss inn i teknologier som vi av forskjellige årsaker ikke bruker i sluttproduktet, selv om dette har gitt oss større forståelse og vi sitter igjen med mye kunnskap vi ikke hadde før vi startet. DotNetOpenAuth- bibloteket er et eksempel på dette. Biblioteket som vi brukte i starten ved oppsett av et dummymiljø, men senere viste det seg at det ikke er lagd for de spesifikke flows vi trenger for å løse prosjektet, noe som førte til at i måtte utvikle kode for disse selv OAuth 2.0 Åpen standard for autorisasjon og autentisering som tilbyr en metode for klienter å aksessere servertjenester på vegne av en ressurseier. Utfordringen med OAuth 2.0 gjennom hele prosjektet har vært den store og tunge dokumentasjonen som ikke gir mange konkrete svar hvordan forskjellige aspekter av løsningen skal programmeres eller implementeres. Det finnes for øvrig mange eksempler ute på nettet, men få eller ingen har valgt å bruke OAuth 2.0 på samme måte som oss i prosjektet. Etter flere møter med veileder og sikkerhetsekspert hos Infront kom vi fram til en løsning med server- til- server kommunikasjon for utveksling og henting av tokens. Når det er klient- til- server kommunikasjon skal dette foregå i sikre kanaler med enten SSL eller TLS. (Se punkt 2.5). (D. Hardt, 2012) Side 11

12 3.2.2 C#.NET Oppdragsgivers løsning er på.net plattformen og ville derfor at vi skulle løse oppgaven med.net. To av gruppemedlemmene har hatt et valgfag som baserte deg på.net og hjalp resten av gruppen for å sette seg dypere inn i.net- rammeverket og biblioteker som skulle brukes RESTful API REST Representational State Transfer. Målet med å bruke REST er å gjøre APIet skalerbart, generelt, selvstendig, sikkert og minske latency. REST er en måte å bruke HTTP- protokollen på for å få informasjon. REST er ingen formell standard, mer en stil eller måte å spørre om informasjon om. Vi vurderte SOAP og REST opp mot hverandre. Vi kunne brukt begge, men SOAP er mer komplekst enn REST. Samtidig tilfredsstilte REST alle våre krav, og vi valgte derfor å bruke REST i prosjektet. Dette var også anbefalt av Christoffer Möllenhoff hos Infront, utvikler og ansvarlig for Mobile Web Service servicen som skulle bli klienten mot vår Auth Server - da han allerede hadde tatt utgangspunkt i å bruke REST- kall. For at et API skal være RESTful er det seks restriksjoner som må være oppfylt: Klient- server Et uniformt interface som separerer klientene fra serverene. Denne separasjonen gjør at klientene ikke skal tenkte på lagring av data eller hvor dette skjer. Serverene skal ikke tenke på klientens state eller grensesnitt mot brukeren, slik at de kan være enklere og mer skalerbare. Stateless (tilstandsløs) Serveren skal ikke lagre noe informasjon om klienten mellom forespørsler. Hver forespørsel fra en klient skal inneholde all nødvendig informasjon som skal til for at serveren skal kunne utføre forespørselen i sin helhet. Og alle session states holdes på klienten. Cacheable Klienter skal kunne mellomlagre svar. Layered system En klient skal ikke kunne vite om den er tilkoblet direkte til sluttserveren, hva slags steg den er i, eller hvor noe skjer. Code on demand (valgfritt) Serveren kan i midlertid utvide funksjonaliteten til en klient, som for eksempel ta imot JavaScript. Uniform interface Det uniforme grensesnittet mellom klient og server skal være i selvforklarende meldinger og hver ressurs er unikt adresserbare. For at et API skal være RESTful må alle disse være oppfylt, foruten om Code on demand som er valgfri. På grunn av at OAuth 2.0 ikke er stateless, kan vi ikke Side 12

13 kalle vårt API RESTfull, men RESTlike ettersom det oppfyller alle andre krav. (REST, 2013) JSON - JavaScript Object Notation JSON er et lettvekts, tekstbasert språkuavhengig format for datautveksling. Vi kunne også benyttet XML til dette, men Christoffer Möllenhoff anbefalte oss å bruke JSON fordi dette er enklere for oss og fordi det sparte han for ekstra arbeid, da han allerede hadde tatt utgangspunkt i å bruke JSON. (D. Crockford, 2006) DotNetOpenAuth Dette biblioteket er utviklet for C# og inneholder de aller fleste metodene for bruk av autorisasjon og autentisering mot tredjepartsservere. Biblioteket er open source og det ligger god dokumentasjon ute på deres nettside. (DotNetOpenAuth, 2013) Vi brukte dette biblioteket for eksempel ved oppsett av dummy- sider ved henting av kontaktboken til en bruker ved innlogging på Google. Vi endte med å ikke bruke dette biblioteket i sluttproduktet på grunn av at det ikke inneholder de spesifikke flytene vi trenger. DotNetOpenAuth- biblioteket blir brukt til både klient- til- server- og server- til- server- kommunikasjon, men bare når serveren er en nettside som brukes direkte av en klient ikke en intern server som i vårt tilfelle. Dette førte til at vi måtte utvikle en løsning fra bunnen av for denne autentiseringen. Vi har tidligere nevnt at det kan utgjøre en sikkerhetsrisiko i å utvikle disse metodene selv, men dette er løst med å whiteliste IPer som kan kommunisere til vår Auth Server. Andre sikkerhetsrisikoer som pakkesniffing og session hijacking vil ikke være nødvendig å ta hensyn til på grunn av at det ikke skjer i en brukers nettleser, men i et back- end- system. Her ligger risikoen i så fall ved et datainnbrudd hos Infront Unik identifisering av bruker Løsningen vår skal kunne identifisere en bruker ved en unik verdi som skal lagres. Ettersom man skal kunne registrere seg med forskjellige tredjeparter som LinkedIn eller Facebook, gjør dette at vi ikke kan hente ut en unik verdi med token fordi disse vil være forskjellige avhengig av hvor man kommer fra. IDen må kunne identifisere brukeren og hvor den kommer fra. Det løses ved å kombinere tilbyders (Facebook og Linkedin) ID som vi har definert sammen med Infront og hver enkelt brukers unike ID hos sin tilbyder. Side 13

14 3.3 Bruk av Scrum Prosjektgruppen gjennomførte hovedmøter, hver mandag slik at alle fikk en oversikt over hvordan det gikk med de forskjellige arbeidsmålene. Dette ga samtidig gruppemedlemmene en mulighet til å ta opp diverse problemer og utfordringer som krevde en samlet avgjørelse. De andre dagene kjørte vi litt kortere møter på ca. 15 min, sånn at vi ikke brukte for mye tid på dette. På disse møtene gikk vi igjennom disse spørsmålene: Hva var gjort siden forrige møte? Hva skulle gjøres i dag? Har det oppstått noen problemer? Sprintplanleggingsmøtene hadde litt lenger varighet på grunn av at det måtte planlegges mer nøye. Her gikk vi igjennom følgene spørsmål: Bestemme hva som skal gjøres i sprinten Forberede sprintloggen ved å sette opp et tidsestimat på oppgavene Finne ut hvor mye jobb det er realistisk å få gjort i løpet av sprinten Etter hver sprint hadde vi et møte der vi gikk igjennom hva som har blitt gjort og hvordan vi følte at det gikk. For å holde styr på dette og få en mer visuell oppfatning av bruken, valgte vi å sette opp et skjema på Scrumy.com. Det er et verktøy som gir god visuell forståelse av faser, sprinter og tildeling av oppgave. Under kan man se hvordan dette ser ut. Her står følgende: Sprintens tittel, sprintens varighet og oppgavene hver enkelt person skal utføre. Side 14

15 Figur 4: Skjermdump fra Scrumy.com/Hovedprosjektsso 26/5-13 Figur 5: Skjermdump fra Scrumy 26/5 Sprinter Sprint 1 - Denne sprinten gikk hovedsaklig ut på kompetansetilegning rundt OAuth 2.0, både for å få større innblikk i hele standarden, og for å få et klarere bilde av hvordan løsningen skulle programmeres. Vi satte den sprinten til 30 dager for å kunne vite i størst mulig detalj hvordan vi skulle løse prosjektet. Derfor valgte vi også å sette opp et dummy- system som hentet ut et utvalg av kontakter fra en Google Mail- konto. Sprint 2 - Sette opp et dummy- miljø med utgangspunkt i eksemplet fra forrige sprint og startet å utvikle for å hente ut informasjon fra tredjeparts autorisasjonsservere (Facebook og LinkedIn). Vi hentet ut for eksempel den unike IDen til brukeren hos de respektive autorisasjonsserverne og sentral informasjon om brukeren. Vi satte tiden til en 20 dagers sprint og klarte å nå målene våres innen tidsfristen. Ved siden av programmeringen ble det satt i gang dokumentasjon for å legge til alle endringene som har skjedd i denne fasen av prosjektet. Mot slutten av denne sprinten hadde vi fått et godt bilde av OAuth 2.0 og var derfor hyppigere i kontakt med Infront. Side 15

16 Sprint 3 Endrede krav. Etter møter med utviklingsteamet til Infront fant vi i samarbeid ut at den tenkte oppgaven ble for omfattende for dem å integrere i sitt system på daværende tidspunkt, da dette ville innebære en endring i store deler av arkitekturen deres. Istedenfor så de at det vi hadde produsert kunne brukes som utgangspunkt til en autentiseringsserver til den mobile plattformen de hadde startet planleggingen av. Resultatet ble at vi ble en del av dette utviklingsteamet. Sprint 4 - Programmere løsning hos Infront. I løpet av denne perioden var vi mye inkludert i sprintmøter hos Infront og hadde mye kontakt med de andre utviklerne deres slik at vi spesifisert i størst mulig grad det de forventet av løsningen vår. Her har vi laget metoder som kommuniserer direkte med Facebook og LinkedIn. Vi mottar denne informasjonen som et JSON- objekt, og parser den over til et JSON- objekt som sendes videre til IAS Web Service. Sprint 5 - Finpusse kode, feilmeldingshåndtering, testing og gjøre ferdig dokumentasjon. Siste innspurt før levering. 4. Kravspesifikasjon Nedenfor beskriver vi kravspesifikasjonen og dens rolle i prosjektgjennomføringen. 4.1 Generelt Kravspesifikasjonen har sett små forandringer underveis i prosjektet. Oppdragsgiveren har endret sine ønsker i løpet av prosjektperioden både pga. kompleksitet samt krav fra tredjeparter, spesielt bankene. Tross dette, har kravspesifikasjonen i store deler vært den samme hele veien. Tekniske krav var i stor grad opp til oss å bestemme, men en implementasjon i C# var mest hensiktsmessig, da bedriften måtte ha skrevet om kode fra Java eller annet til C# om vi hadde programmert i dette. Vi har to versjoner av kravspesifikasjonen en original og en etter de største endringene i starten av april. 4.2 Endringer i kravspesifikasjonen Det er i hovedsak systemkrav som har hatt små endringer. Krav om at bearertokens skal inneholder markeds- og/eller handelsinformasjon er ikke gyldig, da systemet ikke lenger skal generere tokens som brukes videre for kjøp og salg. Krav (Lagrede access tokens skal ha en levetid spesifisert av Infront) går bort, da systemet ikke skal generere egne tokens, men bruke de fra Facebook og LinkedIn. Med tanke på utvidelser under punkt 8., skal løsningen nå fungere for nettbrett og mobil. Dette fordi Infront startet et nytt prosjekt i april med ett- klikksregistrering på mobil og nettbrett. Dette prosjektet vil bruke vår løsning for denne registreringen. Side 16

17 5. Oppsummering/Konklusjon Her oppsummerer vi og kommenterer det ferdige produktet, samarbeidet og annet som kunne vært løst annerledes. 5.1 Oppsummering Vi var fra starten klar over at dette kom til å bli et krevende prosjekt, og dette var også noe som motiverte oss, i tillegg til at vi skulle lage noe som et stort selskap skulle bruke i en av sine produkter. Store deler av oppgaven gikk ut på å lære nytt stoff og komme med forslag til Infront basert på det vi hadde funnet ut. Vi endte til slutt opp med å lage et produkt som tilfredsstiller oppdragsgivers krav. I tillegg til dette er Auth Serveren også bygd opp slik at den, med mindre tilpasninger, kan benyttes i andre systemer enn kun Infront sitt. Det er også tatt høyde for at man på et senere tidspunkt kan implementere støtte for flere OAuth- tilbydere. Arbeidet vårt med den første problemstillingen resulterte i at Infront fant ut at den tenkte løsningen ble mer omfattende enn det de i utgangspunktet var klar over og vi måtte omstille oss litt, men det grundige arbeidet vi hadde gjort opp til da, gjorde at dette gikk mer eller mindre uten store problemer. Vi har lært mye om single sign- on, OAuth 2.0, REST API, DotNetOpenAuth, C#.NET og hvordan det er å være en del av et team som lager en større løsning, der vi er ansvarlig for én brikke i et helt system. Vi har sett viktigheten av planlegging og samarbeid, samt hvordan ting kan endre seg underveis i prosjektet av forskjellige grunner - noe som har vært både utfordrende, interessant og lærerikt. Vi har levert en server som går rett inn i Infront sin arkitektur og som vil bli en viktig komponent i dag og i fremtiden. 5.2 Hva kunne vært bedre? I starten satt vi mye på skolen på for å tilegne oss kunnskap om de aktuelle nye teknologiene vi trengte. Vi hadde kanskje kommet enda tidligere i gang med programmeringen om vi hadde oppsøkt utviklerne fra Infront allerede på dette tidspunkt. Dette ble lettere i ettertid, da vi etter hvert begynte å samarbeide med de om hele løsningen, men vi hadde helt klart kommet raskere i gang om vi hadde sittet nede på Infront sine lokaler helt fra starten av. 5.3 Ønsker for fremtiden Auth Serveren vi har laget kan utvides til det opprinnelige SSO- ønsket ved et senere tidspunkt. Derfor kommer produktet til å blant annet være klargjort for håndtering av mer brukerinfo enn det som er nødvendig i første omgang. Systemet vårt er såpass polymorft at det kan også konfigureres og eksporteres til andre bedrifter som vil benytte seg av en lignende løsning. Side 17

18 Ønsket vårt for fremtiden er at Auth Serveren kommer til å bli brukt i lang tid fremover og at Infront velger å endre på arkitekturen sin slik at serveren vil etter hvert kunne fungere mot bankene. 6. Figurliste Figur 1: Viser flyten til OpenID. Hentet fra openid- tfim/openid_authentication.gif Figur2: Viser flyten til SAML. Hentet fra browser- sso- post.gif Figur 3: Viser flyten til OAuth 2.0 Figur 4: Viser aktiviteter og arbeidsoppgaver som skal bli/har blitt gjort Figur 5: Viser sprinter og hva som skal gjøres i sprinten 7. Kilder D. Crockford, Juli 2006, JSON The application json Media Type for JavaScript Object Notation, hentet april D. Hardt, okt The OAuth 2.0 Authorization Framework, hentet Februar Scrum, u.å. oversikt hentet januar REST, u.å. oversikt hentet april sfer OpenID. u.å. OpenId spesifikasjon hentet februar SAML. u.å. SAML spesifikasjon hentet februar specifications DotNetOpenAuth, u.å. Hentet februar Side 18

19 Kommentar: Når det ikke er oppgitt noe personnavn: Nettstedet har en tydelig profil som formidler av informasjon, vi lar JSON stå som forfatter navn. Det er ikke oppgitt noen dato, derfor setter vi u.å. (dvs uten år) i stedet for årstall. Side 19