Digital Sundhed Brugerstyringsattributter - Introduktion - Specificering af nye og ændrede attributter i id-kortet Indhold 1. Introduktion... 2 2. Læsevejledning... 2 3. Aktører... 2 4. Autentifikation... 3 5. Veksling af identitytoken... 4 6. Autorisation... 4 7. Politikker... 5 8. Attributter... 5 9. Attribut Metadata... 5 10. Referencer... 6 Version Dato Ansvarlig 0.1 12.05.2010 KKJ 0.2 14.05.2010 JSK 0.3 21.06.2010 JSK Kommentarer Ny skabelon Formuleringer tilrettet efter kommentering fra KKJ Side 1 af 6
1. Introduktion Sundhedssektorens har etableret en identitetsbaseret web service infrastruktur, der involverer flere parter. Modellen baserer sig i stor stil på tillid til påstande om en given brugers identitet og det er derfor vigtigt for de forskellige parter at vide hvorfra en påstand stammer. Dette dokument har til formål at skabe overblik over hvordan brugerstyringsattributter kan indgå i en webservice kontekst. Dokumentationen for brugerstyringsattributter konkretiserer en del af referencearkitekturen [REF-ARK] omhandlende datamodel. Der vælges som sådan ikke datamodel i dette dokument, men der i mod krav til indhold. 2. Læsevejledning Den samlede pakke omfatter en række dokumenter, hvoraf nærværende dokument med fordel kan læses først for at få et overblik. De detaljerede overvejelser findes i de resterende dokumenter, som kan læses efter følgende skabelon: - Brugerstyringsattributter Indhold ([BRUGERATT-IND]). Konkret indhold af attributter vedrørende brugeren. - Brugerstyringsattributter Politikker ([BRUGERATT-POL]). Politik for de enkelte oplysninger om brugeren: hvor kommer oplysningen fra, hvem er autoritativ kilde til oplysningen og hvem verificerer oplysningen. - Brugerstyringsattributter Ræsonnementer ([BRUGERATT-RÆS]). Ræsonnement for de enkelte brugeroplysninger dokumenteres med reference til eksisterende standarder, krav fra eksisterende services eller projekter eller fra lignende projekter her i landet eller i udlandet. 3. Aktører På konceptuelt niveau involverer sundhedssektorens webservice infrastruktur 4 aktørtyper: WSC: Web Service Consumer. Den aktør, der ønsker at kalde en service for at gennemføre en forretningsgang. IDP: Identity Provider: En central aktør, der kan autentificere en WSC og udstede en simpel sikkerhedsbillet (bootstrap token) som udtrykker at WSC blev autentificeret, hvordan og hvornår. STS: Security Token Service. En central aktør, der kan udstede sikkerhedsbilletter (identity tokens) om en WSC til brug mod en specifik WSP. STS udmærker sig ved at både WSC og WSP stoler på sikkerhedsbilletter udstedt her. IDP og STS er ofte kollokerede. WSP: Web Service Provider. Den aktør, der udbyder en service og som skal processere sikkerhedsbilletter udstedt af STS for at autentificere og autorisere en WSC. De 4 aktører og det overordnede flow er illustreret på figuren nedenfor. Dette flow er i overensstemmelse med standarden for identitetsbaserede web services (OIOIDWS) fra ITST: Side 2 af 6
4. Autentifikation Første skridt i at foretage et identitetsbaseret webservice kald er at autentificere brugeren. Dette foregår som angivet på figuren ovenfor ved at WSC en danner en besked indeholdende en brugers akkreditiver. I sundhedssektoren identificeres en bruger ved en signatur dannet med et OCES certifikat. Resultatet er et authentication token, der sendes til IDP en hvor signaturen valideres og hvor der dannes et bootstraptoken 1 med lige netop nok information om brugeren til at en STS senere kan danne et rigere og WSP specifikt identity token. 1 I [REF-ARK] kaldes denne token for ID billet. Side 3 af 6
Bootstraptokens lever længe (1 arbejdsdag) og kan derfor med fordel udstedes i forbindelse med initielt dagligt login. 5. Veksling af identitytoken Når WSC ønsker at kalde en specifik WSP kræves et identitytoken 2, der indeholder netop de attributter om brugeren, som WSP har brug for (jævnfør afsnittet om politikker og attributter nedenfor). Et sådant identitytoken opnås ved at WSC kalder STS med et bootstraptoken og en angivelse af hvilken service der ønskes kaldet. I kaldet kan WSC medsende ekstra attributter som WSP har brug for og STS vil nu om muligt verificere værdien af disse, samt påklistre dem i det resulterende identity token. Slutteligt returneres det udstedtee identitytoken til WSC. Identitytokens er kortlivede, men kan let dannes igen ved et kald til STS. 6. Autorisation Når WSP modtager et webservicekald, der indeholder attributter om en bruger, anvendes blandt andet 3 disse oplysninger til at autorisere brugeren. WSP tjekker at kaldet medsender de i politikken definerede attributter og at værdierne i attributterne direkte giver rettigheder til at udføre kaldet eller til at slå yderligere adgangsgivendee oplysninger 4 op. Hvis dette er tilfældet, udføres kaldet og svaret returneres. Alternativt returneres en SOAP fejl. 2 I [REF-ARK] kaldes denne token for attributbillet. 3 Der kan være andre forhold der egulerer autorisation til anvendelse af service. Dette kan være behandlingsre- projekt at præcisere hvad lation eller revanskriterier. 4 Det kunne være behandlingsrelation eller relevanskriterier. Det ligger udenfor dette der ligger i sådanne yderligere adgangsgivende oplysninger. Side 4 af 6
7. Politikker Afhængig af hvilken service en WSP udbyder vil den have behov for forskellige oplysninger om aftageren af oplysningerne (WSC). Nogle services kræver ingen viden fordi de data der udstilles ikke er sensitive. Andre kræver præcis viden om den fagperson der aftager data for at kunne afgøre om vedkommende skal have lov at tilgå oplysningerne. En WSPs behov udtrykkes i politikker, der omfatter en række attributoplysninger, som skal medsendes et web service kald. En WSP kunne f.eks. have behov for at kende en persons arbejdsfunktion, sundhedsfaglig autorisationskode og navn. Politikker kan udtrykkes teknisk og det er muligt at lave en ren teknisk løsning, hvor politikken for en service indlejres i servicens tekniske beskrivelse. Dette er dog udenfor dette dokuments omfang. 8. Attributter Et web servicekald til en WSP skal altid ledsages af et sæt attributter, der matcher den politik som WSP kræver. I praksis betyder det, at der altid skal medsendes et matchendee sæt attributter. Attributter kan stamme fra forskellige parter: WSC: Oplysninger om brugerens aktuelle rolle på et hospital, den sundhedsfaglige autorisation der anvendes lige nu, mm. kendes kun hos WSC og medsendes derfor herfra. STS: Når brugeren autentificeres af IdP sker dette på basis af et OCES certifikat, der i sig selv rummer oplysninger om brugeren. For POCES og MOCES certifikaterr kan et unikt id i certifikatet (hhv. PID og CVR:RID) desuden veksles til et CPR-nummer. STS en vil dels kunne hente attributter om en bruger i bagvedliggende registre, dels kunne verificere claims sendt af WSC imod andre registree med CPR-nummer som nøgle. Attributter angives med et navn og en værdi. 9. Attribut Metadata Attributter der indlejres i en sikkerhedsbillet (bootstraptoken, identitytoken) påklistres metainformation, der tillader en part at afgøre: Side 5 af 6
Claimant: Authority: Verifier: 10. Referencer Den aktør, der fremsætter påstanden om afsenderen. Dette kan være WSC eller STS. Den aktør, der definerer værdien for en påstand. Dette kan være andre parter f.eks. Sundhedsstyrelsen eller Det Centrale Personregister. Den aktør, der har verificeret korrektheden af værdien af en påstand ifht. et autoritativt register. Dette kan være STS. BRUGERATT-IND Brugerstyringsattributter Indhold, version 0.5, 14/5 2010. BRUGERATT-RÆS Brugerstyringsattributter Ræsonnementer, version 0.5, 14/5 2010. BRUGERATT-POL Brugerstyringsattributter Politikker, version 0.5, 14/5 2010. REF-ARK Referencearkitektur for Sundhedsvæsenets Brugerrettighedsstyring (SBRS), version 0.97, 5/1 2010. WS-FED http://specs.xmlsoap.org/ws/2006/12/federation/ws-federation.pdf Side 6 af 6