Styringsdokumentasjon

Transkript

1 Styringsdokumentasjon Forord Dette dokumentet er en samling av alle styringsdokumentene vi har brukt i hovedprosjektet ved Høgskolen i Oslo og Akershus(HiOA) våren Dokumentet består av flere selvstendige deler samlet i et dokument med felles innholdsfortegnelse. Styringsdokumentasjon Side 1

2 Innholdsfortegnelse 1. Innledning Prosjektskisse... 4 Infront SSO... 4 Gruppe Om Infront... 4 Problemstilling Prosjektdagbok Forprosjektrapport Sammendrag Om oppdragsgiver Dagens situasjon Mål Primære mål Sekundære mål Prioriteringsliste Utfordringer og risikostyring Benyttede teknologier Systemutviklingsmetoden Løsninger/Alternativer Konklusjon Endringer i prosjektet Grunner til endringer Endringsrapport Dagens situasjon Mål og krav Primære mål Sekundære mål Problemstilling Virkning av endringene for prosjektet Konklusjon Arbeidsplan og fremdriftsplan Arbeidsplan Fremdriftsplan Kravspesifikasjon Forord Innledning Bakgrunn for prosjektet og bedriften Systemkrav Krav til innloggingssystem Krav til innloggingssystem, endret Tekniske krav Tekniske krav, endret Datalagring Krav til datalagring Krav til datalagring, endret Kode Krav til kode Styringsdokumentasjon Side 2

3 7.7Dokumentasjon Krav til dokumentasjon Utvidelser Eventuelle utvidelser Eventuelle utvidelser, endret Innledning Prosjektgruppen har utviklet en løsning for håndtering av forskjellig typer tokens til autentisering for å lage en single sign- on- løsning for Infront AS. En single sign- on innebærer at man bare skal trenge ett sett med brukernavn og passord som man bruker til å logge seg inn på et sted og blir da samtidig logget inn på ett eller flere andre tjenester. I dette dokumentet vil single sign- on bli forkortet med SSO. Løsningen, Auth Server, er utviklet med C#.NET og fungerer som en autentiseringsserver med et WebAPI som håndterer REST kall. Styringsdokumentasjon Side 3

4 Det har gjennom prosjektet vært endringer, som har gjort til at blant annet krav og problemstilling har blitt forandret. Gruppen har gjennom hele prosjektet samarbeidet med Infront sine ansatte og deltatt på møter hos bedriften med resten av de involverte i systemet som gruppens løsning er en del av. 2. Prosjektskisse Infront SSO Hovedprosjekt data ved Høgskolen i Oslo og Akershus våren 2013 Gruppe 15 Erling Fjelstad Anders Emil Rønning Jon Hammeren Nilsson Lars Strande Grini Infront kontakt Kontaktperson: Erling Olaussen Head of development Adresse: Fjordalleén 16 Postnummer: 0250 Sted: Oslo Tlf: E- post: olaussen@infront.no Om Infront Infront leverer programvare for aksjehandel til banker og meglerhus, hovedsakelig i Norden, men også i Øst- Europa. Noen av de mest kjente er DNB og Danske Bank. Infront er tilbyder av sanntids markedsdata, nyheter og analyser fra over 50 børser over hele verden, Alt dette gjennom deres program Infront terminal. For at en kunde skal kunne logge på Infront terminal må kunden logge på med sin Infront- konto. For å få tilgang til kjøp/salg må deretter kunden logge inn i sin respektive bank via ett nytt vindu. Problemstilling Lage en SSO(Single- Sign- On)- løsning som gjør at kunden får full tilgang ved å logge inn én gang. Arbeidsgiver har ikke stilt noen spesifikke krav til verken plattform eller teknologi, men løsningen skal kunne integreres i deres eksisterende system og er derfor et ønske om at vi skal bruke Microsoft teknologi. Foreslåtte teknologier for autentisering er SAML, OpenId og OAuth Prosjektdagbok Uke 2 Første møte med Norun. Første dag av prosjektet etter nyttår. Hadde vårt første møte med veilederen vår på høyskolen. Diskuterte litt rundt prosjektet, og planla videre møter. Samlet stoff om OAuth 2.0. Styringsdokumentasjon Side 4

5 Uke 3 Møte nummer to med Infront: Hadde vårt andre møte med Erling Olaussen hos Infront. Vi diskuterte teknologier, planlegging og fremgangsmåter. Vi har bestemt oss for å bruke OAuth 2.0 som protokoll etter diskusjon med Erling. Som første mål skal vi sette opp en OAuth 2.0 Service Provider og en side vi kan logge oss på ved hjelp av denne for å få større forståelse for konseptet. Uke 4 Hadde møte med Norun. Snakket om veien videre, avtaler mellom oppdragsgiver og skole. Gikk gjennom forprosjektrapporten, og diskuterte hvordan denne kunne forbedres. Etter møte satte vi i gang med å lage Google- innlogging for en egen App, som vi fikk til. Jobbet videre på gårsdagens Google- innloggingsprototype, og lagde tilsvarende for Facebook og Twitter. Det som mangler er blant annet lagring av tokens. Utbedret rapporten og sendte til veileder. Uke 5 Hadde møte med veileder og diskuterte litt ansvarsfordeling, da dette er noe som enda har vært litt uklart. Utdypet også Way of working- dokumentet. OAuth- prototypen fungerer nå ved innlogging med Facebook, og lagrer tokenen i en database Det står stille om dagen, lite eller ingen fremgang innen OAuth- dummyprogrammet vårt. Har sendt mail til Tor Krattebøl og spurt om han vet noe om sikkerhet innenfor webløsninger, men fikk beskjed om at han hadde ingen kompetanse innenfor dette området. Vi fortsetter med prøving og feiling. Uke 6 Utformet skisse til sluttrapporten med de viktigste hovedpunkter, underpunkter og innholdsfortegnelse. Opprettet mal for sluttdokumentasjon. Grunnet mye nytt stoff angående utviklingsspråk så tar det litt tid å sette sammen et fungerende system, men utviklingsavdelingen har jobbet systematisk bra, noe som har resultert i stadig fremgang. Angående dokumentasjon har vi fortsatt mye å gjøre. Alt kan av naturlige årsaker ikke gjøres ferdig enda, men dokumentasjonsansvarlige har masse å ta tak i. Mail sendt til Erling Olaussen: Hei, Erling. Vi jobber stadig med dummy- programmet vårt. Etter å ha brukt en stund på å prøve og lage et bibliotek selv, har vi endt opp med DotNetOpenAuth. Dette særlig grunnet sikkerhetsaspektet som er en fordel med et ferdig og godt testet bibliotek. Ved hjelp av dette har vi fått til enkel autentisering mot Facebook, Google og Twitter. Der vi står litt fast nå, er interaksjonen med en egen autentiseringsserver. Dokumentasjonen til DotNetOpenAuth er noe manglende, så det er i hovedsak prøving og feiling Styringsdokumentasjon Side 5

6 rundt det å sette opp autentiseringsserveren og interaksjonen med den vi driver på med for øyeblikket. Uke 7 Endret oppsett for sluttdokumentasjon med utgangspunkt i dokumentasjonsstandarden. Laget egne mapper, og et dokument som inneholder kort fortalt hva som skal hvor. Vi gjør fremskritt med forslag til løsning, det går fortsatt ganske sakte fremover da det er så mye å sette deg inn i. Har satt opp skisse til sluttdokumentasjonen og driver å setter opp egen autorisasjonsserver. Veileder har fortsatt ikke svart på mailen sendt sist uke, vi har lyst til å ha et møte med Infront snarest, så vi kan diskutere veien videre med tanke på løsningen vi driver å utvikler. Han er på feire i to uker, så vi forsetter med dokumentasjonen, utviklingen og lager diagrammer. Uke 8 Forbedret mappestruktur for dokumentasjon. I forrige uke (uke 7) ble innleveringer i andre fag prioritert, og det ble dermed ikke jobbet særlig mye på prosjektet. Vi fortsetter jobbingen med autorisasjonsserveren denne uken, og har som mål å ha en fungerende server å vise til Infront neste uke. Vi har laget fremdriftsplan og arbeidsplan, og utdypet kravspesifikasjonen. Startet å skrive på prosessdokumentasjonen. Startet med å lage API Uke 9 Vi har kommet videre med å få satt opp en autorisasjonsserver. Nå skal det lages en database for lagring av tokens. Vi har nå hørt fra Infront og har avtalt et møte der vi skal vise fram koden til serveren vår. Ellers har vi fått konstruktive tilbakemeldinger fra Norun på noen dokumenter som vi nå har fått forbedret. Uke 10 Møte med infront. Kom fram til ny måte å lage løsningen på. Dette skal gjøres ved at vi setter opp en (federerings)server som tar seg av generering av tokens, autentisering og autorisasjon av brukere ved hjelp av identity providers som LinkedIn, Facebook og Google. Uke 11 Jobbet med den løsningen vi kom fram til i forrige uke. Var å jobbet hos Infront på tirsdag og fikk pratet litt med sikkerhetsekspert, Andrew Gubanov. Uke 12 Jobbet med sekvensdiagrammer og andre grafiske tegninger av hvordan vår nye løsning skal fungere i praksis. I tillegg til dette har det blitt framgang på programmeringsfronten Uke 13 Påskeferie og samt jobbing med andre fag. Styringsdokumentasjon Side 6

7 Uke 14 Oppfølgingsmøte hos Infront der vi har fortalt litt hvordan det har gått de siste ukene. Programmeringen begynner å komme på stell nå, får logget inn med en tredjepart(linkedin). Uke 15 Nytt møte hos Infront. De har startet å utvikle en lignende løsning som vi lager, nå bare for mobil. Dette resulterte i at vi må modifisere problemstilling og alle andre dokumenter fordi dette skal nå bli gjort litt annerledes. Heldigvis for oss var programmeringsdelen vår ganske bra oppbygd, sånn at den bare trenger små modifikasjoner for å passe inn i det nye systemet. Uke 16 Møte med Infront. Diskutert oppbygningen av hva som skal sendes mellom serverne, standarder protokoller og hvordan dette skal håndteres. Dette skal diskuteres mer med Steffen Søyland Hellestøl i løpet av denne eller neste uke. Han er ansvarlig for brukerdatabasen hos Infront. På grunn av endringer i prosjektet har vi laget en undermappe under Sluttdokumentasjon hvor foreldede utdrag fra dokumentasjonen legges, slik at vi ikke mister noe av arbeidet i tilfelle det trengs senere. Uke 17 Gjort ferdig endring av prosessdokumentasjon ut fra Noruns kommentarer. Prosessdokumentasjon: rett skrivefeil og formateringsfeil. Fylt ut punkt 7 med underpunkter. Mye lesing om REST og satt oss inn i hvordan vi skal lage et API. Ferdig stilling av prototype. Definerte meldinger mellom systemene. Møte Torsdag for å diskutere hvordan IAS serveren skal kunne ta imot våre meldinger. Prosess: Endret nummerering, innholdsfortegnelse, formatering. Skrevet om 1.2, 1.3, lagt til nytt punkt, 1.4 Endringer, nummerert alle figurer og satt inn caption. Uke 18 Skrev styringsdokumentasjon og sendte til Norun for vurdering. Koding: Access token blir hentet fra Facebook og parset. Får også hentet JSON- objekt med brukerinfo og parset dette. Møte med Kurt Petter Humstad, Steffen Hellestøl og Andreas Hage. Fant ut at vi skulle bruke WebAPI(REST) og JSON for kommunikasjon til web admin. Dette bruker vi fordi da er det lik teknologi på klient og server. I tillegg er dette nytt og kom med i asp.net 4.5 Uke 19 Alle gruppemedlemmene jobbet iherdig med dokumentasjon i påvente at Kurt skal bli ferdig med sin web service Styringsdokumentasjon Side 7

8 Uke 20 Kurt er ferdig med sin del, vi har finpusset programmeringsdelen av prosjektet vårt. Siste delen av programmeringen blir å sende tilbake konstruktive feilmeldinger til Web Admin som foretar kallene mot Auth Serveren. Denne uken har det også foregått ferdiggjøring av alle dokumenter. Uke 21 Lest nøye igjennom dokumentstandaren, produkt og prosessdokumentasjonen og har funnet ut at det er en del viktige ting som gjenstår å få dokumentert, spesielt i oppsummering/konklusjon. Ellers finpusset og fikset skrivefeil som stadig dukker opp i dokumentene. Uke 22 Prosjektet er nå levert. 4. Forprosjektrapport 4.1 Sammendrag Vi skal lage en innloggingsfunksjon for Infront sånn at deres program, Infront Terminal, skal bli mer brukervennlig i den forstand av brukeren bare skal trenge å logge seg inn en gang i stedet for to ganger slik det er i dagens løsning. 4.2 Om oppdragsgiver 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. 4.3 Dagens situasjon Infront har i en tid ønsket å få utviklet en Single Sign- On (heretter forkortet til SSO) løsning til deres tjenester, Infront Terminal og Infront Connect. Per dags dato må kunden først logge seg inn på terminalen for å se på markedsdata, for så å logge inn på Infronts plugin (Infront Connect) - som ligger oppå bankens OMS (Order management system) - for å kjøpe og selge aksjer og valuta (Se figur 1). Styringsdokumentasjon Side 8

9 Figur 1 Dagens løsning fra Infront AS 4.4 Mål Vi har delt inn målene i primære og sekundære mål, der de primære målene er de kritiske som må bli oppfylt, mens de sekundære målene skal gjøres hvis tiden tillater det Primære mål Integrere SSO i dagens løsning ved hjelp av OAuth 2.0, SAML og/eller OpenID. Sette opp en autorisasjonsserver hos Infront som skal ta seg av autorisasjonen av brukere og sende ut access tokens til resten av systemet, avhengig av teknologi og behov. Lage en sikker løsning med tanke på integritet for brukeren og pålitelighet for systemet Sekundære mål Integrere innlogging via LinkedIn, Facebook, Google og eventuelt andre tredjeparter som kan gå god for brukeren. Styringsdokumentasjon Side 9

10 4.4.3 Prioriteringsliste Funksjonalitet Prioritet Implementere SSO 1 Sette opp en autorisasjonsserver 1 Sikker løsning 1 Implementere SSO også på mobil plattform 3 Integrere logg inn m/ LinkedIn 4 Prioriteringsverdier: 1 Vital 2 Høy 3 Middel 4 Lav 5 Veldig lav 4.5 Utfordringer og risikostyring Funksjonalitet Implementere en SSO- løsning Applikasjoner for spesifikke mobile plattformer Få løsningen sikker Sette opp en autentiseringsserver Utfordringer Kode, type teknologi som skal brukes Lære programmering for de spesifikke plattformene Vurdere alle muligheter, kryptografi, integritet og pålitelighet samt sikre kvaliteten på koden. Lære seg å sette opp en autentiseringsserver, sikker autentisering Utfordringer under planlegging og utførelse av oppgaven: Omfang Størrelsen og vanskelighetsgraden på oppgaven kan bli en utfordring, da vi ikke med sikkerhet kan si nøyaktig hvor stor og omfattende den vil bli, og ettersom vi ikke sitter inne med noen kunnskaper om SSO eller teknologiene som skal benyttes, vi må også sette oss inn i Infront sine programmer som er omfattende og avanserte. Tidsfrister Gruppas tidsfrister i forhold til egen fremdriftsplan og Innleveringer, hvis det skulle dukke opp uforutsette hendelser som sykdom, som gjør at vi må gjøre endringer på arbeidsoppgaver og ansvar for å kunne nå fristene. Samarbeid Fordeling av oppgaver og roller i gruppa må gjøres slik at alle sitter igjen med samme kunnskapsnivå fra alle nivåer av prosjektet. Dette for å maksimere læring, og samtidig gi alle like stor følelse av deltakelse. Kommunikasjon innad i gruppa er vesentlig for at alle vet hva hver enkelt skal gjøre og hvordan vi ligger an, dette løser vi ved hjelp av Styringsdokumentasjon Side 10

11 fremdriftsplan, der arbeidsoppgavene er oppført med beskrivelse og hvem som skal utføre den. Vi har også en gruppe på Facebook der kan diskutere og spørre om hjelp og ideer. Konflikt Konflikter og uenigheter i gruppa kan oppstå og vi vil løse dette ved diskusjoner og av avstemninger om det skulle passe. 4.6 Benyttede teknologier Software: Microsoft Visual Studio 2012 Microsoft Office 2010 Microsoft Visio 2010 Programmeringsspråk og rammeverk: C#.NET o DotNetOpenAuth- biblioteket ASP.NET Entity Framework 4.7 Systemutviklingsmetoden Vi har bestemt oss for å bruke Scrum som systemutviklingsmetode oss fordi det er et agilt rammeverk og vi kan jobbe iterativt, samt at det er praktisk for en liten utviklergruppe. I Scrum nås målet ved å dele opp hele prosjektet i flere små deler, i prioritert rekkefølge. Disse løper vi gjennom i iterasjonene/sprintene som vil vare i alt fra 1-4 uker. Etter hver sprint evalueres resultatet før vi planlegger neste sprint og eventuelt omprioriterer noen av delmålene. Scrum er en smidig utviklingsmetode som blant annet går ut på at man begynner tidlig med programmeringen for å lettere få en oversikt over hva som skal gjøres og et bedre bilde av tidsperspektivet. 4.8 Løsninger/Alternativer Vi drøftet løsninger med veilederen vår hos Infront, Erling Olaussen, og kom fram til følgende alternativer: Løsning 1: Lage en SSO- løsning der vi bruker bankens innloggingssystem til å logge på, og at Infront stoler på bankens informasjon. Løsning 2: Vi lager en løsning der man logger seg først inn hos Infront og så hos banken, med den innloggingsinformasjonen vi får da, oppretter vi en ny database som all ny autorisering og autorisasjon vil bli sjekket mot. Styringsdokumentasjon Side 11

12 Figur 2 Vår foreslåtte løsning 4.9 Konklusjon Det finnes i hovedsak to standarder vi kan benytte oss av; SAML og OAuth 2.0. Begge er tokenbasert, og begge har eksisterende mekanismer for både autentisering og autorisering. Det ser ut til at prosjektet kan løses både med OAuth 2.0 og SAML, så vi har foreløpig ikke bestemt oss for hvilken standard som skal brukes. Utgangspunktet er OAuth 2.0, noe som også var foreslått av Erling Olaussen. Dette på grunn av flere punkter: Open Source det finnes ingen open source biblioteker for SAML i.net. Arbeidsgiver har foreløpig ingen planer om å bruke penger på et eget API. Populæritet OAuth 2.0 brukes av blant annet Yahoo, Google, Facebook og Twitter, altså eksisterende sider der det er mange eksisterende kontoer. Sikkerhet I OAuth 2.0 som er den nye standarden foregår all utveksling av data på SSL. Styringsdokumentasjon Side 12

13 5. Endringer i prosjektet 5.1 Grunner til endringer Etter mye utforskning og testing kom vi i samarbeid med Infront frem til at prosjektet slik det ble formulert fra starten ikke lengre vil være aktuelt. Endringene i prosjektet skyldes at bankene ikke vil godta at Infront står for autentiseringen av deres brukere. Dette ville blitt tilfellet om bankene skulle stolt på en token som vi har utstedt. I tillegg viste det seg at det ikke ville være mulig å implementere token- godkjenning i resten av Infront sitt system uten å involvere hele den tekniske delen av bedriften. Dette på grunn av infrastrukturen til Infront sine systemer, som er bygget på at brukernavn og passord blir sendt rundt i de fleste kall. Erling Olaussen mente en slik endring ville bli for omfattende for øyeblikket, samt at bedriften hadde høyere prioriteringer før sommeren. Vi diskuterte muligheten for å heller snu situasjonen, og stole på at banken autentiserer brukerne for oss, men dette vil ikke bli mulig før de selv implementerer en OAuth- autorisasjonsserver, som vi kan motta tokens fra. I følge Erling Olaussen var blant annet den Danske Bank i planleggingsfasen for dette. Denne åpenbaringen kom mye på grunn av vårt arbeid og forsking. De hadde imidlertid et annet prosjekt gående der de utvikler en gratis applikasjon for Android og ios der de vil at brukeren skal kunne registrere seg og logge inn med en tredjepartstjenester som Facebook og LinkedIn. Dette prosjektet passet bedre fordi det ikke involverte hele det eksisterende systemet. Ideen og teknologien var den samme. Endringene hadde liten innvirkning på arbeidsplan og fremdriftsplan, men kravspesifikasjonen og målene måtte endres til å passe den nye problemstillingen. Vi valgte å lage en liten rapport om endringene for å sette opp den nye problemstillingen med nye mål og krav. 5.2 Endringsrapport Dagens situasjon Infront utvikler en applikasjon til ios og Android for deres tjenester, denne applikasjonen vil være gratis og det skal kun være mulig å registrere seg og logge inn med en tredjepart. De har prioritert å lage registrering og innlogging med Facebook først på grunn av at de har flest brukere. Vi skal sette opp en Authserver som skal kunne håndtere denne registreringen og innloggingen Mål og krav Primære mål Integrere Authserver(en autentiseringsserver) som ved hjelp av OAuth 2.0 kan autentisere brukere som ønsker å registrere seg eller logge inn på Infront sin applikasjon med Facebook. Styringsdokumentasjon Side 13

14 Sekundære mål Integrere innlogging og registrering via LinkedIn, Google og eventuelt andre tredjeparter som kan gå god for brukeren Problemstilling Lage en SSO- løsning for Infront sin applikasjon som gjør at brukeren kan logge seg inn og registrere seg ved å bruke en tredjepart der de allerede har registret en bruker Virkning av endringene for prosjektet At prosjektet tok en annen vei en først antatt gjorde at vi måtte restrukturere løsningen og dokumentasjonen, selv om det var veldig mye overlapp gjorde dette at det ble en del ekstra arbeid på justeringer så alt skulle passe til den nye løsningen Konklusjon Som i veldig mange prosjekter er det vanskelig å forutse og planlegge alt. Vi kom med forslag til hvordan problemet til Infront kunne løses, og på grunn av dette kom vi sammen frem til at det ikke var aktuelt på dette tidspunktet som nevnt overfor. Ettersom vi bruker samme teknologi og den nye løsningen også skal være en tokenbasert autentiseringsserver, kunne mye av det vi allerede hadde gjort brukes, og ettersom vi allerede hadde satt oss godt inn i stoffet kunne vi enkelt gjøre de justeringene som måtte til for den nye løsningen. 6. Arbeidsplan og fremdriftsplan 6.1 Arbeidsplan Aktivitet Beskrivelse Ferdig Innledende Statusrapport Kort info om gruppen og 2012 prosjektet Prosjektskisse Beskrivelse av prosjektet og 2012 arbeidsgiver Prosjektside Hjemmeside for prosjektet 2012 Forprosjekt Arbeidsplan Fremdriftsplan Kravspesifikasjon Mål, krav og teknologier i prosjektet Oversikt over hva som skal gjøres Oversikt avsatt tid til deler av prosjektet Uke 4 Uke 7 Uke 7 Styringsdokumentasjon Side 14

15 Datainnsamling Skaffe oversikt over nødvendige aspekter av ny teknologi til prosjektet Uke 6 Kravspesifikasjon Detaljert kravspesifikasjon Uke 9 Prototype og implementering Sette opp miljø.net OAuth Sette opp egen klient og egen server Prototype Implementering Testing og feilsøking Intern testing Ekstern testing Finpusse kode Skrive testrapport Dokumentasjon Sluttrapport Prosjektdagbok Lage prosjekt i Visual Studio og installere rette rammeverk. Sette opp OAuth bibliotek i.net Sette opp en klient og en autentiseringsserver for testing med bruk av OAuth og access tokens Lage en prototype av Authserveren Implementere Authserveren i systemet til Infront Teste serveren, prøve ut unaturlige hendelser og prøve å få det til å krasje. Fange alle feil og håndtere de Teste severen med de andre systemene hos Infront. Håndtere eventuelle feil Finpusse koden, gjøre den mest mulig forståelig og kommentere om noe mangler Lage en rapport av testene som har blitt utført og utfallet av disse Komplett dokumentasjon for hele prosjektet Føre prosjektdagbok under hele prosjektet Uke 7 Uke 11 Uke 10 Uke 12 Uke 19 Uke 21 Uke 21 Uke 21 Uke 21 Uke 23 Uke 23 Avslutning Forberede presentasjon Lage fremføring av hele Uke 23 prosjektet med PowerPoint Presentasjon Fremføring i auditorium Uke 24 Styringsdokumentasjon Side 15

16 6.2 Fremdriftsplan Figur 3: Fremdriftsplan Styringsdokumentasjon Side 16

17 Figur 4: Milepæler Figur 5: Fargekoder 7. Kravspesifikasjon 7.1 Forord Denne kravspesifikasjonen beskriver betingelsene for prosjektet vårt, Infront SSO. Krav til funksjonalitet og rammebetingelser er beskrevet i dette dokumentet. Hovedkravene av funksjonalitet er gitt av Infront, men hvordan det er spesifikt og hvordan det løses har gruppa styrt selv. 7.2 Innledning Prosjektet skal gjennomføres som et hovedprosjekt ved HiOA Ingeniøravdelingen i samarbeid med Infront. Oppgaven gikk i første omgang ut på at vi skal utvikle en Single Sign- On- løsning til Infront sine tjenester, Infront Terminal og Infront Connect, slik at brukerne kun trenger å logge inn en gang for å få fult utbytte av programmet. Dette ble endret til at vi skal lage en autentiseringsserveren, Auth Server, slik at brukeren skal kunne registrere seg og logge inn med en tredjepart. dette er også en from for SSO, men noen av kravene måtte endres og noen fjernet fordi det lenger ikke er en del av funksjonene, som for eksempel skal brukerinformasjon ikke lengere lagres i vår løsning og da er det ikke lengere et krav om bruk av database. Vi vil utvikle dette systemet ved hjelp av C# og OAuth Bakgrunn for prosjektet og bedriften Infront har i dag mange kunder som får tilgang til markedsdata gjennom applikasjonen, Infront Terminal. Da Infront Terminal er en betalingstjeneste, må alle brukere være registrert og innlogging er nødvendig. Infront tilbyr i tillegg en plattform, Infront Connect, hos diverse banker, meglerhus og andre som tilbyr kjøp og salg av aksjer. Denne plattformen gjør det mulig å handle gjennom Infront Terminal. For å få tilgang til denne tjenesten, må brukerne autentiseres hos banken, noe som betyr at de må logge på også her. Innloggingsinformasjonen hos banken er naturligvis en annen enn hos Infront. Konsekvensen av dette er at brukerne må taste inn to forskjellige brukernavn og passord først for å bruke terminalen, og deretter for å handle hver gang. Det er denne siste innloggingen de vil eliminere da dette er noe arbeidsgiver har uttrykt at er veldig tungvint for brukerne. De vil ha en løsning der man logger seg inn en gang og blir automatisk logget inn og autorisert hos andre tjenester som tilhører applikasjonen - en single Styringsdokumentasjon Side 17

18 sign- on. Dette viste seg å ikke la seg gjennomføre, og de ville heller at vi skulle lage en autentiseringsserver for applikasjonen som er under utvikling, denne applikasjonen er gratis og man får bare tilgang til markedsdata og informasjon som er gratis og trenger derfor ikke å involvere bankene som var med på å gjøre at vi ikke kunne gjennomføre prosjektet slik vi først satte ut til å gjøre. 7.4 Systemkrav Krav til innloggingssystem 1. Brukeren skal bli innlogget via en sikker kanal - HTTPS. 2. Brukeren skal kun trenge å logge inn én gang for å få nødvendig tilgang. 3. Det skal være mulig å oppnå single sign- on med eksterne tjenester (Facebook og LinkedIn). 4. Det bør brukes bearertokens. Disse skal inneholde marked- og/eller handelsinformasjon. 5. Det skal være single sign- off Krav til innloggingssystem, endret 1. Brukeren skal bli innlogget via en sikker kanal HTTPS. 2. Informasjon om brukeren skal bli sendt over en sikker kanal HTTPS. 3. Brukeren skal kun kunne registrere seg og logge inn via en tredjepart. 4. Brukeren skal bli identifisert ved hjelp av en unik nøkkel. 5. Tredjeparter skal bli identifisert ved hjelp av en unik nøkkel Tekniske krav 1. Det skal utvikles med OAuth 2.0 sammen med C#.NET. Det bør brukes DotNetOpenAuth- biblioteket. 2. For å garantere sikkerheten, skal all data sendes på en trygg måte (sikker kanal, kryptert). 3. Microsoft Visual Studio 2012 bør brukes som utviklingsverktøy. 4. Datalagring kan foregå i SQL Databaser i samarbeid med Linq/Entinity Framework. 5. Auth Server skal kjøres på en Windows server. 6.Klient- til- server kommunikasjon skal sendes med SSL/TLS. 7. Det skal være server- til- server kommunikasjon ved henting og utveksling av tokens Tekniske krav, endret 1. Auth Server skal utviklet med OAuth 2.0 sammen med C#. 2. Auth Server bør bruke DotNetOpenAuth- biblioteket. 3. Kall til Auth Server skal gjøres gjennom REST Web API. 4. Auth Server skal sende og motta meldinger i from av JSON. 7.5 Datalagring Krav til datalagring 1. Validering av data skal sjekkes av systemet før det sjekket mot databasen. 2. Lagrede access tokens skal ha en levetid spesifisert av Infront. Styringsdokumentasjon Side 18

19 7.5.2 Krav til datalagring, endret 1. Auth Server skal ikke lagre informasjon om brukeren. 2. Auth Server skal ikke lagre access tokens. 7.6 Kode Krav til kode 1. Alle kontroller, metoder og variabler bør ha naturlige navn i forhold til hva de brukes til. 2. Kodefilene bør kommenteres for å si hva filen gjør, og hvem som har skrevet filen. 3. Koden skal optimaliseres for videreutvikling, og skal være lett å sette seg inn i. 7.7Dokumentasjon Krav til dokumentasjon 1. Det skal føres logg over hva som blir gjort, hvilke utfordringer og hvordan det blir løst 2. Når prosjektet er ferdig skal det kunne dokumenteres igjennom: o Styringsdokumentasjon o Prosessdokumentasjon o Produktdokumentasjon o Testrapport o Kravspesifikasjon o Brukermanual 7.8 Utvidelser Eventuelle utvidelser 1. Løsningen vår bør fungere for mobil og nettbrett. 2. Gjøre det mulig å registrere seg og logge inn med en annen autorisasjonsserver (for eksempel LinkedIn). 3. Utvide til en eventuell nyere standard for OAuth Eventuelle utvidelser, endret 1. Auth Server kan utvides til å støtte andre tredjeparter for autentisering. 2. Auth Server kan utvides til at Infront terminal også kan benytte den. Styringsdokumentasjon Side 19