(-- JanRiis - 20-01-2006)

Helt overordnet er designet i SOSI inspireret af de ID-kort, man får udleveret, når man besøger virksomheder, der har sådanne ordninger. Når en person bærer et ID-kort (synligt) er det muligt for andre personer at se, hvem personen er, hvornår ID-kortet er udstedt og hvornår det udløber, hvem der har udstedt ID-kortet, hvilken arbejdsfunktion personen har og evt. hvor personen har tilladelse til at opholde sig (med forskellige farvekoder eller lignende).

I SOSI designet opereres der med virtuelle ID-kort, som kan udstedes til en bruger (personligt ID-kort) efter succesfuld autentifikation og til systemer (system ID-kort), så også disse kan genkendes. Alle parter der "bærer" et SOSI ID-kort er i samme "føderation" og kan nu identificeres. Endvidere er det målet at påtrykke tilstrækkeligt med informationer (attributter) på de personlige ID-kort til, at serviceudbydere kan foreteage en passende autorisation af brugerne og dermed give adgang til et passende sæt services. Eksempler på attributter kunne være den afdeling brugeren er "logget ind på" og arbejdsfunktion på afdelingen f.eks. "tilsynsførende læge".

Inspireret af SAML standarden består løsningen af:

1. En Identity Provider (IdP)
2. En eller flere Service Providers (SP)
3. Service klienter (f.eks. medicinmoduler) (Klient)

Et grundlæggende krav til designet er, at klienter skal kunne kommunikere med serviceudbyder uden al for megen involvering af IdP'en og uden at serviceudbyderen skal bruge tid på at verificere brugeren igen og igen. Ideen er derfor at IdP'en er en slags portvagt, som sikrer at kun autentificerede brugere/systemer får lov til at komme ind i føderationens tillidsområde og benytte services hos serviceudbydere. Omvendt kan serviceaftagere, efter at være blevet autentificeret, frit kommunikere med serviceudbydere uden videre involvering af IdP'en eller andre parter.

Hvis en serviceudbyder vil have endnu mere "bevis" for, at det er den rigtige bruger, der sidder bag tastaturet, eller ønsker at opbevare data, der kan bevise at en given bruger foretog en given forespørgsel eller indberetning på et bestemt tidspunkt, kan serviceudbyderen kræve at få en uafviselighedsforsikring med i forespørgslen i form af en digital signatur. Kræver servicen omvendt slet ikke anvendelse af digitale certifikater, er det muligt at anvende autenticitetsikring på niveau 1 eller 2. Designet har dermed en fleksibelitet, der gør det muligt at kræve den fornødne viden, sikkerhed og beviselighed i nogle situationer, men undlade det i andre situationer, hvor det ikke er påkrævet, og dermed optimere performance og minimere mængden af arbejde, der skal til som serviceaftager.

En anden performanceegenskab er, at ID-kortets ægthed kan verificeres af de enkelte serviceudbydere helt uden indblanding af andre instanser. Den udstedende myndighed (en såkaldt Identity Provider) sætter sin digitale signatur på alle udstedte ID-kort, som enhver part i føderationen kan verificere ved hjælp af den udstedende myndigheds offentlige nøgle. I praksis er det derfor umuligt at udstede falske ID-kort. Ægthed er et aspekt, mens troværdigheden er et andet. Hvis ID-kortet udstedes på baggrund af digitale certifikater, kan enhver serviceudbyder i føderationen føle sig ret sikker på, at brugeren er den, som vedkommende udgiver sig for at være. Hvis ID-kortet er udstedt på baggrund af et brugernavn og password (niveau 2) er troværdigheden baseret på tilliden mellem den udstende myndighed og den part, der verificerede password'et (typisk afsendersystemet).

Når en klient ønsker adgang til en serviceudbyder, skal klienten altså først igennem en autentifikationsprocess hos IdP'en. Som grundlag for autentifikationen skal IdP'en bruge nogle informationer om brugeren i form af nogle akkreditiver ("credentials"), der kan godtgøre at brugeren netop er den vedkommende udgiver sig for at være. Nedenstående skema opridser, hvilke akkreditiver, der kræves på de forskellige autenticitetsniveauer i SOSI:

SOSI Autenticitetssikring
Autenticitetsniveau	Krævede akkreditiver
4	OCES medarbejdercertifikat
3	OCES virksomhedscertifikat
2	Brugernavn+Password
1	evt. brugernavn

Hvorfor gå igennem al dette bøvl med ID-kort på niveau 3 og 4? Hvorfor ikke bare benytte certifikatet i alle forespørgsler til serviceudbydere? Det alt overvejende argument er kompleksitet. Det er komplekst og tidskrævende at foretage verifikation af et certifikat. Derfor er det performancemæssigt fordelagtigt at foretage denne verifikation én gang og lade IdP'en stå inde for denne verifikation for en periode. Helt konkret opnås denne "trust propagation" ved at lade IdP'en underskrive ID kortet med en digital signatur, der senere enkelt og effektivt kan verificeres med IdP'ens offentlige nøgle - problemet er altså reduceret til, at alle serviceudbydere skal kende og have tillid til dette ene certifikat (IdP'ens).

På niveau 1 og 2 har IdP'en typisk ikke informationer til at kunne autenticere en bruger, og må da uddelegere dette ansvar. I SOSI fremsender man dog altid (uanset autenticitetsniveau) en digital signatur i forbindelse med udstedelse af ID-kort - enten brugerens signatur eller systemets signatur. På niveau 1 og 2 sikrer IdP'en således med sin underskrift af ID-kortet, at brugeren kommer fra det påståede system, at systemet er kendt, og at autenticeringen var succesfuld hos den autenticitetsservice, der forestod autenticeringen.

IdP'en består af en SSO service (den service, som kaldes for at udstede ID-kort) og en "trust authority", der tager sig af verificering af en brugers eller et systems identitet og udsteder ID-kortet. Selve autenticitetskontrollen uddelegerer IdP'en enten til en lokal "authentication authority" (f.eks. ved verificering af certifikater og signaturer på niveau 3 og 4) eller til en ekstern autoritet.

Uddelegering til en ekstern autoritet benyttes f.eks. i situationer, hvor serviceudbyderen også ønsker at autenticere brugeren (enten på baggrund af et lokalt brugernavn/password, eller ved systemlogin/password). Det smarte er nu, at efter at brugeren er autenticeret hos en ekstern autenticitetsautoritet, udstedes et ID-kort hvor IdP'en står inde for at brugeren er blevet autenticeret. ID-kortet kan derefter anvendes hos andre serviceudbydere, der kræver autenticitetsniveau mindre end eller lig det der står på ID-kortet.

En lidt speciel form for "uddelegering" er når IdP'en slet ikke autenticerer brugeren, dvs. blot stoler på, at brugeren er korrekt autenticeret fra serviceaftagersystemet. Dette er muligt på niveau 2, hvor vi benytter "sender-vouches" mekanismen i SAML. Som tidligere nævnt sendes der dog altid i disse tilfælde en digital signatur med fra afsendersystemet, så ikke alle og enhver kan kontakte IdP'en og påstå at brugeren er autenticeret af afsendersystemet.

2.1 Et eksempel

Her følger et konkret eksempel, hvor en bruger skal indberette meget personfølsomme eller patientsikkerhedsfølsomme data til en central instans (f.eks. en kvalitetsdatabase). Indberetningen antages at kræve niveau 3 autenticering og serviceudbyder ønsker digital signatur (uafviselighedsforsikring). Kvalitetsdatabasen er Service Provider (SP) (erviceudbyder) og EPJ systemet er klient (serviceaftager). Serviceaftager er todelt, idet EPJ systemer typisk er delt op i en EPJ klient, og en EPJ server. Det er oplagt at lade Sundhed.dk være Identity Provider (IdP), idet Sundhed.dk i forvejen har ansvar for validering af OCES certifikater mv.

Det antages, at der i tråd med pilotafprøvningen vedr. udbredelsen af digitale signaturer i Ribe Amt findes en central signaturserver, som opbevarer lokale brugeres certifikater og private nøgler. Serveren er i stand til at danne en digital signatur på vegne af en bruger, såfremt brugeren afgiver sit certifikatpassword.

2.1.1 Udstedelse af "personligt ID kort"

For en klient, der ikke har et gyldigt ID kort, er den første arbejdsgang altid at rekvirere et sådant:

1. Først genererer klienten en "udsted venligst nyt ID-kort" besked.
2. EPJ serveren danner en kuvert, hvorpå der er påtrykt modtager, afsender og andre nyttige data, og putter en "Udsted venligst ID-kort" forespørgsel ned i kuverten. Før denne kuvert kan sendes til IdP'en skal både indholdet og de kuvertdata underskrives digitalt ved at benytte brugerens private nøgle (det er en implementationsdetalje, hvor vidt det i praksis gøres fra klientmaskinen eller med EPJ serveren som proxy).
3. Nu sendes kuvert og indhold til IdP'en.
4. IdP'en kontrollerer først at det er tilladt for det kaldende system at komme ind i føderationen. Dernæst henter IdP'en brugerens offentlige certifikat fra TDC på baggrund af et certifikat ID i beskeden (CVR+RID). Certifikatet verificeres for ægthed og gyldighed, hvorefter brugerens offentlige nøgle anvendes til at kontrollere den digitale signatur af beskeden. Ved succes kan IdP'en nu være sikker på, at afsenderen er i besiddelse af den private nøgle, og dermed er den som brugeren udgiver sig for at være.
5. IdP'en påbegynder nu ID-kort udstedelsesprocessen, hvor IdP'en påtrykker en blanding af data fra forespørgslen (data fra EPJ systemet) og data fra diverse centrale registre på ID-kortet. ID-kortet får også en begrænset gyldighedsperiode.
6. For at en aktør senere på en nem måde kan afgøre om ID-kortet er ægte og i øvrigt kan stole på ID-kortets indhold, påfører IdP'en sin digitale signatur på ID-kortet ved hjælp af IdP'ens private nøgle.
7. Nu er ID-kort udstedelsen tilendebragt, og kortet sendes tilbage til EPJ serveren, der opbevarer ID-kortet forsvarligt, til senere anvendelse.

2.1.2 Servicekald

Ved efterfølgende servicekald er arbejdsgangen flg.:

1. Nu fremsender klienten en "Indberet XYZ data" meddelelse til EPJ serveren
2. EPJ serveren danner igen en XML meddelelse og kuvert, som signeres digitalt ved hjælp af brugerens private nøgle.
3. Den underskrevne forespørgsel fremsendes til serviceudbyderen sammen med ID-kortet
4. Serviceudbyderen kontrollerer nu:
   1. At brugeren har rettighed til at kalde service XYZ ved at bruge oplysninger fra ID kortet
   2. At ID kortet er ægte ved at kontrollere kortets digitale signatur (dvs. IdP'ens signatur) ved hjælp af IdP'ens offentlige certifikat, som er det eneste certifikat, der forventes at være kendt af alle serviceudbydere i føderationen.
   3. At brugerens signatur er korrekt vha. brugerens offentlige nøgle, der kan aflæses på ID kortet.
5. Hvis alt er OK, så gennemføres transaktionen, den digitale signatur gemmes sammen med en reference til ID-kortet og der returneres.

Ovenstående eksempler i to af de tekniske usecases, der understøttes af designet. Nedenfor gennemgås alle tekniske Use Cases i større detalje. Endvidere gennemgås senere nogle situationer, hvor man kan fravige kravet om signering af meddelelser og svar.