Forprosjektrapport. Høgskolen i Oslo og Akershus. Gruppe 1. Forfattere: Erik H. Forsén Erlend K. Rognes Ole G. Hansen Julie H. Roa

Transkript

1 Høgskolen i Oslo og Akershus Gruppe 1 Forprosjektrapport Forfattere: Erik H. Forsén Erlend K. Rognes Ole G. Hansen Julie H. Roa Veiledere: Ismail Hassan Frank T. Johnsen Trude H. Bloebaum 1. juni 2015

2 Innhold 1 Presentasjon Oppdragsgiver Oppgave Sammendrag 3 3 Dagens situasjon 4 4 Mål og rammebetingelser Mål Teknologier Rammebetingelser Løsninger Utvikling «back end» Utvikling «front end» Produktet Analyse av virkninger «Front end» «Back end» Applikasjonsserver Referanser 11 1

3 1 Presentasjon Oppdragsgiver Prosjekttittel Oppgave Forsvarets forskningsinstitutt (FFI) Common Operational Picture Secured Webapplikasjon som forstår, dynamisk presenterer- og gir tilgang på differensiert informasjon basert på informasjon om brukeren og vedkommendes rettigheter Periode Gruppenummer 1 Gruppemedlemmer Erik Haider Forsén, s Ole Gunhildsberg Hansen, s Erlend Kristoffer Rognes, s Julie Hill Roa, s Talsmann Erlend Kristoffer Rognes Intern veileder Eksterne veiledere Ismail Hassan Frank Trethan Johnsen, frank-trethan.johnsen@ffi.no, Trude Hafsøe Bloebaum, trude-hafsoe.bloebaum@ffi.no, Prosjektside Oppdragsgiver FFI driver anvendt forskning innenfor en rekke fagområder, blandt annet informatikk. Felles for nesten all forskningen ved FFI er at den er rettet inn mot Forsvarets behov. FFI har en høy grad av samarbeid med internasjonale partnere, spesielt innen NATO 1. FFI jobber, sammen med representanter fra andre nasjoner, med å utvikle, teste og verifisere standarder og profiler som skal benyttes til utveksling av informasjon mellom nasjonene i NATO. En viktig del av dette arbeidet er å kunne demonstrere nytten av disse løsningene til militære beslutningstagere. Per i dag har FFI ingen god applikasjon som kan benyttes til å demonstrere 1 North Atlantic Treaty Organization 2

4 nytten av de relevante sikkerhetsstandardene, og det er dette prosjektet skal bidra til. 1.2 Oppgave FFI ønsker en webapplikasjon der autoriserte brukere får differensiert tilgang til informasjon, basert på informasjon om brukerne. Eksempler kan være at kun norske brukere får tilgang til informasjon som kommer fra en gitt kilde, eller at brukeren må være klarert for «NATO Secret» for å kunne se informasjon med denne graderingen. FFI bruker plattformen OpenAM til tilgangskontroll, og denne benytter standarden SAML til å uttrykke informasjon om brukere. Webapplikasjonen som prosjektet skal lage må kunne forstå denne brukerinformasjonen, og deretter vise frem den informasjonen brukeren har tilgang til. Denne informasjonen skal presenteres dynamisk på kart og blir sendt til en server i form av NATOs egne filformater basert på XML 3. Dette kan typisk være informasjon om posisjon, nasjonalitet, med mer til objekter som vennlige tropper, fly, skip og lignende. 2 Sammendrag Gjennom våren 2015 skal vi utvikle en webapplikasjon i samarbeid med FFI som de vil ta i bruk på en større NATO-øvelse i juni. Frank T. Johnsen og Trude H. Bloebaum vil være våre veiledere fra FFI. Vår interne veileder vil være Ismail Hassan. Oppgaven vi har fått tildelt vil ha fokus på aksesskontroll hvor autoriserte brukere får differensiert tilgang til informasjon. Eksempel kan være at kun norske brukere får tilgang til informasjon som kommer fra en gitt kilde. Måten vi ønsker å løse dette på er å vise informasjon dynamisk på et kart. Norge skal i samarbeid med andre nasjoner definere, verifisere og utvikle sikkerhetsstandarder på informasjonsutveksling. I NATO er det utviklet «Network Enabled Capabilities» 4 Dette innebærer at brukere på operative nivåer skal kunne kommunisere og ha tilgang til informasjon de trenger. For å kunne koble sammen teknologier, har NATO valgt å å satse på tjenesteorientert arkitektur, SOA 5. Vi skal filtrere på SAML 2.0 token for å se hvem som skal ha tilgang til hva på kartet. Vårt hovedmål ved oppgaven er å tilby FFI en webapplikasjon de kan demonstrere sin sikkerhetsløsning på. Vi har stort sett fått frie tøyler til å ta de fleste avgjørelser selv. Noen rammebetingelser har vi likevel fått, slik at løsningen skal fungere i de miljøene FFI ønsker å demonstrere. I forhold til løsninger vi ønsker å bruke for å gjennomføre prosjektet, har vi bestemt oss for Java «back end» og AngularJS, Leaflet og Foundation «front 2 Security Assertion Markup Language versjon extensible Markup Language 4 NNEC - Nettverksbasert Forsvar 5 Service Oriented Architecture 3

5 end». Gjennom utarbeidelsen av denne rapporten har vi analysert hva som vil passe oss best i forhold til vår oppgave. I seksjon 6 på side 8 kommer det frem mer detaljert hvorfor vi ønsker å bruke de verktøyene, og hvorfor de passer oss. 3 Dagens situasjon Et av forskningsprosjektene FFI holder per dags dato er informasjonsflyten mellom nasjoner og applikasjoner i forsvaret. Norge i samarbeid med andre nasjoner, skal derfor definere, verifisere og utvikle sikkerhetsstandarder på informasjonsutveksling. I NATO har man utviklet konseptet «Network Enabled Capabilities» som tilsvarer «Nettverksbasert Forsvar» [2]. Dette innebærer at brukere på operative nivåer problemfritt skal kunne kommunisere og ha tilgang til den informasjonen de trenger. Da det er snakk om forskjellige nasjoner med egne systemer er det urealistisk og tro at alle vil bytte ut sin egen teknologi med noe nytt. For å kunne koble sammen de nye og de gamle systemene og oppnå sømløs informasjonsutveksling har NATO valgt å satse på tjenesteorientert arkitektur (SOA). Dette skal de oppnå ved å bruke web services. Dette kan være en utfordring da Web services fungerer best med høy båndbredde, noe man ikke alltid har ute i felt. For tiden er det et driv i NATO mot nye, forbedrede informasjonutvekslingsformater og i 2014 var FFI med i øvelsen CWIX[1] 6. Her ble det gjort eksperimenter med fokus på SOA. FFI samarbeidet med NCIA 7 og partnernasjoner der målet var utvikling og verifisering av FMN 8 -relaterte interoperabilitetsspesifikasjoner for sentrale infrastrukturtjenester. I 2015 skal de videreføre denne forskningen og bygge på resultatene fra FFI planlegger å bidra på tre områder, informasjonsutveksling, webautentisering, og web service sikkerhet. Vår jobb er derfor å lage en testapplikasjon hvor de kan demonstrere sine resultater for NATO på CWIX Vi skal ta i mot sanntidsinformasjon på en server og fremvise et situasjonsbilde. Vi skal også filtrere på SAML 2.0 token for så å gi tilgang og rettighet ut ifra det. Dette ved hjelp av web services, SOAP 9 og NATO formaterte XML-filer. 4 Mål og rammebetingelser 4.1 Mål Hovedmålet med arbeidet vårt er å tilby FFI en webapplikasjon de kan demonstrere sin sikkerhetsløsning på. I tillegg har vi disse målene: 6 Coalition Warrior Interoperability exploration experimentation and examination exercise 7 NATO Communications and Information Agency 8 Federated Mission Networking 9 Simple Object Access Protocol 4

6 lage en «situational awareness» 10 webapplikasjon tilby en komplett webapplikasjon bestående av «back end» og «front end» løsningen skal kunne demonstreres eksternt kildekoden skal kunne vedlikeholdes og videreutvikles av andre utviklere uten store utfordringer 4.2 Teknologier JavaSE Spring Framework Spring Security OpenAM JavaScript Apache TomCat IntelliJ IDEA GIT (Bitbucket som hostingtjeneste) L A TEX JIRA & Confluence 4.3 Rammebetingelser FFI har gitt oss en oppgave der vi tar de fleste avgjørelser selv. Noen rammebetingelser er det likevel, slik at løsningen vår skal fungere i de miljøene FFI ønsker å demonstrere. VMWare (virtuelle maskiner) Benytte web services som maskin-til-maskin kommunikasjon SOAP Må støtte både publish / subscribe og request / response metoder Windows 7 server «Back end» skrives i Java, rammeverk Spring Framework «Front end» skrives i JavaScript, rammeverk AngularJS & Leaflet «Back end» må kunne ta i mot data i henhold til NFFI[3] 11 og NIEM En webapplikasjon som viser hvor forskjellige ressurser befinner seg i nærområdet. Kan være vennlige styrker, mistekenkelig aktivitet og lignende 11 Nato Friendly Force Information 12 National Information Exchange Model 5

7 Systemet må kunne forstå og ta i bruk «tokens» fra OpenAM, SAML 2.0 er formatet som benyttes 5 Løsninger For valg av teknologier har vi i denne seksjonen prøvd å forklare litt rundt våre valg og behov: 5.1 Utvikling «back end» Vi har sett på litt ulike teknologier for bruk i vår «back end». Nedenfor ser man en kort presentasjon om de teknologiene vi kommer til å benytte, samt litt drøfting rundt valgene vi har tatt. Java SE Ved å bruke Java SE får vi tilgang til ny funksjonalitet i Java 8, som vi vil utforsøke og eventuelt benytte. Java SE har god integrasjon mellom Spring Framework, Spring Security og OpenAM, samt Maven som gjør oppsett og avhengighet av disse lett. Spring Framework med Spring Security Spring Framework er et velkjent rammeverk for Java. Spring Framework er godt dokumentert og virker å være et greit rammeverk å sette seg inn i. Med Spring Security kan vi også fokusere på sikkerhet. Dette kan integreres godt med OpenAM som vi skal bruke til innlogging og rettighetskontroll. Deler av rammebetingelsene våre er å bruke web services og SOAP, dette har også Spring støtte for gjennom Spring-WS. OpenAM OpenAM er en tilgangskontroll-, rettigheter- og føderasjonsplattform. Denne gjør det mulig med Single Sign On på tvers av systemer og enheter. Brukernes rettigheter er ikke definert av OpenAM, men av systemeierne. Dette gjør OpenAM til en fleksibel plattform. I vårt prosjekt vil rettighetene leveres i form av SAML 2.0 tokens. Maven Vi har sett på flere forskjellige byggsystem, hovedsaklig Ant, Maven og Gradle. Maven har et mer moderne konfigureringsstruktur enn Ant (konvensjoner istedenfor lange XML konfigurasjonsfiler), og er raskere til å bygge en Gradle. Vi ser at Maven er kapabel til å inkludere OpenAM i prosjektet, samt bygge og 6

8 «deploye» prosjektet mot TomCat. Fungerer godt i IntelliJ IDEA, som er vårt forløpig valg av IDE 13. TomCat Ved valg av applikasjonsserver så har vi sett litt på GlassFish, JBoss, TomCat og TomEE. TomCat skiller seg her ut ved at den er hovedsaklig en HTTP 14 server med støtte for servlets og jsp. TomCat har altså ikke full støtte for Java EE, men kun et subset av spesifikasjonen. Til vårt prosjekt så har vi konkludert med at TomCat vil være tilstrekkelig. Fordelen med å benytte TomCat kontra de andre er at TomCat har et betydelig mindre «footprint» når det kommer til ressursbruk, og er mer effektiv. Konklusjon Vi har tidligere jobbet sammen med utvikling av webapplikasjon innenfor.netrammeverk. Vi ønsker å tilegne oss kompetanse på begge feltene og samtidig komme litt utenfor komfortsonen. Samtidig er veilederne våre godt kjent med utvikling innenfor Java i tidligere prosjekter. Dette vil være positivt av den grunn at FFI lettere kan videreutvikle vårt produkt og vi kan samtidig få hjelp om vi står fast. 5.2 Utvikling «front end» Vi har sett på flere alternativer til applikasjonen. Vi har ut i fra våre søk kommet frem til disse valgene i forhold til utvikling «front end»: AngularJS Vi har valgt å utvikle «front end» ved hjelp av AngularJS. Dette fordi Angular er et MVC 15 -rammeverk fra Google som hjelper å strukturere JavaScript og dele opp i «models», «views» og «controllers». AngularJS gir en fin arkitektur på koden. Leaflet For applikasjonens karttjeneste har vi valgt å bruke Leaflet. Leaflet er et moderne «open source» JavaScript bibliotek for mobilvennlige, interaktive kart. Leaflet virker effektivt på alle stasjonære og mobile plattformer og drar god fordel av HTML5 16 og CSS3 17 på moderne nettlesere, samtidig som det er lett tilgjengelig på eldre versjoner. 13 Integrated Development Environment 14 HyperText Transfer Protocol 15 Model-View-Controller 16 HyperText Markup Language versjon 5 17 Cascading Style Sheets versjon 3 7

9 Leaflet har i tilegg mange tilgjengelige utvidelser, veldokumentert API 18 og et eget direktiv i forhold til AngularJS. Foundation Vi ønsker å differensiere vår applikasjon fra Bootstrap sine tema. Vi ønsker å se nærmere på Foundation og vurderer sterkt å benytte det til utvikling av brukergrensesnittet. Foundation har gode verktøy for utvikling av ryddige brukergrensesnitt og har fokus på «mobile first». Selv om Foundation har mindre temautvalg enn Bootstrap vil det passe oss godt i forhold til vår oppgave. Konklusjon Slik det ser ut nå ønsker vi å bruke Leaflet for karttjenesten i applikasjonen, Foundation for å få et pent brukergrensesnitt og AngularJS til resten av «front end» utviklingen. Mer detaljert analyse om valg vi har tatt kommer i seksjon Produktet Produktet vil utvikles i to utviklingsprosjekter («back end» og «front end»). Hvor «back end» vil i all hovedsak omhandle Java, og «front end» vil ha fokus på AngularJS, Foundation og Leaflet som nevnt over. 6 Analyse av virkninger Målet med våre teknologivalg er at FFI får en solid, elegant og funksjonell applikasjon å teste sin sikkerhetsløsninger på ved CWIX 2015 og senere øvelser. Samtidig ønsker vi et stort læringsutbytte. Løsningene vi har valgt vil få oss ut av komfortsonen og vi vil bli nødt til å sette oss inn i mye nytt. 6.1 «Front end» Vi ønsker å velge et rammeverk for «front end» som vi kan benytte til å oppfylle alle oppgavens krav i forbindelse med brukergrensesnitt. CSS-rammeverk For CSS-rammeverk har vi sett på to mulige valg. Bootstrap - som vi kjenner godt fra før, og Foundation - som er nytt for oss. For å ta et valg har vi sett på de ulike mulighetene i rammeverkene, se figur 1 på neste side. 18 Application Programming Interface 8

10 Det er vanskelig å se en klar vinner av de to «front end»-rammeverkene. Både Bootstrap og Foundation har sine fordeler og ulemper, men det er på svært få punkter de utmerker seg i forhold til konkurrenten. Punktet som trekker mest opp for oss på dette tidspunktet er muligheten til å lage et unikt brukergrensesnitt, hvor Foundation er best. Vi har også brukt Bootstrap tidligere. For å utvide vår kompetanse vil det derfor denne gangen være nyttig å lære- og benytte Foundation. 6.2 «Back end» Java har vi kjennskap med fra før, men vi har ikke tidligere benyttet det i forbindelse med webapplikasjoner. Vi velger Java fremfor for eksempel C# (som vi har brukt tidligere) fordi vi ønsker erfaring på begge områder. Veilederne våre har tidligere benyttet seg av Java og kan gi oss gode innspill dersom vi får utfordringer underveis. 6.3 Applikasjonsserver Veileder benytter seg av både TomCat og GlassFish. Vår oppdragsgiver legger ingen føringer på hvilke applikasjonsserver vi skal benytte. Vi har vurdert TomCat, GlassFish, TomEE og JBoss. GlassFish og JBoss JavaEE applikasjonsservere, relativt tunge ressursmessig Et must dersom applikasjonen krever full JavaEE støtte TomCat En HTTP server som støtter Java servlets og JSP spesifikasjonene. Figur 1: Sammenligning av Bootstrap og Foundation 9

11 Vesentlig «lettere» ressursmessig, men også lettere å sette opp, konfigurere og administrere Vårt valg falt på TomCat, da våre veiledere mener at den applikasjonen vi skal utvikle ikke har behov for full JavaEE støtte, og derfor vil TomCat være det mest fornuftige valget. 10

12 Referanser [1] Trude Hafsøe Bloebaum og Frank T. Johnsen. CWIX 2014 core enterprise services experimentation, nov [2] Ketil Lund, Trude Hafsøe, Frank T. Johnsen, Espen Skjervold og Anders Eggen. Information exchange in heterogeneous military networks, dec [3] Vincenzo de Sortis. NFFI service interoperability profile 3 (sip3) technical specifications. (1.1.5). 11