Göm menyn

Laboration 3 - Säkerhet

Alla laborationer görs i par, och alla studenter måste registrera sig i Webreg

Syfte

Laborationen ämnar hjälpa studenten att uppfylla följande mål.

Lärandemål - Gäller TDP024

Från kursplanen: Kursplan
  • redogöra för ramverk/mönster för att utveckla affärssystem (enterprise applications)
  • redogöra för principerna för service-oriented architecture (SOA)
  • reflektera över egen programutveckling inom området och diskutera alternativa lösningar

Programmål - Gäller IP

Från utbildningsplan: Utbildningsplan
  • ämne: principiell kunskap som ingår som en del i den vetenskapliga teoribyggnaden runt programmering och datorer, främst inom den datavetenskapen
  • teknik: kunnande om den teknik som finns för programmering och datorer, med fokus på programmeringsspråk och plattformar.

Examensmål - Gäller Kandidatexamen

Från examensordning: Examensordning
  • visa förmåga att söka, samla, värdera och kritiskt tolka relevant information i en problemställning samt att kritiskt diskutera företeelser, frågeställningar och situationer
  • visa förmåga att självständigt identifiera, formulera och lösa problem samt att genomföra uppgifter inom givna tidsramar
  • visa förmåga att muntligt och skriftligt redogöra för och diskutera information, problem och lösningar i dialog med olika grupper

Säkerhet

Disclaimer 1

Att säkra en SOA tjänst är inte en lätt uppgift, och kräver fördjupade kunskaper som skulle kunna fylla en hel kurs i sig. Därför kommer vi inte att påstå att den lösning ni utvecklar för säkerhet i denna laboration är "säker". Tanken med laborationen är att ge er en inblick i säkerhet, som kanske väcker intresse för vidare studier.

Disclaimer 2

Denna laboration är tänkt som självstudier för studenter som har intresse av att fördjupa sig i SOA tjänster. Kursledningen förväntar sig därför att studenterna själva löser laborationen med ingen eller minimal handledning. Denna självständighet är också en del av målen från examensordningen.

Introduktion

Tjänsten som utvecklats genom laboration 1 och 2 är helt öppen för vem som helst att anropa. Dessutom finns ingen kontroll på vem som får göra vad med vilka konton. Det första problemet kommer vi att arbeta med här, inte det andra.

Ni skall implementera ett system som kontrollerar att den som anropar tjänsten har rätt att använda tjänsten. Detta skall göras genom en metod som ofta kallas HMAC. Tänk på att vi bara vill att ni hanterar tillgång till hela tjänsten (dvs ni behöver inte hantera att person A har rätt att ändra konto B). Om person A har tillgång till tjänsten får person A göra vad den vill.

För att göra detta skall ni följa instruktionerna i denna artikel: Designing a Secure REST (Web) API without OAuth (Om inte artikeln finns tillgänglig finns den här som PDF: pdf).

Ni skall fortfarande följa den arkitektur som använts i tidigare laborationer: program to an interface, test driven development, entities, facades, etc.

Datalagret skall aldrig behöva oroa sig över om den som anropar har korrekt rättigheter. Datalagret antar alltid att den som anropar har rätt att använda dess metoder. Logiklagret behöver inte anropas av webblagret, utan skulle kunna användas av andra program eller system. Därför blir det omständigt om säkerhet som är anpassad till webben tas hand om i logiklagret, eftersom det inte är alla anrop som kommer från webben. Det blir således webblagrets uppgift att ta hand om säkerheten i vårt fall. Datalagret och logiklagret får dock gärna användas för att hantera nycklar och/eller andra nya metoder, men de metoder som era facader hade i laboration 1 och 2 bör inte ändras (dvs era existerande tester för data och logik bör inte ändras, dock kanske det tillkommer nya tester).

Krav på lösning

  • Lösningen skall följa instruktionerna i given artikel och i detta laborationsmaterial.
  • Nycklar etc. skall sparas i databasen, inte några hårdkodade nycklar.
  • Existerande tester för ert logik och datalager skall inte ändras, dock kanske nya måste tillkomma.
  • Sonar skall inte anmärka på några fel i koden.
  • Tester skall skrivas och code coverage skall vara 100% (eller motivera varför det inte är det).
  • Projektet och koden skall bli godkänd genom en manuell genomgång av kursledningen.

Sidansvarig: infomaster
Senast uppdaterad: 2013-08-30