1177 Vårdguiden (exempel)
2014-01-31
Center för eHälsa i samverkan
Hornsgatan 20, 118 82 Stockholm
Vxl: 08-452 70 00
ARK_0014
CeHis AR
Dokuemnt: ARK_0014
www.cehis.se
[email protected]
1 (24)
2014-01-31
7 (51)
1177 Vårdguiden (exempel)
SAD - Systemarkitekturdokumentation
Version1.0.7
2014-02-25
Innehåll1Inledning61.1Syfte71.2Målgrupp71.3Referenser81.3.1Styrande
dokument91.3.2Stödjande dokumentation92Arkitekturell
översikt102.1Arkitekturella mål102.1.1Mål102.1.2Planerade
avsteg102.2Prioriterade områden102.3Översikt112.3.1Översikt och
mål122.3.2Övergripande teknisk lösning132.3.3Övergripande principer
för lösningens utformning132.3.4Signifikanta delar av
lösningen143Följsamhet till T-boken183.1Följsamhet mot T-bokens
styrande principer183.1.1IT2: Informationssäkerhet183.1.2IT3:
Nationell funktionell skalbarhet193.1.3IT4: Lös koppling203.1.4IT5:
Lokalt driven e-tjänsteförsörjning213.1.5IT6: Samverkan i
federation234Användningsfall254.1Användningsfall –
Översikt254.2Aktörsinformation264.2.1Artikellager264.2.2Granskare264.2.3HSA264.2.4Invånare264.2.5Redaktör264.2.6SITHS264.2.7Syndikeringskonsument264.2.8Systemadministratör264.3Logisk
realisering
användningsfall274.3.1Autentisering274.3.2Behörighetshämtning284.3.3Ytterligare
användningsfall305Icke-funktionella krav315.1Icke-funktionella krav
från
verksamheten315.1.1Svarstider315.1.2Tillgänglighet315.2Icke-funktionella
krav från Systemägaren/Förvaltaren315.2.1Test (endast
exempel)325.2.2Konfigurationsstyrning325.2.3SLA-övervakning325.2.4Visning
av driftsstatus326Teknisk lösning336.1Beskrivning av arkitekturellt
signifikanta delar av lösningen336.1.1Komponentmodell (nivå
2)336.1.2Designmönster346.1.3Autentisering och
behörighet346.1.4Siteramverk366.1.5Integration med
HSA366.1.6Ytterligare signifikant del av lösningen366.1.7Tjänstens
hantering och användning av
informationsmängder366.1.8Felhantering376.1.9Tekniska
ramverk377Säkerhet387.1Övergripande387.2Säkerhetsklassificering av
information387.2.1Rekommendation387.3Riskanalys397.4Riskminimering
i den tekniska lösningen397.4.1Principer för utveckling av säker
programkod397.5Infrastruktursäkerhet417.6Intrångsskydd417.7Insynsskydd
(kryptering)417.8Transportoförvanskning.427.9Presentationskorrekt427.10Dataintegritet
(Oförvanskat över tid), riktighet427.11Autentisering (”stark” vid
behov enligt infoklassning)427.12Implementerad
Signering427.13Lagkrav ex. spärrhantering427.14Spårbarhet
(loggning)438Nyttjade integrationstjänster459Nyttjade
plattformsfunktioner4610Informationshantering4710.1Domäninformationsmodell4710.2Informationsflöde4710.3Informationens
ursprung4710.3.1Information som konsumeras4810.3.2Information som
skapas4811Driftaspekter4911.1Lösningsöversikt4911.2Fysisk
miljö4911.3Programvaror4911.4Detaljerad
information5011.4.1Tillämpning av ickefunktionella krav på teknisk
tillgänglighet5011.4.2Tillämpning av ickefunktionella krav på
prestanda5111.5Produktionssättning och överlämning till
förvaltning51
Figurer
Figur 1: Webbplatsens startsida6
Figur 2: Artikellayout och redigering av artikel7
Figur 3: Söktjänst samt Hitta och jämför vård7
Figur 4: Schematisk systemöversikt för tjänsten11
Figur 6: Megameny15
Figur 8: Schematisk (förenklad) användningsfallsöversikt för
1177 Vårdguiden25
Figur 12: Sekvensdiagram – Autentisering28
Figur 13: Sekvensdiagram – Behörighetshämtning30
Figur 16: Komponentmodell – nivå 2 (tjänstens ansvarsområden med
komponenter)33
Figur 32: Övergripande domäninformationsmodell47
Figur 10: Översikt över tjänstens driftsmiljöer49
Inledning
1177 Vårdguiden omfattar tre huvudområden: webbplats,
redaktörsfunktioner (inkl. Redaktionellt innehåll) samt
e-tjänster.
Detta dokument är avgränsat att endast beskriva webbplatsen 1177
Vårdguiden. Tjänster som visas på webbplatsen, som exempelvis Hitta
och jämför vård, beskrivs i andra SAD-dokument.
Hösten 2013 gjordes en sammanslagning av 1177.se och Vårdguiden,
samtidigt som den integrerade tjänsten Hitta och jämför vård bröts
loss och blev en självständig tjänst. Resultatet av dessa
aktiviteter är den invånartjänst som går under namnet 1177
Vårdguiden.
Webbplats
Figur 1: Webbplatsens startsida
Redaktörsfunktioner och redaktionellt innehåll
Figur 2: Artikellayout och redigering av artikel
E-tjänster
Figur 3: Söktjänst samt Hitta och jämför vård
Syfte
Syftet med detta dokument är att beskriva detta system med dess
informationsmodeller, tjänster, plattformsfunktioner och
interaktioner.
Målgrupp
De huvudsakliga målgrupperna för detta dokument är: systemägare,
systemförvaltare, CeHis arkitekturgrupp, systemarkitekter och
utvecklingsteam (obligatoriskt: CeHis arkitekturgrupp).
Referenser
Referenser
Kategori
Referens
Dokument inom kategori
Plattformsbeskrivningar
P1
Organisationskatalog (HSA)
P2
EPiServer-dokumentation
http://www.episerver.com/sv/Products/EPiServer-CMS-6
http://www.episerver.com/sv/Products/EPiServer-CMS-6/Funktioner/
Tjänstekontraktsbeskrivningar
T1
Namn på dokument med tjänstekontraktsbeskrivning
Bilagor
B1
Arkitekturella beslut_1177 Vårdguiden.doc
B2
Namn på dokument som beskriver ickefunktionella krav
B3
Namn på annan bilaga …
Länkar
L1
https://code.google.com/p/skltp
L2
Designmönster: Model View Presenter
http://msdn.microsoft.com/en-us/magazine/cc188690.aspx
L3
Apache Log4Net
http://logging.apache.org/log4net/
L4
Designmönster: Circuit Breaker
http://timross.wordpress.com/2008/02/10/implementing-the-circuit-breaker-pattern-in-c/
L5
Behörighetstillämpning i EPiServer
http://sdk.episerver.com/library/CMS5/Developers
Guide/Membership and Role Providers
L6
ASP.NET: autentisering, behörighetstillämpning
http://weblogs.asp.net/scottgu/archive/2006/02/24/ASP.NET-2.0-Membership_2C00_-Roles_2C00_-Forms-Authentication_2C00_-and-Security-Resources-.aspx
L7
Principer för säker programutveckling
http://www.owasp.org/index.php/Secure_Coding_Principles
L8
Andra länkar …
Styrande dokument
Ref
Dokument ID
Dokument länk
S1
CeHis handlingsplan 2013-2018
http://www.cehis.se/images/uploads/Nyheter/Skrift_CeHis_handlingsplan_2013_2018_120615.pdf
http://www.cehis.se/arkitektur_och_regelverk/gemensam_arkitektur/
S2
T-boken
http://rivta.se/documents/ARK_0019
S3
RIV Tekniska Anvisningar
http://rivta.se/documents
Stödjande dokumentation
Ref
Dokument ID
Dokument/länk
R1
Domäninformationsmodell
Informationsspecifikation_1177 Vårdguiden.docx
R2
Tjänsteplattform
http://www.cehis.se/infrastruktur/tjansteplattform/
https://code.google.com/p/skltp
Arkitekturell översikt
Arkitekturella målMål
Utvecklingsprojektet har arbetat enligt följande mål för
utformning av arkitekturen:
· Följsamhet mot Nationella IT-strategin.
· Följsamhet mot gemensamma regler från CeHis arkitekturgrupp. I
detta mål ingår bl.a. att ta fram arkitekturdokumentation enligt
mallar från CeHis, som både stöttar projektet och granskar dess
arkitekturdokumentation. Se även det ickefunktionella kravet IFK-27
i bilaga B3.
· T-bok och RIV:s tekniska anvisningar (företrädesvis RIV TA
2.0, se referens S5).
· Följsamhet mot krav från Sjunet och HSA. Följsamhet mot dessa
krav är en förutsättning för att få tillåtelse att integrera mot
HSA via Sjunet. Se även Arkitekturellt beslut AB-2.5 i bilaga
Bx.
· Följsamhet mot ickefunktionella krav på tjänsten. Kraven
beskrivs i ett separat dokument (se bilaga Bx).
· Arkitektur- och designmönster ska användas. Syftet är att
skapa en genomtänkt och konsekvent tillämpad lösning som
underlättar återanvändbarhet och vidareutveckling. Detta är viktigt
med tanke på att 1177-projektet är nationellt och att
tjänsteutveckling för dess plattform ska kunna bedrivas av flera
aktörer.
· Samtliga inloggade användare ska vara autentiserade med hjälp
av SITHS-kort.
Planerade avsteg
De planerade avsteg som görs från nationella riktlinjer är
följande:
· Avsteg och deras konsekvenser beskrivs översiktligt
Prioriterade områden
Utöver de arkitekturella målen så har även följande områden
identifierats som prioriterade för 1177 Vårdguiden: säkerhet,
integration och prestanda. Mer om dessa områden beskrivs i andra
kapitel i detta dokument.
Översikt
Figur 4: Schematisk systemöversikt för tjänsten
Webbplatsen visar en mindre mängd e-tjänster, men är utformad
för att kunna utökas med fler e-tjänster över tiden. Hitta och
jämför vård är en av de e-tjänster som visas på 1177
Vårdguiden.
Säkerhetslösningar berör alla delar av systemet.
SITHS används i behörighetslösningen för inloggning, närmare
bestämt vid autentisering av redaktörer och systemadministratörer.
Denna autentisering baseras på certifikat på SITHS-kort.
Den syndikering som visas på bilden ovan är den hittills enda
tjänst som exponeras från 1177 Vårdguiden. Detaljer om tjänsten
beskrivs i separat kapitel.
Integrationen med APSIS används för administration och utskick
av nyhetsbrev. Dessa nyhetsbrev samt e-postadress till
prenumeranterna lagras hos APSIS, och anmälningsformulär för att få
nyhetsbrev finns på 1177 Vårdguiden (skapas och publiceras från
redaktörsgränssnittet).
På 1177 Vårdguiden publiceras anmälningssidor som
prenumeranterna använder för att anmäla att de vill få nyhetsbrev.
Dessa anmälningssidor skapas och publiceras från 1177 Vårdguidens
redaktörsgränssnitt. Varje sådan anmälningssida är kopplad till ett
APSIS-id som gör att anmälningar kopplas till rätt utskick.
Av integrationerna för 1177 Vårdguiden så är några särskilt
värda att nämnas.
· Hitta och jämför vård är en e-tjänst som tidigare var delvis
ihopbyggd med 1177. Den är numera fristående, och visas upp på 1177
Vårdguiden via den klientapplikation (Hittavard.Client.dll) som
tillhandahåller metoder för att kommunicera och hämta innehåll
(HTML) från hitta vårds webbplats/API
· 1177 Vårdguiden hämtar alla enheter från Hitta vårds API
(publikt namn, landstingstillhörighet, hsaid) mha ett
EPiServer-importjobb som körs en gång per dygn och resultatet
lagras i 1177 Vårdguidens databas. Den hämtade informationen
används primärt för URL-hantering på 1177 Vårdguiden för
kontaktkorten från Hitta vård men också för generering av sitemap
för indexering av SiteSeeker/Google
· Självtester huseras i separat webbapplikation
(selftest.1177.se), men visas upp på 1177 Vårdguiden genom
Iframe-integration
· Rådgivningstödet (RGS) prenumererar på notifiering om
förändringar i artikelutbudet, och hämtar förändringar efter
notifiering
· Länkar till bloggar i 1177-sfären (blog.1177.se) sker via puff
på 1177 Vårdguiden. Dessa bloggar indexeras av sökmotorn (via
sitemap-länkar till bloggarna) så att de kan hittas via
sökfunktionen på 1177 Vårdguiden
Översikt och mål
Detta är en förenklad systemöversikt över 1177 Vårdguiden. I
stora drag innehåller systemet tre huvuddelar:
· Webbplats med redaktionellt innehåll
· Redaktörsfunktioner (används för att skapa och publicera
redaktionellt innehåll)
· Visning av e-tjänster på webbplatsen.
Webbplats och redaktörsfunktioner är starkt ihopkopplade genom
att redaktörsfunktionerna används vid det redaktionella arbetet med
webbplatsens struktur och innehåll. E-tjänsterna är mer frikopplade
från webbplats och redaktörsfunktioner genom att de inte är
beroende av dessa. Sambandet mellan e-tjänsterna och de andra två
områdena består i att redaktörsfunktionalitet används för att
konfigurera platshållare för e-tjänsterna på sidor som visas på
webbplatsen.
1177 Vårdguiden tillhandahåller både egen information, för
närvarande främst medicinskt granskade artiklar och webbplatsens
navigering/struktur, samt information som produceras inom ramen för
de e-tjänster som är tillgängliga via 1177 Vårdguiden. På sikt är
det tänkt att det ska tillkomma många nya e-tjänster som
tillgängliggörs via webbplatsen, för såväl vårdpersonal som
invånare.
Ett övergripande arkitekturellt mål för 1177 Vårdguiden är att
både konsumera och exponera tjänster via den nationella
tjänsteplattformen. När denna version av 1177 Vårdguiden togs i
drift så finns ingen sådan integration implementerad, men
utformningen av systemet är gjord bl.a. med tanke på att det ska
vara enkelt att komplettera med integration mot
tjänsteplattformen.
Mönster som används i utformningen av lösningen beskrivs separat
i kapitlet Logisk arkitektur.
Övergripande teknisk lösning
Webbplats med redaktionellt innehåll
Denna del av lösningen baseras till stor del på EPiServers
redaktörs- och publiceringsfunktionalitet, med viss komplettering i
.NET.
Redaktörsfunktioner
De redaktionella funktionerna för redigering och publicering av
artiklar baseras på EPiServers redaktionella funktioner, med vissa
egenutvecklade anpassningar. Redaktörsfunktionerna har en stark
koppling till webbplatsens innehåll.
E-tjänster
Förutom att visa redaktionellt innehåll så exponerar webbplatsen
e-tjänster i invånargränssnittet. De e-tjänster som är framtagna
vid tidpunkten för driftsättning av den nya versionen av 1177
Vårdguiden är utvecklade med lite olika tekniska lösningar.
Söktjänsten baseras på sökmotorn SiteSeeker i kombination med
för webbplatsen utvecklade sidor för sökning och träfflistor. Läs
mer om tjänsten i avsnittet om söklösning.
Övergripande principer för lösningens utformningPrincip:
samverkan med externa system
Beskriv
Signifikanta delar av lösningen
Integration (konsumtion och exponering)
1177 Vårdguiden har integrationer mellan plattformen och externa
tjänster. För de flesta av dessa integrationer gäller att 1177
Vårdguiden är konsument till tjänsterna. Den enda
producentintegration som erbjuds av plattformen är den så kallade
syndikeringen, dvs. exponering av artiklar via ett Atom-format. Mer
om denna integration beskrivs i separat avsnitt i detta
dokument.
Utökning med fler systemintegrationer bör i första hand ske via
den nationella tjänsteplattformen, baserat på nationella
tjänstekontrakt. Alla avsteg från detta ska motiveras i form av
arkitekturella beslut, som ska granskas av CeHis arkitekturgrupp. I
de fall där 1177 Vårdguiden i framtiden kommer att agera producent
så bör det tas fram nationella tjänstekontrakt som helst
tillgängliggörs via den nationella tjänsteplattformen.
Det finns både nationella riktlinjer (se exempelvis CeHis T-bok)
och ickefunktionella krav (IFK-25 och delvis även IFK-22) som
ställer krav på integrationer. Dessa krav har beaktats vid
utformningen av 1177 Vårdguiden, men hittills har ingen
tjänstekonsumtion kunnat göras via den nationella
tjänsteplattformen av anledningen att de tjänster som konsumeras
(ännu) inte exponeras via tjänsteplattformen. Det bör vara en
långsiktig strävan att dessa integrationer på sikt tillgängliggörs
via nationella tjänstekontrakt som helst bör vara åtkomliga via
tjänsteplattformen.
Navigering
Temaområden byggs primärt upp av sidtyperna Fokussida, Behållare
– fokusartikel, Fokuslista A-Ö, Fokusartikel och Fokusartikel
enkel. Roten för ett temaområde är alltid en Fokussida, vars
sidnamn blir temaområdets namn och visas högst upp på alla sidor
som tillhör temaområdet. Fokussidor kan också ha högerspalter.
Varje Fokussida kan ha andra fokussidor, Behållare –
Fokusartikel, Fokuslista A-Ö som barn. Fokussidor är alltså
”rekursiva” i någon mening. Däremot renderas en Fokussida som inte
är roten i ett fokusområde något annorlunda än en fokussida på
rotnivå.
Behållare för fokusartiklar används för artiklar som ska finnas
under ett fokusområde. De visas som en del av en fokussida men har
ingen egen visuell representation, d.v.s. det är inte tänkt att en
besökare ska kunna klicka sig fram till en behållare för
fokusartiklar. Under en behållare ligger fokusartiklar eller enkla
fokusartiklar. Dessa kan antingen ha ett ”eget” innehåll eller
spegla artiklar och enkla artiklar. Fokusartiklar och enkla
fokusartiklar har exakt samma egenskaper och funktionalitet som
artiklar och enkla artiklar men med extra egenskaper för bilder och
text som visas på fokussidor.
Ytterligare beskrivning …
· Megameny
Den så kallade Megamenyn är en översiktsmeny som visas som en
del av sidhuvudet. Megamenyn visar en översiktsmeny per
område/kategori. Exempel på områden är: Fakta och råd, Regler och
rättigheter, Temasidor, Hitta och jämför vård.
Figur 6: Megameny
Respektive megamenys innehåll fylls dynamiskt med de
artikelkategorier som hör till artiklarna som ingår i strukturen i
respektive megameny. Det innebär att nya artikelkategorier
automatiskt kommer att visas i megamenyn utan vare sig utvecklings-
eller konfigurationsarbete. Det redaktionella materialet styr
megamenyns innehåll.
Konfiguration av de kategorier som ingår i respektive megameny
görs av behörig redaktör i respektive megamenys inställningsflik i
redigeraläget i EPiServer.
Kopplingen mellan de element som fyller megamenyn är följande:
Megameny > Navigeringssidor > Artikelbehållarsidor >
Artikelsidor > Artikelkategorier
· Megameny: programmerad klass som har samlar in och visar
megamenyns innehåll
· Navigeringssida: sida som i adminläget konfigureras med
koppling till artikelbehållarsidor
· Artikelbehållarsida: sida som har artikelsidor under sig i
EPiServers strukturträd. Hanteras i redigeraläget.
· Artikelsida: sida som innehåller en artikel. Sidan är
konfigurerad att peka på artikelkategorier. Även denna hanteras i
redigeraläget.
· Artikelkategori: konfigurerbara hierarki av kategorier och
underkategorier. Kategorierna redigeras i adminläget.
Exempelvis innehåller megamenyn Fakta och råd indelningen
Sjukdomar, Behandlingar, Undersökningar, Råd om läkemedel, Om
läkemedel. Dessa kategorier finns i EPi-strukturen i form av
artikelbehållarsidor.
URL-format
URL-formatet är uppbyggt enligt följande:
domän/regionstillhörighet/kategori/…Om nationell nivå är vald så är
regionstillhörigheten tom, vilket ger format: domän/kategori/…
Exempel på
URL-format:https://www.1177.se/Fakta-och-rad/Sjukdomar/Astma/https://www.1177.se/Kalmar/Fakta-och-rad/Sjukdomar/Astma/
Automatisk synlighet i menyer
Normalt är de sidor som är lagrade i EPiServers sidträd
automatiskt synliga på webbplatsen om de är publicerade. Det finns
ett undantag, och det gäller de sidor som är lagrade under de
regionala startsidorna. Det räcker inte att publicera dem för att
de ska bli synliga, det måste skapas länkar till dem för att de
automatiskt ska visas i menystrukturen (se beskrivning av
megamenyn). Det ska också tilläggas att dessa sidor kommer att
indexeras, vilket gör att de kan hittas och visas genom sökning,
även om de inte syns i någon meny. Det är naturligtvis också
möjligt att länka till dem på alla ställen på webbplatsen som
tillåter länkning till artikelsidor.
Söklösning
Söklösningen använder sökmotorn SiteSeeker. Valet av SiteSeeker
baseras dels på en strävan att återanvända befintlig kod och
kunskap och dels på att förvaltningen har ett nyttjandeavtal med
Euroling rörande SiteSeeker. Se även Arkitekturellt beslut AB-2.7 i
bilaga Bx (Hitta och jämför vård) samt IFK-21 i bilaga By.
SiteSeeker utför indexering, tillhandahåller sök-API (i form av
en Web Service) samt skapar statistik. 1177 VG:s
EPiServer-instanser har kompletterats med en modul som används vid
kommunikation med SiteSeeker.
Indexering sker schemalagt av SiteSeeker, som crawlar
Vårdsökstjänstens publika kontaktkortssidor. Crawlning av
kontaktkorten sker via http-anrop. Se även Arkitekturellt beslut
AB-2.9 i bilaga Bx (Hitta och jämför vård).
Regionalisering
Regionalisering av webbplats med innehåll ger användarna en
möjlighet att få ta del av regionalt anpassad information och ett
regionalt tjänsteutbud. Med region avses både region/landsting och
nationell nivå.
Användarna kan göra ett övergripande regionsval som påverkar
hela webbplatsens innehåll och tjänsteutbud. Det är också möjligt
att i vissa tjänster kunna se information från annan region än den
som valts för webbplatsen, exempelvis kan man välja ett visst
landsting för webbplatsen, och genom ett regionsval i
vårdsöktjänsten söka vårdgivare i annat landsting.
Läs mer om implementation av regionalisering i kapitlet ”Logisk
arkitektur”
Integration med informationskällor
All information som tillgängliggörs av tjänsten kommer från
externa informationskällor som är integrerade med tjänsten. För
närvarande (juni 2013) konsumerar tjänsten information från
följande externa informationskällor:
· HSA
· Tandvårdsadmin (internt system som ingår i 1177-sfären)
Ytterligare beskrivning …
Samverkan med HSA
Kommunikationen med HSA, över Sjunet, sker via den befintliga
kommunikationsväg som tagits fram för 1177 Vårdguiden. Information
hämtas från HSA via dess Web Servicegränssnitt.
Söklösning
Söklösningen bygger på användning av Open Source-sökmotorn
Elasticsearch, som ingår i tjänstens infrastruktur. Sökmotorn
används internt av tjänsten för att erbjuda möjlighet till sökning
via tjänstens webbapplikation och/eller via tjänstens API.
Indexering av sökbar information sker inledningsvis sporadiskt
och manuellt. Detta kommer att schemaläggas innan tjänsten tas i
drift. Den mest förekommande indexeringen är tänkt att endast
omindexera förändrat data, vilket ska ske händelsestyrt när
enhetsinformation ändras i dess källa. Det är också tänkt att
fullständig omindexering ska ske schemalagt.
Följsamhet till T-bokenFöljsamhet mot T-bokens styrande
principer
En förutsättning för att kunna besvara nedanstående principer är
att reda ut om HSA:s Web Service ska betraktas som ett nationellt
(standardiserat) tjänstekontrakt eller ej. Kontakt har tagits både
med HSA:s förvaltning och 1177 Vårdguidens förvaltning av
tjänstekontrakt. Diskussion med dessa kontakter har lett till
kunskapen att HSA:s Web Service INTE ska betraktas som ett
nationellt tjänstekontrakt. Nedanstående principer är besvarade med
detta som förutsättning.
IT2: Informationssäkerhet
Förutsättningar att uppfylla
Uppfyllnad
Verksamhetskritiskt IT-stöd designas för att möta verksamhetens
krav på tillgänglighet vid frånfall av ett externt beroende. Ju
fler beroenden till andra komponenters tillgänglighet, desto lägre
egen tillgänglighet.
Detta tillämpas genom lokal mellanlagring av sådan information
som är kritisk för vitala delar av 1177 Vårdguiden. Konkret så
innebär det att det sker mellanlagring av HSA-information för att
säkra att inloggning till redaktörsgränssnittet har önskad
tillgänglighet.
Verksamhetskritiska nationella stödtjänster (t.ex. tillgång till
behörighetsstyrande information) erbjuder möjlighet till lokala
instanser som med tillräcklig aktualitet hålls uppdaterade med
nationell master.
Uppdatering av mellanlagrad information sker så ofta att
informationen är tillräckligt aktuell för att funktionalitet som är
beroende av informationen fungerar på ett tillfredsställande sätt.
Uppdatering sker minst dygnsvis.
Krav mellan integrerande parter regleras genom
integrationsavtal. Integrationsavtal är det avtal där
informationsägaren godkänner att en ett visst system får agera mot
information genom ett visst tjänstekontrakt. Exempelvis skall
enligt integrationsprocessen för den nationella tjänsteplattformen
ett avtalsnummer för ett integrationsavtal registreras i samband
med att man "öppnar dörren" för en viss tjänstekonsument mot en
viss kombination av informationsägare och tjänstekontrakt.
Tillämpas för HSA-integrationen genom HSA:s dokument HSA Policy
Tillämpning (HPTB)
Arkitekturen måste möjliggöra tillräcklig tillgänglighet vid
flera samverkande system.
Tillämpas genom att tillgodose krav rörande teknisk
tillgänglighet. Dessa krav tillgodoses bl.a. genom mellanlagring av
information som är kritisk för viktig funktionalitet, samt att
felhanteringsrutiner har anpassats för att nyttja mellanlagrad
information vid kommunikationsstörningar.
En sammantagen tolkning av tillämpliga lagar och förordningars
konsekvenser för teknisk realisering av informationsfångst, utbyte
och lagring.
Tillämpas där så är lämpligt för denna tjänst
Förutsättningar för spårbarhet etableras i form av
loggningsregler för komponenter som deltar i säkert
informationsutbyte.
Loggning tillämpas. Detta beskrivs senare i detta dokument
Interoperabla, internationellt beprövade och för leverantörer
tillgängliga standarder tillämpas för kommunikation mellan parter
som har upprättat tillit.
Tillämpas genom användandet av ATOM-format i
syndikerings-tjänsten
IT3: Nationell funktionell skalbarhet
Förutsättningar att uppfylla
Uppfyllnad
Nationella tjänstekontrakt definieras med nationell täckning som
funktionell omfattning. Det är möjligt för ett centraliserat
verksamhetssystem som användas av alla verksamheter i Sverige att
realisera varje standardiserat tjänstekontrakt. Det får inte finnas
underförstådda funktionella avgränsningar till regioner, kommuner,
landsting eller andra organisatoriska avgränsningar i nationella
tjänstekontrakt.
Ej tillämpbar, inga nationella tjänstekontrakt används
SLA ska definieras för varje tjänstekontrakt. Detta SLA ska ta
hänsyn till framtida kapacitet för tjänstekontraktet med avseende
på transaktionsvolym, variationer i användningsmönster och krav på
tillgänglighet, i kombination med förmåga till kontinuerlig
förändring.
Ej tillämpbar, inga nationella tjänstekontrakt används
Integration ska ske över en integrationsinfrastruktur (t.ex.
virtualiseringsplattform) som möjliggör uppföljning av
tjänsteproducenters fullföljande av SLA.
Integration med HSA sker via Sjunet. Denna integration beskrivs
senare i detta dokument.
System och e-tjänster som upphandlas kan utökas med fler
organisationer som kunder utan krav på infrastrukturella ingrepp
(jämför s.k. SaaS)
Detta tillämpas i syndikeringstjänsten genom att den
tillhandahåller ett gränssitt som är gemensamt för samtliga
syndikerings-konsumenter
IT4: Lös koppling
Förutsättningar att uppfylla
Uppfyllnad
Meddelandeutbyte baseras på att kommunikation etableras utgående
från vem som äger informationen som ska konsumeras eller berikas,
inte vilket system, plattform, datalager eller tekniskt gränssnitt
som informationsägaren för stunden använder för att hantera
informationen. Genom centralt administrerad förmedlingstjänst
skapas lös koppling mellan informationskonsument och
informationsägarens tekniska lösning.
Delvis tillämpat genom att information från HSA hämtas från
kommunikation med HSA:s Web Service
En arkitektur som skapar lös koppling mellan konsumenter och
producenter, avseende adressering och standarder för
kommunikation.
Tillämpas i syndikerings-tjänsten, genom dess publika gränssnitt
och genom att ATOM-formatet används
En nationell integrationspunkt ska kunna erbjudas för varje
nationellt standardiserat tjänstekontrakt, som en fasad mot
bakomliggande brokiga systemlandskap.
Ej tillämpbar, inga nationella tjänstekontrakt används
Nationella tjänstekontrakt förvaltas i en nationellt koordinerad
förvaltning.
Ej tillämpbar, inga nationella tjänstekontrakt används
För en process inom vård och omsorg kan flera tjänstekontrakt
ingå. Därför är det viktigt att alla tjänstekontrakt baseras på en
gemensam referensmodell för informationsstruktur.
Ej tillämpbar, inga nationella tjänstekontrakt används
Parter som samverkar i enlighet med arkitekturen integrerar med
system hos parter som lyder under annan styrning (t.ex.
myndigheter, kunder och leverantörer). Det kan leda till att vård-
och omsorgsgivare antingen:
oNationellt bryggar informationen (semantisk översättning)
eller
oNationellt införlivar externt förvaltat tjänstekontrakt som
standard.
Observera att semantisk bryggning av information till vårdens
referensmodell förutsätter en nationell förvaltning av
bryggningstjänster.
För att införliva ett externt förvaltat tjänstekontrakt
förutsätts en transparent, robust och uthållig
tjänstekontraktsförvaltning hos den externa parten.
Ej tillämpbart då ingen sådan samverkan förekommer
Befintliga system behöver anpassas till nationella
tjänstekontrakt. Detta kan göras av leverantörer direkt i
produkten, eller genom fristående integrationskomponenter
(”anslutningar”). En anslutning bör ligga nära (logiskt vara en del
av) det system som ansluts, oavsett om det är i rollen som
konsument eller producent för anslutningen som genomförs.
Ej tillämpbar, inga nationella tjänstekontrakt används
Interoperabla standarder för meddelandeutbyte tillämpas, så att
integration med till exempel en Web Service kan utföras utan att
anropande system behöver tillföras en för tjänsteproducenten
specialskriven integrationsmodul (s.k. agent).
Tillämpas i syndikeringstjänsten genom att ATOM-format
används
IT5: Lokalt driven e-tjänsteförsörjning
Förutsättningar att uppfylla
Uppfyllnad
När utveckling av källkod är en del av en tjänsteleverans skall
följande beaktas:
oAlla leveranser tillgängliggörs under öppen källkodslicens.
Valet av licensformer samordnas nationellt genom
rekommendationer.
oUtvecklingen bedrivs från start i en allmänt tillgänglig (över
öppna nätverk) projektinfrastruktur där förvaltningsorganisation
kan förändras över tiden inom ramen för en kontinuerligt
tillgänglig projektinfrastruktur (analogi: ”Projektplatsen för
e-tjänsteutveckling”).
oDet innebär full insyn och åtkomst för utvecklare till källkod,
versionshantering, ärendehantering, stödforum och andra element i
en projektinfrastruktur under projektets och förvaltningens hela
livscykel.
oUpphandlade e-tjänster fungerar på de vanligaste plattformarna
hos vårdgivarna och hos nationella driftspartners (Windows, Linux,
Unix) t.ex. genom att vara byggda för att exekvera på en s.k. Java
virtuell maskin.
oGemensam referensmodell för e-tjänsters interna uppbyggnad
stimulerar och förenklar återanvändning och överföring av
förvaltningsansvar mellan organisationer.
Hittills (januari 2014) har leveranser ej tillgängliggjorts som
öppen källkod. Arkitekturellt beslut (AB-2.14) har påbörjats för
att beskriva följsamheten mot denna princip.
Minsta möjliga – men tillräcklig – mängd standarder och
stödjande gemensamma grundbultar för nationella e-tjänstekanaler
säkerställer att även utvecklingsenheter i mindre organisationer
kan bidra med e-tjänster för en integrerad användarupplevelse och
att en gemensam back-office för anslutning av huvudmän till
e-tjänster finns etablerad. I den mån etablerade standarder med
bred tillämpning i kommersiella e-tjänster finns (t.ex. för
single-sign-on), bör de användas i syfte att möjliggöra upphandling
av hyllprodukter.
Tillämpas
Utveckling sker mot globalt dominerande portabilitetsstandarder
i de fall mellanvara (applikationsservrar) tillämpas. Det är
möjliggöraren för nyttjande av free-ware och lågkostnadsverktyg i
organisationer som inte orkar bära tunga licenskostnader för
komplexa utvecklingsverktyg och driftsplattformar.
Tillämpas delvis. Användning av .NET och publika mjukvaruramverk
stödjer detta, likaså syndikeringen som baseras på ATOM.
EPiServer används som publiceringsplattform har dock en
proprietär lösning i form av dess sidmallar som används för att
samla och visa innehåll i användargränssnittet
Nationell (eller regional – beroende på sammanhang vård/omsorg)
förvaltning är etablerad (t.ex. s.k. Portal Governance), med
effektiva processer för att införliva lokalt utvecklade e-tjänster
i nationella e-tjänstekanaler. Systematisk och effektiv allokering
av resurser för drift är en viktig grundförutsättning.
Detta tillämpas genom 1177 Vårdguidens förvaltningsorganisation,
som bl.a. innehåller tjänsteägare, utvecklingsansvarig och
webbförvaltare. Processer som används är bl.a. ITIL och PM3.
Genom lokal governance och tillämpning av det nationella
regelverket får lokala projekt den stöttning som behövs för att
från början bygga in förutsättningar för integration i samordnade
(t.ex. nationella) e-tjänstekanaler.
Ej tillämpbart för det nationella systemet 1177 Vårdguiden som
sådant. Detta angreppssätt bör tillämpas vid utveckling av tjänster
som ska tillgängliggöras via 1177 Vårdguiden
IT6: Samverkan i federation
Förutsättningar
Uppfyllnad
Att gemensamma gränssnitt i alla federativa utbyten finns
framtagna och beskrivna, vilket möjliggör kostnadseffektiva och
leverantörsneutrala lösningar.
Dokumentation om syndikeringsgränssnittet finns tillgänglig via
1177 Vårdguiden
Det behövs organ och processer för att godkänna utgivare av
elektroniska identitetsintyg och certifikat som är giltiga i
federationen.
Detta tillämpas för de certifikat som används för autentisering
(SITHS)
Aktörer i olika nät, inklusive öppna nät ska vara välkomna i
elektronisk samverkan genom att samverkande komponenter är
säkra.
Tillämpas genom 1177 Vårdguidens samverkan med HSA, vilken
innebär att Internet-trafik på ett säkert sätt hämtar information
från HSA via Sjunet
Att Ingående parter i federationen är överens om ett antal
gemensamma ståndpunkter:
oatt stark autentisering likställs med 2-faktors
autentisering
oatt vid samverkan acceptera följande metoder för stark
autentisering; eID, PKI med lagring av nyckelpar på SmartCard eller
motsvarande och metoder baserade på engångslösenord, antingen
genererade i en fysisk enhet eller säkert distribuerad till fysisk
enhet
oatt tillämpa en gemensam certifikat- och utfärdarpolicy,
likvärdig med SITHS, som ett minimikrav för egen eller annans
PKI
oatt sträva mot en autentiseringslösning, framför flera olika,
för att realisera stark autentisering i den egna organisationen och
i federation
oatt enbart acceptera SAMLv2, eller senare version, vid
identitetsfederering samt tydliggöra att det i förekommande fall är
det enda sättet att logga in och säkerställa det inte finns någon
bakväg in
oatt tillämpa ett gemensamt ramverk för att ingå i en
federation
oatt tillämpa en gemensam katalogpolicy, med utgångspunkt från
HSA policy, som ett minimikrav för egna kataloger
oatt stäva mot att all gränsöverskridande kommunikation skall
vara möjlig både över Sjunet och Internet. Det är den egna
organisationen som beslutar vilken tillgänglighet som är
tillräcklig för anslutningen
oatt sträva efter att möjliggöra kontroll av trafik till och
från den egna infrastrukturen i en eller få kontrollpunkter
oAtt utgå från att kommunikation över Internet och Sjunet har
ett likvärdigt skyddsbehov
Här beskrivs hur vi tillämpar dessa ståndpunkter i
lösningen.
Autentisering:
Det är endast för redaktörsgränssnittet som det är aktuellt med
autentisering. För närvarande (juni 2011) så stöds följande
autentiseringsmetoder: SITHS-kort.
HSA:
Från HSA hämtas behörighetsroller för de användare som loggar in
i redaktörsgränssnittet.
Nät:
Både invånargränssnittet och redaktörsgränssnittet är åtkomliga
via Internet. HSA-anrop sker via Sjunet, för detta ändamål så
används 1177 Vårdguidens infrastruktur som har separata nätsegment
för Internet och Sjunet, med brandvägg och trafikloggning mellan
nätsegmenten.
Användningsfall
Användningsfall – Översikt
Ref
Dokument id
Dokument
Af-1
Söka / visa information
AF-2
Inloggning i redaktörsgränssnittet
AF-3
Skriva / redigera artikalr
AF-4
Publicera artiklar
AF-5
Granska artiklar
AF-6
Exponera artikelinformation (syndikering)
Af-7
Inloggning i administrationsgränssnittet
Af-8
Systemadministration
Figur 8: Schematisk (förenklad) användningsfallsöversikt för
1177 Vårdguiden
Aktörsinformation
Artikellager
Både publicerade och opublicerade artiklar lagras i ett arkiv
varifrån de visas på webbplatsen och kan exponeras till
syndikeringskonsumenter
Granskare
Läser och kommenterar artiklar som är under granskning
HSA
HSA används som informationskälla för hämtning av
behörighetsroll vid inloggning.
Invånare
Invånare använder 1177 Vårdguidens publika webbplats för att
söka/visa information, samt för att annvända e-tjänster som
tillgängliggörs via 1177 Vårdguiden
Redaktör
Redaktörer skriver och publicerar artiklar. En förutsättning för
att få tillgång till redaktörsfunktionerna är en inloggning med
hjälp av SITHS_kort
SITHS
Inom ramen för inloggning till redaktörs- och admingränssnittet
ingår autentisering. Den baseras på så kallade SITHS-kort som
innehåller utfärdade SITHS-certifikat. Under autentiseringen så
kollas certifikatens giltighet mot revokeringslistor som utges av
SITHS.
Syndikeringskonsument
Syndikering av artiklar sker via tekniskt gränssnitt till
konsumenter (tekniska system) som avtalat med 1177 Vårdguiden om
att få tillgång till artiklar.
Systemadministratör
Systemadministratör sköter teknisk administration av systemet.
EPiServer har ett adminläge för sådana uppgifter. Adminläget blir
tillgängligt efter inloggning med SITHS-kort.
Logisk realisering användningsfall
Autentisering
Se även Arkitekturellt beslut AB-2.1 i bilaga B1 samt det
ickefunktionella kravet IFK-16.
Textuell beskrivning
Diagrammet visar ett scenario där autentiseringen lyckas.
Kort beskrivning:
· Klient: Net ID
· Klientcertifikat finns på SITHS-kortet
· Rotcertifikat finns på webbservern (Microsoft IIS). I
skrivande stund (augusti 2010) används SITHS_CA_v3.cer.
· Autentisering
· EPi-inloggning startar klientprogramvara, i detta fall Net
ID
· Net ID-klienten presenterar en lista med de certifikat som
finns på SITHS-kortet. Användaren väljer det certifikat som ska
användas vid autentiseringen
· PIN-koden anges i Net ID-klienten, som verifierar PIN-koden
mot valt certifikat
· Klientcertifikatets giltighet verifieras mot revokeringslistor
via anrop till tjänster vars adresser (http) är angivna på
SITHS-kortet. IIS slår mot revokeringslistor.
· Normalfallet är att certifikatet är giltigt, och därför inte
är med i revokeringslistan
· HSA-id hämtas från certifikatet på SITHS-kortet
· Krypterad kommunikation sker med hjälp av SSL mot
webbservern
Felhantering:
I de fall där certifikat är med i revokeringslistan och alltså
inte ska användas, så avbryts autentiseringsflödet och även hela
inloggningsprocessen. Detta sker efter att revokeringsstatus har
erhållits som svar på kontroll mot revokeringslistan.
Ingen åtkomst ges till systemet förrän hela inloggningsprocessen
har genomförts med godkänt resultat i alla steg, vilket i detta
fall innebär att ej godkänd revokeringsstatus avbryter
autentiseringsflödet med felstatus. Avbrutet inloggningsflöde
resulterar i att användaren inte får tillgång till önskad del av
systemet.
Realisering
Figur 12: Sekvensdiagram – Autentisering
Behörighetshämtning
Textuell beskrivning
· Hämtning av användar/behörighetsinformation för redaktionella
användare
· Hämta HSA-id från SITHS-kortets certifikat
· Anrop sker till Web Service (HSA Web Service 2) hos HSA
(metoden: IsAuthorizedToSystem). Nyckel är det HSA-id som hämtats
från SITHS-kortets certifikat
· Användarinformation inkl. användarens behörighetsprofil för
1177.se returneras från Web Servicen. Hämtar E-postadress,
system_role (”1177.se; xxx”)
· Regionstillhörighet hämtas från certifikatet (”o” i fältet
”subject”)
· Om regionstillhörigheten matchar en region vi har lagrad så
kommer användaren att tilldelas en .NET-roll ( i roleprovidern)
· Om HSA:s Web Service inte returnerar användarinformation
(informationen kan saknas i HSA eller HSA kanske inte får tag i
informationen på grund av teknisk otillgänglighet) så tillämpas
följande regelverk:
· Inloggning/behörighet godkänns om lokalt lagrad
behörighetsinformation uppdaterades inom definierad giltighetstid
(inledningsvis satt till 5 dagar). Då används senast hämtad
behörighetsinformation
· Behörighetsinformation finns i vår databas för de som loggat
in tidigare. Informationen finns även i minnescache (asp.net
minnescache, se även flödet nedan om behörighetstillämpning).
Minnesinformationen används vid sidrequests, men inte vid
inloggning
· Användarinformationen sparas lokalt (minnescache och/eller
databas). Uppdaterar sparad post (e-post och roller)
· Hämtad behörighetsprofil mappas mot EPi:s
behörighetsprofil
· Lösningen använder standardiserad virtuell roll (mapped role)
som kollar om användaren tillhör rollen regionalRedaktör och vilket
landsting användaren tillhör.
· Om användaren tillhör rollen regionalRedaktör så tilldelas
användaren en EPiServer-roll som motsvarar regionalRedaktör. Det är
den rollen som har rättigheter till EpiServers sidträd i
redigeraläget.
Realisering
Figur 13: Sekvensdiagram – Behörighetshämtning
Ytterligare användningsfall
Textuell beskrivning
Realisering
Icke-funktionella krav
Läsanvisningar för information
Ickefunktionella krav (bilaga Bx, se kapitel 1.3)
Icke-funktionella krav från verksamheten
Övergripande krav
Övergripande krav för projektet har varit att följa de
riktlinjer som ges ut av CeHis. Arbetet med detta har
konkretiserats genom att ett antal ickefunktionella krav har tagits
fram för projektet. Dessa krav har sedan bearbetats inom ramen för
utvecklingsarbetet och tillämpningen har granskats av projektets
Tekniskt ansvarige.
Företrädare för 1177 Vårdguiden och CeHis arkitekturgrupp har
granskat projektets arkitekturdokumentation, främst SAD,
Arkitekturella beslut och RIV-spec.
Specifika krav
· Särskilda yttre säkerhetskrav
· Sjunetkrav på driftmiljö (separat bilaga, referens i kapitel
1.3.1)
· HSA-krav på driftmiljö och driftleverantör (separat bilaga i
kapitel 1.3)
· HSA-krav på att integration sker mot HSA:s Web Service via en
krypterad SSL-förbindelse. Detta är implementerat som en del av den
lösning som tagits fram för att tillgodose Sjunets
säkerhetskrav
Svarstider
Beskrivning av svarstidskraven och deras påverkan på vald
lösning …
Tillgänglighet
Beskrivning av tillgänglighetskraven och deras påverkan på vald
lösning …
Icke-funktionella krav från Systemägaren/Förvaltaren
Beskrivning av kraven och deras påverkan på vald lösning …
Test (endast exempel)Funktionstester
Som en del av arbetet med att realisera User Stories så
utvecklas och körs automatiserade funktions/beteendetester i form
av enhetstester och automatiserade funktionstester som baseras på
testramverket Selenium. Enhetstesterna kontrollerar programkoden på
enhetsnivå och Seleniumtesterna testar lösningens beteende utifrån
ett användarperspektiv (webbläsartester). Som komplement till dessa
tester så används även testramverket Cucumber/Capybara till
automatiserade funktionstester, vilka även kan exekveras manuellt.
Cucumber/Capybara baseras på testspecar som är skrivna med ”vanligt
språk”, dessa testspecar används vid generering av körbara
automatiska tester.
Ytterligare beskrivning …
Prestandatester
Prestandatester har genomförts som separata aktiviteter under
hösten 2010. Underlag för prestandatesterna har varit de
ickefunktionella krav som ställts på systemet.
Genomförandet av prestandatester har skett i flera omgångar, där
den första omgången endast omfattade två testfall (navigering med
artikelvisning resp. kontkatkortsvisning). Den första testomgången
kördes i den s.k. demomiljön, som är en betydligt klenare miljö än
produktionsmiljön. Syftet med det första testet var att få en tidig
uppfattning om eventuella svagheter i applikationen.
Den stora prestandatestomgången kördes i produktionsmiljön.
Under den omgången kördes både stresstester och uthållighetstester,
omfattande testfall för artikelvisning, sökning i webbplatsen samt
vårdsökning. Test av kontaktkortsvisning, vilket innefattar anrop
till HSA, har skett separat under noggrann övervakning från
Cybercom.
Ytterligare beskrivning …
Konfigurationsstyrning
Beskrivning av kraven och deras påverkan på vald lösning …
SLA-övervakning
Beskrivning av kraven och deras påverkan på vald lösning …
Visning av driftsstatus
Beskrivning av kraven och deras påverkan på vald lösning …
Teknisk lösning
I detta kapitel visas grafiska skisser över systemets
ansvarsområden och deras viktigaste komponenter.
Beskrivning av arkitekturellt signifikanta delar av
lösningen
Komponentmodell (nivå 2)
Figur 16: Komponentmodell – nivå 2 (tjänstens ansvarsområden med
komponenter)
Designmönster
Sammanställning och beskrivning av de viktigaste designmönster
som används i lösningen
Model View Presenter (MVP)
Webbapplikationen använder Model View Presenter (förkortat MVP),
som är en tillämpning av designmönstret Separation of concerns
(separering av ansvar). MVP tillgodoser vissa behov från
presentationslogik-lösningar, såsom webblösningar. Genom
användandet av detta mönster skapas en god struktur i programkoden,
vilket gör koden enklare att förstå och underhålla.
Läs mer om designmönstret via länkarna L3, L21 (kapitel 1.3)
Circuit Breaker
Circuit Breaker är ett designmönster som man bl.a. kan läsa om i
boken Release IT av Michael T. Nygard. Syftet med användningen av
mönstret är att hålla reda på statusen för uppkopplingen mot HSA:s
webbtjänst och använda fallback-lösningen (databas) då många anrop
mot webbtjänsten fallerar. 1177.se:s implementation fungerar
tekniskt enligt följande:
Varje anrop till HSA får en ”poäng” beroende på om anropet
lyckades eller inte. Ett misslyckat anrop ger 1 poäng och ett
lyckat anrop ger -0,1 poäng. Systemet håller totalsumman för
anropen i minnet (en summa per region) och om den vid något
tillfälle kommer upp i 5 ”öppnas kretsen”, dvs fallbacklösning
appliceras.
Fallback används i 15 minuter innan ”kretsen sluts” igen och
anrop på nytt sker mot HSA. Poängen kan aldrig bli lägre än 0. När
kretsen sluts ligger poängen för regionen på 4, dvs det räcker med
ett fallerande anrop för att kretsen återigen ska öppnas om den
precis återgått från öppen till stängd 4 (detta kallas att kretsen
är halvt öppen). I verkligheten innebär implementationen att 5
fallerande anrop i rad alltid resulterar i en öppen krets eller att
om fler än 10% av anropen fallerar över tid så kommer kretsen att
öppnas.
I lösningen används en Circuit Breaker per landsting/region.
Varje Circuit Breaker öppnas och stängs oberoende av övriga Circuit
Breakers.
Mer om Circuit Breaker läsas via extern länk (ref. L5)
Autentisering och behörighet
Se även Arkitekturellt beslut AB-2.1 i bilaga Bx samt det
ickefunktionella kravet IFK-16.
HSA innehåller attributet hsaSystemRole (förutom motsvarande
Miu-attribut) av den anledningen att hsaSystemRole ska användas av
system som inte naturligt passar in i Säkerhetstjänsters
uppdragsstruktur. Det finns ett antal sådana system, varav 1177.se
är ett.
Läsanvisning för mer informationSe länkreferenserna L7, L8 och
L9 (se kapitel 1.3)
Teknisk lösning i stora dragAutentiseringens realisering
innehåller certifikat på SITHS-kort, certifikat autentiseras med
hjälp av NetID-klient, Membership Provider (ASP .NET 2.0-funktion
som används av EPiServer). Användarbehörighet hämtas från HSA via
Web Servicemetoden IsAuthorizedToSystem (ingår i HSA Web Service
2). Som minnescache i lösningen används en instans av EPiServers
CacheManagerklass inkapslad i applikationskod.
Autentisering
Under en övergångsperiod innan webbplatsen tillgängliggörs för
invånarna så kommer både certifikatbaserad och formsbaserad
inloggning att stödjas i den så kallade stagingmiljön. Den
certifikathanterade inloggningen beskrivs nedan i avsnittet om
SITHS-autentisering. Den så kallade formsbaserade inloggningen
baseras på användar-id och lösenord.
Lite stolpar kring autentiseringslösningen:
· Krypterad kommunikation sker med hjälp av SSL mot
webbservern
· Klient: Net ID
· Klientcertifikat finns på SITHS-kortet
· Rotcertifikat finns på webbservern (Microsoft IIS). I
skrivande stund (augusti 2010) används SITHS_CA_v3.cer.
· Autentisering
· EPi-inloggning startar klientprogramvara, i vårt fall Net
ID
· En lista med SITHS-kortets certifikat visas, användaren väljer
det certifikat som ska användas vid autentiseringen
· PIN-kod anges i Net ID-klient, och verifieras mot valt
SITHS-certifikat
· Klientcertifikatets giltighet verifieras mot revokeringslistor
via anrop till tjänster vars adresser (http) är angivna på
SITHS-kortet. Autentiserings-processen avbryts om
revokeringskontrollen för valt certifikat anger att certifikatet
inte är giltigt.
· HSA-id hämtas från certifikatet på SITHS-kortet
· Hämtning av användar/behörighetsinformation
· Anrop sker till Web Service hos HSA (Metoden:
IsAuthorizedToSystem). Nyckel är det HSA-id som hämtats från
SITHS-kortets certifikat
Se även flödesbeskrivning av autentiseringsflödet i tidigare
kapitel
Behörighet
Inloggning i EPiServers redaktörsgränssnitt sker med hjälp av
SITHS-kort. Information från (certifikatet på) kortet kombineras
med information i HSA för att ge användaren rätt roll i EPiServer.
Det finns två roller för 1177.se som kan sättas i HSA;
nationellRedaktör och regionalRedaktör. När användaren autentiserar
sig så görs ett uppslag mot HSA:s webbtjänst med användarens HSA-id
(som hämtats från certifikatet) och systemnamnet (1177.se) vilket
innebär att användarens roller hämtas.
För regionala redaktörer hämtas användarens region från
certifikatet och användaren tilldelas även en s.k. virtuell roll
som består av rollnamn+landstingsnamn, där även tjänstens
förvaltning betraktas som landsting. Exempel på dessa är
”regionalRedaktör Landstinget Sörmland”, ”regionalRedaktör
Västerbottens läns landsting” o.s.v., eller ”regionalRedaktör
Inera”). Den virtuella rollen är den som sätts automatiskt på sidor
som en regional redaktör skapar och som möjliggör att alla
redaktörer i samma region får rätt att redigera de regionala
sidorna samtidigt som de inte kan redigera sidor i andra regioner.
Precis samma sak gäller för nationella artiklar, dvs. de kan endast
redigeras av de nationella redaktörerna.
Ytterligare beskrivning …
Hur roller och behörigheter används i lösningen
Beskrivning …
Siteramverk
Det som är gemensamt för varje sida på siten är sidhuvud, sidfot
och information som inte är direkt synlig för användare (t.ex.
metadata). För att samla logiken som hanterar denna gemensamma
funktionalitet används en kombination av ASP.NET MasterPages och
UserControls.
Alla sidor har en standarduppsättning metadata som kan upphävas
av en specifik sidtyps kontroller (eng. controls). Det innebär att
de flesta sidor, t.ex. startsidan, använder standarduppsättningen
som har lämpliga värden för t.ex. externa sökmotorer. Vissa
sidtyper, t.ex. artiklar, kan innehålla mer specifik metadata
(t.ex. SweMeSH-nyckelord som kan sättas av redaktören). Dessa
sidtyper innehåller logik som publicerar metadata på sidorna. På så
vis får alla sidor en rimlig standarduppsättning metadata som kan
skrivas över på specifika sidor.
Det finns även en uppsättning CSS- och Javascriptfiler som finns
på alla sidor på siten tack vare användandet av MasterPages.
Ytterligare beskrivning …
Integration med HSA
Beskrivning …
Ytterligare signifikant del av lösningen
Beskrivning …
Tjänstens hantering och användning av informationsmängder
Beskrivning …
Felhantering
Felhantering i webbgränssnittet
Beskrivning …
Felhantering i tekniska gränssnitt
Beskrivning …
Tekniska ramverk
Ramverk / verktyg
Användningsområde i lösningen
Cucumber/Capybara
Testramverk för automatiserade beteendedrivna tester, utgår från
testspecar som är skrivna i ”vanligt språk”
EPiServer
Verktyg som innehåller redaktionella funktioner samt sidvisning
för webbplatsen
Ytterligare ramverk
Säkerhet
Övergripande
Den tekniska lösningen har utformats så att den ska tillgodose
de informationssäkerhetskrav som ställts på lösningen. Se mer i de
olika avsnitten nedan i detta kapitel.
Säkerhetsklassificering av information
Den information som tillgängliggörs via webbplatsen är
publik.
Information som inte är publik och har en högre
säkerhetsklassificering är användarinformation och
behörighetsinformation för de användare som loggar in i EPiServers
redaktörs- eller administrationsgränssnitt. Sådan information är
inte åtkomlig via webbplatsen.
Rekommendation
Beskrivning …
Riskanalys
Sommaren 2009 utfördes en riskanalys av projektet ”Vården på
Webben”. Riskanalysen utfördes av Veriscan, på uppdrag av Inera.
Riskanalysen bifogas som bilaga B7 (kapitel 1.3).
Nedan visas ett utdrag ur den genomförda riskanalysen, utdraget
avser redaktionella tjänster
Nr
Risk
Konsekvens
Sannolikhet
Riskvärde
R1
Risk
3
1
2
R2
Risk
2
1
1,5
R3
Risk
3
1
2
Riskanalysens (bilaga B7) åtgärdsförslag samt referens till hur
de tillämpas:
· R1: Säkerställ att det finns tydliga rutiner för inmatning av
information. Tillämpas delvis genom IFK-12 (Kapacitetskrav för
webbplatsen)
· R2: Se över driftkraven på plattformen. Se till att det skapas
redundans. Då ej tillgänglighet fungerar till informationen, skapa
relevanta felmeddelanden så att medborgare vet vad de kan förvänta
sig.Tillämpas genom IFK-kraven rörande teknisk tillgänglighet och
prestanda
· R3: Säkerställ riktlinjer och efterlevnad av dessa t.ex. genom
att systematisk genomläsning och kontroll utförs eller genom
riktlinjer om second opinion som gör att enskilda kan anmäla
artiklar till kontroll av en från artikeln fristående redaktör. En
fastlagd ärendegång med signering är också en rekommenderad
åtgärd.Tillämpas genom att …
Riskminimering i den tekniska lösningen
Den tekniska lösningen innehåller ett grundläggande skydd mot
vissa säkerhetsrisker, se riskanalysen och de ickefunktionella krav
som rör säkerhetsområdet.
För att minimera säkerhetsrisker har två huvudsakliga
aktiviteter utförts; dels har säkerhetskrav från Sjunet
tillgodosetts (se ovan) och dels har principer för utveckling av
säker programkod tillämpats (se nedan). Förutom dessa aktiviteter
har realisering av vissa ickefunktionella krav (IFK-15, 16, 17, 19)
inneburit att säkerhetsgranskning och intrångstest genomförts med
resultatet att inga stora brister funnits. Dock ska tilläggas att
granskningen resulterade i en lista med aktiviteter som bör
åtgärdas.
Principer för utveckling av säker programkod
Följande principer har följts för att åstadkomma så säker
programkod som möjligt:
· All kod granskas av annan utvecklare, antingen genom
parprogrammering eller genom kodgranskning innan koden betraktas
som klar
· Separering av ansvar. Detta tillämpas genom realisering av
komponentmodellen.
· Abstraktion mot SQL-anrop. Detta tillämpas i lösningen genom
användande av komponenterna DataAccess och LinqToSQL (se
komponentmodellen)
· Kontroll av datakvalitet. Tillämpas dels genom att detta sker
innan lagring i databasen (se den import av NPE:s XML-fil som görs
inom ramen för Hitta och jämför vård), och dels genom
datakvalitetsgranskning i källorna för sådant indata som konsumeras
utan att lagras i 1177.se (exempelvis arbete med HSA:s
innehåll).
· SITHS-baserad autentisering. Används i lösningen för samtliga
användare som loggar in för att få behörighet till vissa
funktioner, detta gäller redaktionella användare och
administratörer. Invånargränssnittet erbjuder ingen inloggning och
använder därför inte någon autentisering
· Genomtänkt felhantering. Tillämpas i lösningen, och leder i
många fall till loggning och i vissa fall dessutom till notifiering
om att fel har inträffat
· Loggning/notifiering. Detta sker i vissa fall till loggfil och
vissa fall till både loggfil och till e-postnotifiering.
· Skydd mot SQL Injection. Detta är implementerat i lösningen
genom användning av LinQToSQL-komponenten (se avsnittet nedan)
· Skydd mot Cross-Site Scripting. Detta är implementerat i
lösningen (se avsnittet nedan)
Principer för säker programkod
Läs om principer via länk på: referens. L10 (kapitel 1.3)
De principer som OWASP rekommenderar är:
Minimize attack surface areatillämpas genom skydd mot SQL
Injection & XSS
Establish secure defaultsURL-parametrar är HTML-encodade (se
XSS)
Principle of Least privilegetillämpas på invånardelen av
tjänsten
Principle of Defense in depthbl.a. infrastruktursäkerhet + att
HSA-id ej visas
Fail securelytillämpas i viktiga delar av lösningen, ex.
behörighet
Don't trust servicestillämpas, externt data kollas innan
import
Separation of dutiestillämpas genom komponentmodellen
Avoid security by obscuritytillämpas genom att följa dessa
principer
Keep security simpletillämpas genom komponentmodellen
Fix security issues correctlytillämpas genom att säkerhetstester
körs
Ett önskemål från utvecklingsprojektet är att gemensamma
principer för säker programkod borde tas fram tillsammans med
rutiner och verktyg för säkerhetsverifiering, som en hjälp för
utvecklingsprojekt att leva upp till krav på detta område.
Utvecklingsprojektet för 1177.se har gjort vissa ansträngningar för
att åstadkomma säker programkod, baserat på OWASP:s principer som
nämns ovan samt på erfarenheter från andra projekt.
Skydd mot SQL Injection
Beskrivning …
Skydd mot Cross-Site Scripting (XSS)
Beskrivning …
Infrastruktursäkerhet
Läsanvisningar för information
Sjunetbilaga om informationssäkerhet (bilaga S4, se kapitel
1.3)
Arkitekturella beslut (bilaga B1 och B2, se kapitel 1.3)
HBB - HSA BrukarBeskrivning (bilaga B5, se kapitel 1.3)
Drifthandboken (Bilaga B6, se kapitel 1.3)
Se även beskrivning i kapitlet om lösningsöversikt (kapitel
11.1)
1177 Vårdguidens förvaltning har beskrivningar av det
intrångskydd som tillämpas på infrastrukturen
Säkerhetskrav från HSA:s HPTB
I HSA:s policytillämpning (HPTB) ställs en del krav på den
driftsleverantör som ansvarar för drift av den IT-lösning som ska
kommunicera med HSA. Detaljerad information om detta kan läsas i
HPTB-bilagan.
Ytterligare beskrivning …
Intrångsskydd
Tillämpning av ickefunktionella krav på intrångsskydd
IFK-15 (Intrångsskydd) tillämpas på följande sätt:
· Passiva skydd (såsom brandväggar)
· Aktiva skydd (intrångsdetektering, övervakning, larm)
· Loggning av incidenter
· Genomförd och godkänd säkerhetsgranskning
· Genomfört och godkänt intrångstest
· BITS tillämpas av driftsleverantören
· Dokumentation från genomförd säkerhetsgranskning och genomfört
intrångsförsök beskriver säkerhetsrisker i lösningen.
Insynsskydd (kryptering)
Beskrivning …
Transportoförvanskning.
Transportskydd tillämpas i lösningen i form av SSL-förbindelser.
Genom att trafiken är krypterad åstadkoms ett för lösningen
tillräckligt bra skydd mot både insyn och förvanskning.
SSL-förbindelser används vid kommunikation mot HSA via Sjunet
samt vid användning av redaktörsstödet.
Presentationskorrekt
Genom att tillämpa principer för utveckling av säker programkod
så åstadkoms en presentationskorrekthet som bedömts som tillräcklig
för lösningen.
Dataintegritet (Oförvanskat över tid), riktighet
Beskrivning …
Autentisering (”stark” vid behov enligt infoklassning)
Läs om flöden för autentisering och behörighet i följande
kapitel:
· 3.4 Flöde: inloggning
· 3.5 Flöde: autentisering
· 3.6 Flöde: behörighetshämtning
· 3.7 Flöde: behörighetstillämpning vid
inloggning/sidvisning
Läs om tillämpningen finns i kapitlet ”Autentisering och
behörighet” (kapitel 4.4.1)
Ytterligare beskrivning …
Implementerad Signering
I denna version av 1177 Vårdguiden finns inget behov som kräver
signering, så ingen signeringsfunktionalitet är implementerad.
SITHS-certifikaten som används vid autentisering i samband med
inloggning i redaktörs- och admingränssnittet kan om så önskas
användas även till signering.
Lagkrav ex. spärrhantering
Spärrhantering är ej tillämpbart för denna tjänst
Samtycke är ej tillämpbart för denna tjänst
Vårdrelation är ej tillämpbart för denna tjänst
Spårbarhet (loggning)
Tillämpning av ickefunktionella krav på spårbarhet
(loggning)
IFK-8 (Systemfel) tillämpas på följande sätt:
· EPiServers loggningsstöd används
· Loggformatet beskrivs med exempel på loggutdrag så att det
framgår hur pass begriplig informationen är (se nedan)
· Beskrivning av vad som loggas och på vilket sätt loggning
sker
· Se bilaga B8 (se kapitel 1.3.1)
· Applikationsloggning (se nedan)
· Systemloggning (se EPi-logg nedan)
· Driftleverantören har aktiverat stöd för övervakning av loggar
och notifiering vid vissa felnivåer. Mer information om detta kan
fås av 1177 Vårdguidens förvaltning.
· En flexibel och konfigurerbar loggningskomponent används (se
nedan)
· Läs mer om val av loggformat i arkitekturellt beslut AB-2.12 i
bilaga B1 (se kapitel 1.3.1)
Applikationsloggning:
Beskrivning …
Exempel på innehåll i loggfiler (utdrag från testmiljö)
Exempel …
IFK-15 (Intrångsskydd) tillämpas på följande sätt för
loggning:
· Loggning av incidenter
· Tillämpat intrångsskydd. Detta tillgodoses genom
driftleverantörens tillämpning av BITS-kraven
· Driftleverantören tillämpar intrångsskydd. Kontakta 1177
Vårdguidens förvaltning för att få mer information om detta
skydd
IFK-17 (Spårbarhet användning) tillämpas på följande sätt:
· Loggning av förändringar på webbplatsen. Inga begränsningar i
antal loggfiler eller maxstorlek på loggfiler; se även IFK-8
(Systemfel).
· Säkerhetskopia på loggfiler sparas 365 dagar, först sparas de
på disk och sedan migreras de till band
· Tillämpat skydd mot obehörig åtkomst till eller förvanskning
av loggar. Detta tillgodoses genom driftleverantörens tillämpning
av BITS-kraven. Detta innebär att det endast är driftleverantörens
administratörer som har åtkomst till loggarna.
· Krypterad kommunikation används av redaktörer och
administratörer
· Tillämpat skydd mot förvanskning av informationsinnehållet.
Detta tillgodoses genom driftleverantörens tillämpning av
BITS-kraven.
· Genomförd och godkänd säkerhetsgranskning
· Genomförd och godkänd acceptanstest
Nyttjade integrationstjänster
Ref
Nyttjad tjänst
Beskrivning eller dokument
HSA
HSA Web Service 2 (se bilaga T1)
Integration sker mot HSA via dess webbtjänst ”HSA Web Service
2”.
Nyttjade plattformsfunktioner
Ref
Nyttjad funktion
Beskrivning eller dokument
HSA
HSA används via des webbtjänst ”HSA Web Service 2”
SITHS
SITHS-kort används vid autentisering av användare som loggar in
i redaktörsgränssnittet. SITHS-certifikat utan kort används mellan
TMG-server och HSA:s webbtjänst
Informationshantering
Domäninformationsmodell
Informationsmodellen för 1177 Vårdguiden består för närvarande
av nedanstående huvudobjekt. Närmare beskrivning av
informationsmodellen finns i den RIV-specifikation som tagits fram
av projektet (se referens B4 i kapitel 1.3)
Figur 32: Övergripande domäninformationsmodell
Bilden ovan visar de viktigaste objekten i varje av 1177
Vårdguidens delområden. Det mest omfattande av dessa tre områden är
Webbplats med innehåll, som täcker både webbplats med navigering
och innehållet (främst i form av artiklar).
För dokumentation om domäninformationsmodellen, se referens R1
(kapitel 1.3.2)
Informationsflöde
Beskrivning …
Informationens ursprung
Information som ägs av detta system
1177 Vårdguiden äger den information som utgör webbplatsens
innehåll och struktur, vilket innefattar artiklar med tillhörande
informationsobjekt (såsom sidtyper, kapitel, mm).
Ägarskapet till den information som hanteras av de e-tjänster
som visas på webbplatsen kan variera från e-tjänst till e-tjänst.
Detta bör beskrivas i separat dokumentation för e-tjänsterna.
Information som exponeras från 1177 Vårdguiden
Många av webbplatsens artiklar exponerar sitt innehåll till
andra webbplatser via en så kallad syndikeringslösning, som innebär
att webbplatser efter överenskommelse med 1177 Vårdguiden kan hämta
artiklar med innehåll (dock ej media objekt såsom bilder och
filmer) vilka kan visas på syndikeringskonsumenternas
webbplats.
Information som konsumeras
Beskrivning …
Information som skapas
Beskrivning …
Driftaspekter
Läsanvisningar för information
Se drifthandboken (bilaga B6, se kapitel 1.3)
Lösningsöversikt
Filreplikering används i samband med uppgradering av
applikationen. Tillvägagångssättet är att uppdatera en nod och
sedan replikera över filerna till den andra noden.
Filreplikeringen är en del av realiseringen för att tillgodose
följande ickefunktionella krav:
IFK-2: Teknisk tillgänglighet för webbplatsen
IFK-3: Teknisk tillgänglighet för producerande
integrationstjänster
IFK-4: Teknisk tillgänglighet för redaktörsfunktioner
IFK-5: Teknisk tillgänglighet för vårdsöks- och
jämförelsetjänst
Beskrivning …
Fysisk miljö
Figur 10: Översikt över tjänstens driftsmiljöer
Driftsmiljön innehåller lastbalanserare, lastbalanserade
webbservrar, klustrade databaser och ett SAN för datalagring.
Förutom dessa finns separata nätsegment för Internet och Sjunet,
brandväggar där så är lämpligt samt IDS som bevakar
intrångsförsök.
Ytterligare beskrivning …
Programvaror
Klustrade databasservrar har MS Windows Server 2008 R2 ENT x64
SP2
Lastbalanserade webbservrar har MS Windows Server 2008 STD x64
R2 SP2
EPiServer CMS 6 R2 (uppgradering till R2 gjordes i maj 2011)
SQL Server 2008
I nätsegmentet för Internet finns klustrade webbservrar och
klustrade databaser. Webbservrarna är implementerade i form av
EPiServerinstanser. Databaserna är SQL Serverinstanser.
Detaljerad information
Detaljerad information om driftsmiljön kan läsas i den
driftshandbok som förvaltas av 1177 Vårdguidens förvaltningsgrupp.
I denna beskrivs sådana saker som skalskydd, mm. Övrig detaljerad
information finns i detta kapitel.
Tillämpning av ickefunktionella krav på teknisk
tillgänglighet
IFK-1 (Backup och restore) tillämpas på följande sätt:
· Infrastrukturen är konfigurerad så att den innehåller
redundans på vitala servrar så att det ska vara möjligt att ta
backup eller göra restore på en serverinstans samtidigt som övriga
instanser är opåverkade
· Driftsleverantören genomför schemalagda backuper
· Den applikatoriska lösningen är utformad så att den inte
innehåller någon funktionalitet som påverkar prestanda eller
teknisk tillgänglighet märkbart under pågående backup.
· Ytterligare beskrivning …
IFK-2 (Teknisk tillgänglighet för webbplatsen) tillämpas på
följande sätt:
· Infrastrukturens utformning har gjorts med tanke på att kunna
åstadkomma en mycket hög teknisk tillgänglighet, det innebär att
det infrastrukturen bl.a. innehåller klustrade servrar och
lastbalansering
· Övervakning av driftmiljön och avtalat SLA
· Webbservrarna, Internet Information Server (IIS), har en aktiv
felhantering som gör att de övervakar sitt tillstånd och
automatiskt utför Âåterställningsåtgärder om övervakningen
upptäcker att IIS stannat av
· Applikationen (1177 Vårdguiden) laddas om en gång per natt i
syfte att rensa eventuella minnesläckor som kan göra att svarstider
och teknisk tillgänglighet försämras över tiden
· Sidor som hämtas inför visning på webbplatsen cachas i minnet.
Detta ger två effekter; dels åstadkoms snabba svarstider och dels
minskas belastningen på databasen, vilket ökar sannolikheten att
den inte ska bli överbelastad och skapa otillgänglighet på
webbplatsen
· Stegvis uppgradering av klustrade noder, vilket innebär att
applikationsuppgradering sker på en nod i taget. Detta ska borga
för att applikationen har en mycket hög teknisk tillgänglighet
Tillämpning av ickefunktionella krav på prestanda
Beskrivning …
Produktionssättning och överlämning till förvaltning
Produktionssättning
Detaljerad information om driftsmiljön och rutiner för
installation i produktionsmiljön finns i den driftshandbok som
förvaltas av 1177 Vårdguidens förvaltningsgrupp. Förutom denna har
1177 Vårdguidens förvaltning ytterligare information om förfarandet
vid installation.
Överlämning till förvaltning
Detaljerad information om driftsmiljön och rutiner för
installation i produktionsmiljön finns i den driftshandbok som
förvaltas av 1177 Vårdguidens förvaltningsgrupp. Förutom denna har
1177 Vårdguidens förvaltning ytterligare information om förfarandet
vid överlämning.
Överlämning av 1177 Vårdguiden till förvaltning har skett i
flera steg, där överlämningsdokumentation tagits fram enligt en
checklista från 1177 Vårdguidens förvaltning och där
förvaltningsobjekt inklusive dokumentation har gåtts igenom på de
överlämningsmöten som hållits i samband med överlämningen.
Center för eHälsa i samverkan koordinerar landstingens och
regionernas samarbete för att förverkliga strategin för Nationell
eHälsa – tillgänglig och säker information inom vård och omsorg.
Centret ska skapa den långsiktighet som krävs för att utveckla och
införa gemensamma eHälsostöd, infrastruktur och standarder som
förbättrar informationstillgänglighet, kvalitet och
patientsäkerhet. Center för eHälsa i samverkan styrs av
representanter från landsting och regioner, Sveriges Kommuner och
Landsting (SKL), kommunerna och de privata vårdgivarna.
