ADGANGSSTYRING. 26. Februar 2019

Transkript

1 ADGANGSSTYRING 26. Februar 2019

2 Agenda Adgangsstyring for brugere Forretningsmål med sikkerhedsmodellen Gennemgang af KOMBITs sikkerhedsmodel Sikkerhedsmodellen repræsenteret i SAML 2.0 Adgangsstyring trin for trin Adgangsstyring for systemer Aktører Aftalebegrebet Anvendelse af Adgangsstyring

3 ADGANGSSTYRING FOR BRUGERE

4 Forretningsmål Sikre en ensartet model for adgange og rettigheder på tværs af kommunernes fagsystemporteføljer Sikre samme høje niveau af sikkerhed i alle fagsystemer Give kommunener ét sted at administrere rettigheder Give kommunerne kontrollen over login processen, så de kan administrere brugerkonti, password-reset og valg af login-faktorer i egen løsning

5 Gevinster for leverandøren Mulighed for at reducere mængden af ikke-fagsystem kode, der skal vedligeholdes, supporteres, dokumenteres, testes m.m. Minimere implementeringsopgaven ved nye kunder, så man hurtigere kan komme fra opstart til normal drift. Rammearkitektur-compliance

6 GENNEMGANG AF KOMBITS SIKKERHEDSMODEL

7 Terminologi (leverandørbegreber) Brugervendt system Et it-system (typisk et fagsystem), der har en brugergrænseflade der anvendes af slutbrugere. Brugersystemrolle En rettighed, der kan tildeles brugere i det brugervendte system. Dataafgrænsningstype Et dataområde der kan afgrænses indenfor, når en brugersystemroller tildeles til en bruger

8 Terminologi (kommunebegreber) Jobfunktionsrolle En gruppering af brugersystemroller, som kommunen anvender til at lette administration af rolletildelinger. Bemærk at Jobfunktionsroller ikke er synlige for, og aldrig kommer i spil, i kommunikationen med et brugervendt system. Dataafgrænsningsværdi En konkret tildeling af et dataudsnit indenfor en dataafgrænsningstype (se illustrationen på næste siden)

9 Illustration gruppering af Jobfunktionsroller Brugersystemroller tildeles understøtter tildelt Dataafgrænsningstyper Dataafgrænsningsværdier Forståes og håndhæves af Brugervendt system tilgår

10 Illustration Godkend faktura Dataafgrænsningstyper Dataafgrænsningsværdier Jobfunktionsroller Brugersystemroller Afdeling = IT Afdelingen Beløbsloft = Afdeling Beløbsloft

11 Illustration En bruger tilgår et Brugervendte system Der medsendes Jobfunktionsroller. Disse veksler KOMBITs infrastruktur til Brugersystemroller og dataafgrænsningsværdier Jobfunktionsroller Godkend Faktura Afdeling= IT Afdelingen Beløbsloft = Brugervendt system tilgår

12 Dataafgrænsningstyper og -værdier Dataafgrænsningstyper er en dimension, man som leverandør, kan vælge at lægge ned over sine brugersystemroller. Som leverandør kan man selv vælge hvilke dataafgrænsnings-typer der understøttes af hvilke brugersystemroller. Man kan vælge om en dataafgrænsningstype er krævet, dvs den skal udfyldes med en værdi, eller den kan udelades. Og man kan vælge hvilke værdier der er lovlige (man kan dog ikke være sikker på at man modtager lovlige værdier)

13

14 Fortolkningsregel for ingen afgrænsning En dataafgræning indsnævrer hvilke data der må tilgås med en brugersystemroller. Hvis en dataafgrænsningstype ikke anvendes, skal det fortolkes som alle data / alle værdier. Bemærk dog at indsnævringen er akkumulerende, så hvis der afgrænses på flere dataområder samtidig, så er det kun de data der er indeholdt i alle afgrænsningerne der må tilgås.

15 SIKKERHEDSMODELLEN REPRÆSENTERET I SAML 2.0

16 SAML Agenda Kort intro til SAML KOMBITs attributprofil Sikkerhedsmodel udtrykt i OIO-BBP strukturen

17 SAML Aktørene i KOMBIT sikkerhedsmodellen Brugervendt system (Service Provider) Etablering af tillid SAML Protokollen Bruger (User Agent) Context Handler (Identity Provider) Kommunale Identity Providere

18 SAML frameworks Der findes rigtigt mange SAML frameworks, og de tager sig alle af alt det praktiske med beskedformater og kommunikationen Digitaliseringsstyrelsen har udviklet 2 sådanne rammeværk til hhv Java og.net platformen (OIOSAML.java og OIOSAML.net) Men der er rigtigt mange andre alternativer, som alle vil fungere fint med KOMBITs infrastruktur

19 SAML protokollen kommunikationen Alle SAML beskeder en XML-baserede, og der er 4 relevante typer af beskeder som beskrives senere XML beskederne sendes enten som en enkodet URL parameter via brugerens browser i et HTTP-GET request, eller via brugerens browser som body i et HTTP- POST request Der er ingen direkte kommunikation (webservice kald eller lignende) mellem det brugervendte system og Context Handleren

20 SAML protokollen relevante beskeder AuthnRequest Dannes af det brugervendte system når det ønsker at logge en bruger på, og sendes til Context Handleren via brugerens browser (typisk via HTTP-GET). Response (aka SAMLResponse) Et svar fra Context Handleren på et AuthnRequest. Indeholder enten en fejlbesked, eller et SAML token. Sendes via brugerens browser til det brugervendte system (typisk som et body payload i en HTTP-POST)

21 SAML protokollen relevante beskeder LogoutRequest En besked der fortæller at brugeren ønsker at logge ud. Kan både dannes af det brugervendte system og sendes til Context Handleren, samt sendes fra Context Handleren til det brugervendte system. I begge tilfælde sendes beskeden via brugerens browser (HTTP-POST foretrækkes for at undgå redirect loop restriktioner i browseren) LogoutResponse Et svar på et LogoutRequest, som enten sendes fra Context Handleren til det brugervendte system, eller skal sendes fra det brugervendte system til Context Handleren. I begge tilfælde via brugerens browser.

22 AuthnRequest Simpel XML struktur uden særlige opmærksomhedspunkter Requestet skal signeres med RSA-SHA256 algoritmen Signaturen vedlægges som en ekstra URL parameter når man anvender HTTP-GET, men indlejres i XML en via XMLDSIG hvis der anvendes HTTP-POST <saml2p:authnrequest AssertionConsumerServiceURL=" Destination=" ForceAuthn="false" ID="a3e87841j3g5e499i376eeae3edb56" IsPassive="false" IssueInstant=" T07:55:48.930Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:saml:2.0:protocol"> <saml2:issuer xmlns:saml2="urn:oasis:names:tc:saml:2.0:assertion"> </saml2:issuer> </saml2p:authnrequest>

23 Response Kompleks XML struktur, der indeholder en fejlbesked eller token. Hvis der medfølger et token, er det krypteret, og skal dekrypteres før det kan læses Beskeden sendes altid som HTTP-POST pga størrelsen <Response Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" Destination=" ID="idac97669bec99434a b5e93" InResponseTo="a13b c47e138gf64ci3g81hag" Version="2.0" IssueInstant=" T09:26: Z" xmlns="urn:oasis:names:tc:saml:2.0:protocol"> <Issuer xmlns="urn:oasis:names:tc:saml:2.0:assertion"> stoettesystemerne.dk </Issuer> <Status> <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </Status> <EncryptedAssertion xmlns="urn:oasis:names:tc:saml:2.0:assertion">... snip... </EncryptedAssertion> </Response>

24 Det dekrypterede payload i en Response besked Indeholder brugerens identitet og rettigheder (brugersystemroller og tilhørende dataafgrænsningsværdier) Nedenstående eksempel er meget forsimplet, da et fuldt eksempel vil fylde flere sider... <Assertion xmlns="urn:oasis:names:tc:saml:2.0:assertion"> <Issuer> <Signature /> <Subject> <NameID> C=DK,O= ,CN=Hans Hansen,Serial=74c08b2b-212b-4f6d-9ce6-0fba d </NameID> </Subject> <AttributeStatement> <Attribute Name="dk:gov:saml:attribute:AssuranceLevel"> <AttributeValue>4</AttributeValue> </Attribute> <Attribute Name="dk:gov:saml:attribute:Privileges_intermediate"> <AttributeValue> PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLT... </AttributeValue> </Attribute> </AttributeStatement> </Assertion>

25 KOMBITS ATTRIBUTPROFIL

26 Oplysninger i det udstedte token KOMBITs attributprofil foreskriver hvilke oplysninger der er tilgængelige i det udstedte token, samt hvilket format disse oplysninger skal udtrykkes i. Oplysninger om brugerens identitet (navn og ID) Oplysninger om det sikkerhedsniveau der er logget på med Oplysninger om brugerens tilhørsforhold (CVR på myndighed) Oplysninger om brugerens rettigheder (Brugersystemroller og Dataafgrænsningsværdier) Versioneringsoplysninger vedrørende den anvendte version af attributprofilen

27 Eksempel på Subject i et SAML token Subject er altid på X509SubjectName formatet O indeholder CVR nummeret på den myndighed brugeren kommer fra CN indeholder en pæn præsentation af brugerens navn Serial indeholder brugerens unikke ID, som kan anvendes til opslag i fx støttesystemet Organisation, og indekserne <Subject> <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"> C=DK,O= ,CN=Hans Hansen,Serial=74c08b2b-212b-4f6d-9ce6-0fba d </NameID> </Subject>

28 Eksempel på attributter i et SAML token SpecVer / KombitSpecVer er versionsnummer (pt kun én version) AssuranceLevel er en værdi fra 1 til 4 Privileges_intermediate er en base64 enkodet OIO-BPP struktur, der indeholder brugerens rettigheder <AttributeStatement> <Attribute Name="dk:gov:saml:attribute:SpecVer"> <AttributeValue>DK-SAML-2.0</AttributeValue> </Attribute> <Attribute Name="dk:gov:saml:attribute:KombitSpecVer"> <AttributeValue>1.0</AttributeValue> </Attribute> <Attribute Name="dk:gov:saml:attribute:AssuranceLevel"> <AttributeValue>3</AttributeValue> </Attribute> <Attribute Name="dk:gov:saml:attribute:Privileges_intermediate"> <AttributeValue> PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLT... </AttributeValue> </Attribute> </AttributeStatement>

29 SIKKERHEDSMODELLEN UDTRYKT I OIO-BBP STRUKTUREN

30 OIO-BPP OIO Basic Privilege Profile er en XML struktur der kan udtrykke rettighedsmodellen fra STS Administrationsmodulet Udarbejdet af Digitaliseringsstyrelsen i 2011, og tilpasset af KOMBIT i 2014 til at understøtte KOMBITs sikkerhedsmodel Leveres via SAML tokenet fra Context Handleren i attributten dk:gov:saml:attribute:privileges_intermediate, som en BASE64 enkodet XML streng.

31 OIO-BPP XML strukturen <bpp:privilegelist xmlns:bpp=" xmlns:xsi=" <PrivilegeGroup Scope="urn:dk:gov:saml:cvrNumberIdentifier: "> <Privilege> </Privilege> </PrivilegeGroup> <PrivilegeGroup Scope="urn:dk:gov:saml:cvrNumberIdentifier: "> <Privilege> </Privilege> Et <PrivilegeGroup> element tilsvarer én brugersystemrolle <Constraint Elementet Name=" <Privilege> indeholder ID et på brugersystemrollen </Constraint> </PrivilegeGroup> <PrivilegeGroup Scope="urn:dk:gov:saml:cvrNumberIdentifier: "> <Privilege> </Privilege> Dataafgrænsningsværdier udtrykkes via et <Constraint> element <Constraint Name=" Dataafgræsningsværdierne kobles til den enkelte Brugersystemrolle </Constraint> <Constraint Name=" IT Afdelingen </Constraint> </PrivilegeGroup> </bpp:privilegelist>

32 Adgangsstyring trin for trin 1. SAML-enable dit fagsystem 2. Modellere en rettighedsmodel 3. Tilslutte STS Administrationsmodul 4. Teste hul-igennem

33 1. SAML-enabling af ens it-system 1. Vælg om SAML skal indarbejdes i ens fagsystem, eller der anvendes en forbrænder/afkoblings-komponent 2. Masser af SAML frameworks at vælge mellem, se evt ( 3. Digitaliseringsstyrelsen stiller OIOSAML til rådighed for Java og.net platformen, men andre SAML frameworks og komponenter vil også fungere 4. Bemærk krav til anvendelse af OCES certifikat

34 2. Modellering af rettighedsmodel 1. Er der en eksisterende rettighedsmodel i fagsystemet? Kan den evt anvendes direkte i KOMBIT modellen, eller skal der laves en oversættelse (fx på runtime via en forbrænder) 2. Skal brugersystemrollerne være aktør-baserede (leder, administrator, sagsbehandler, osv) eller handlings-baserede (se sag, opret sag, udbetal ydelse, osv) 3. Er dataafgrænsning nødvendig (typisk drevet af lovgivning og evt kundeønsker) i så fald hvilke dataområder, og for hvilke brugersystemroller er det relevant.

35 3. Tilslutte til STS Administrationsmodul 1. Forudsætning at ens organisation er oprettet i STS Administrationsmodulet (kontakt helpdesk for oprettelse) 2. Rettigheder til administratorer tildeles via NemLog-in brugeradministration 3. Tilslut it-system via simpel web-form i STS Administration Basale informationer (navn, kontakt , osv) SAML metadata (trukket fra ens eget fagsystem) Liste af brugersystemroller, og evt dataafgrænsningstyper 4. Bemærk at KOMBIT har både et TEST og et PROD miljø

36 4. Teste hul-igennem 1. Test af login gennem Context Handleren forudsætter at man har en kommunal Identity Provider tilsluttet 2. Der kan være fordele i at tilslutte sin egen til infrastrukturen, eller indgå en samarbejdsaftale med en kommune om at bruge deres 3. Hvis man vælger at tilslutte sin egen, skal man dog stadig bestille Jobfunktionsroller via helpdesk, da man ikke som leverandør (endnu) kan oprette disse via STS Administrationsmodulet

37 Spørgsmål inden vi kigger på Adgangsstyring for systemer?

38 ADGANGSSTYRING FOR SYSTEMER

39 Aktører Serviceudbyder En serviceudbyder er et it-system der udstiller webservices (SOAP, REST, MQ, FTP,...), som kan tilgås af Anvendersystemer Myndighed En myndighed er den part der ejer de data der udstilles og behandles af serviceudbyderen Anvendersystemer Et anvendersystem er et fagsystem eller andet it-system, der ønsker at tilgå data eller services udstillet af et andet it-system

40 Aftalebegrebet 1. Serviceudbyderen (leverandøren) opretter sine services i STS Administrationsmodulet, og angiver for hvilke myndigheder der udstilles/behandles data (default er alle) 2. Anvendersystemet (leverandøren) anmoder om adgang til disse services for en eller flere myndigheder 3. Myndighederne godkender aftalen 4. Anvendersystemet kan nu kalde servicene

41 Illustration Anvendersystem Serviceudbyder Anmoder om adgang til, og tilgår services Udstiller services Myndighed Ejer data og godkender adgange

42 Sikkerhedsmodellen 1. Baserer sig på SAML-tokens som adgangsstyring for brugere 2. Anvender en tilsvarende attributprofil, og OIO-BPP struktur til at udtrykke rettigheder 3. Anvendelsesflowet minder også meget om bruger-scenariet, hvilket illustreres på næste slide

43 Anvendelsen af adgangsstyring for systemer Anvendersystem Serviceudbyder Security Token Service Anvendersystemet Serviceudbyderen foretager validerer kalder RequestSecurityToken sikkerheden et kald til servicen på kaldet udstillet på støttesystemet af serviceudbyderen Security Token Service a) Det Kaldet Libety udstedte Basic foregår token SOAP altid vedlægges i Binding kontekst profilens af kaldet én myndighed valideringer og udføres én service b) Der SAML foretages tokenets en signatur sikring af valideres kaldet jf op Liberty mod Basic Security SOAP Token Binding Servicens profilen certifikat 2. Hvis c) Anvendersystemet Security Token Servicens har en godkendt certifikat har serviceaftale, man udvekslet udstedes på et et tidligere SAML token tidspunkt a) SAML tokenet er gyldigt i 8 timer, og skal caches af Anvendersystemet

44 Dokumentation og vejledninger Der er udstillet vejledninger til Administrationsmodulet, Adgangsstyring for brugere og Adgangsstyring for systemer på KOMBITs dokumentbibliotek Dokumentbibliotek STS Administrationsmodul brugervejledning for leverandører Adgangsstyring for brugere vejledning til Adgangsstyring for brugere Adgangsstyring for systemer vejledning til token sikkerhed

45 Spørgsmål?

46 TUSIND TAK FOR I DAG!