1. No category

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
Innhold
1 Presentasjon
1.1 Oppdragsgiver . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Oppgave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
3
2 Sammendrag
3
3 Dagens situasjon
4
4 Mål
4.1
4.2
4.3
og rammebetingelser
Mål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Teknologier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rammebetingelser . . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
5
5
5 Løsninger
5.1 Utvikling «back end» . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Utvikling «front end» . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Produktet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
6
7
8
6 Analyse av virkninger
6.1 «Front end» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 «Back end» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Applikasjonsserver . . . . . . . . . . . . . . . . . . . . . . . . . .
8
8
9
9
Referanser
11
1
1
Presentasjon
Oppdragsgiver
Forsvarets forskningsinstitutt (FFI)
Prosjekttittel
Common Operational Picture Secured
Oppgave
Webapplikasjon som forstår, dynamisk
presenterer- og gir tilgang på
differensiert informasjon basert på informasjon
om brukeren og vedkommendes rettigheter
Periode
Gruppenummer
Gruppemedlemmer
Talsmann
05.01.2015 - 26.05.2015
1
Erik Haider Forsén, s188086
Ole Gunhildsberg Hansen, s188114
Erlend Kristoffer Rognes, s188087
Julie Hill Roa, s188103
Erlend Kristoffer Rognes
Intern veileder
Ismail Hassan
Eksterne veiledere
Frank Trethan Johnsen,
[email protected],
+47 63 80 79 60
Trude Hafsøe Bloebaum,
[email protected],
+47 63 80 74 31
Prosjektside
1.1
http://hov.forsen.no
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 NATO1 .
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
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 2.02 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å XML3 . 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,
SOA5 . 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 2.0
Markup Language
4 NNEC - Nettverksbasert Forsvar
5 Service Oriented Architecture
3 eXtensible
3
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 NCIA7 og partnernasjoner der målet
var utvikling og verifisering av FMN8 -relaterte interoperabilitetsspesifikasjoner
for sentrale infrastrukturtjenester. I 2015 skal de videreføre denne forskningen og
bygge på resultatene fra 2014. 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 2015. 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, SOAP9 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 eXer-
cise
7 NATO
Communications and Information Agency
Mission Networking
9 Simple Object Access Protocol
8 Federated
4
• 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)
• LATEX
• 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 NIEM12
10 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 http://release.niem.gov/niem/3.0/
5
• 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
«deploye» prosjektet mot TomCat. Fungerer godt i IntelliJ IDEA, som er vårt
forløpig valg av IDE13 .
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 HTTP14
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 MVC15 -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
HTML516 og CSS317 på moderne nettlesere, samtidig som det er lett tilgjengelig
på eldre versjoner.
13 Integrated
Development Environment
Transfer Protocol
15 Model-View-Controller
16 HyperText Markup Language versjon 5
17 Cascading Style Sheets versjon 3
14 HyperText
7
Leaflet har i tilegg mange tilgjengelige utvidelser, veldokumentert API18 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 6.
5.3
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
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
– 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
Referanser
[1] Trude Hafsøe Bloebaum og Frank T. Johnsen. CWIX 2014 core enterprise
services experimentation, nov 2014.
[2] Ketil Lund, Trude Hafsøe, Frank T. Johnsen, Espen Skjervold og Anders
Eggen. Information exchange in heterogeneous military networks, dec 2009.
[3] Vincenzo de Sortis. NFFI service interoperability profile 3 (sip3) technical
specifications. (1.1.5).
11