Vejledning i lokal implementering af Identity
Lokal implementering af Identity Provider En vejledning til kommunernes og ATP’s opgaver Version 1.0 februar 2015 KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 1/21 Klik her for at angive tekst. Indhold 1. 2. 3. 4. 5. 6. 7. Baggrund ................................................................................................................... 3 Hvad er en Identity Provider? .................................................................................... 3 Hvorfor en IdP? ......................................................................................................... 4 Hvordan ser en IdP ud? ............................................................................................ 4 Produkter som kan udstille en SAML 2.0 Identity Provider ....................................... 5 Krav og anbefalinger til Identity Provider .................................................................. 6 Implementeringsovervejelser .................................................................................... 7 7.1 Overvejelser relateret til etablering af Identity Provider ..................................... 8 8. Implementeringsmønstre........................................................................................... 9 8.1 Mønster 1: Directory, APOS og IdM system ...................................................... 9 8.1.1 Odense Kommune’s IdP-løsning .............................................................. 12 8.2 Mønster 2: Microsoft AD og AD FS alene ........................................................ 16 8.3 Tekniske overvejelser om AD FS ..................................................................... 17 9. 10. 11. 12. Skabelon til beskrivelse af kommuneløsninger ....................................................... 18 Appendiks A: Overvejelser i forhold til NIST 800-63 standarden ............................ 19 Appendiks B: Overvejelser om persondataloven .................................................... 20 Referencer ............................................................................................................... 21 KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 2/21 1. Baggrund En central forudsætning for at myndigheder kan ibrugtage SAPA, KY, KSD samt de fælleskommunale støttesystemer er, at de etablerer en såkaldt lokal ”Identity Provider” (herefter forkortet IdP), som kan logge deres lokale brugere på de fælleskommunale systemer. Dette dokument beskriver en række overvejelser om etablering af kommunale IdP’er - og er tænkt som en støtte til den lokale implementering. Beskrivelsen er henvendt til kommunale it-arkitekter og projektledere (samt deres leverandører), som skal planlægge og gennemføre etablering og tilslutning af en lokal Identity Provider. En lang række kommuner (>35) har allerede etableret en IdP i forbindelse med tilslutning til Danmarks Miljøportal, WAYF mv. For disse vil en stor del af arbejdet med etablering af den basale infrastruktur allerede være gjort, og her vil hovedfokus naturligt være på konfigurering af en ny forbindelse til Støttesystemerne. 2. Hvad er en Identity Provider? En Identity Provider er en service etableret af den enkelte myndighed, som kan autentificere myndighedens medarbejdere (log-in) samt udstede en digital ”billet”, der fortæller omverdenen om vedkommendes adgange til eksterne systemer (i form af såkaldte jobfunktionsroller). IdP’en agerer populært sagt som en ”billetudsteder” og udsteder ”billetter” til medarbejderne i organisationen, som efterfølgende kan benyttes til at få adgang til eksterne systemer. De eksterne systemer stoler på billetten via en digital signatur fra IdP’en, og de uddelegerer ansvaret for brugerhåndteringen til myndigheden. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 3/21 En konceptuel illustration af en IdP findes nedenstående figur: 3. Hvorfor en IdP? Den grundlæggende tanke er, at myndighederne selv bedst kan håndtere deres medarbejdere/brugere, og at de vil foretrække at administrere deres adgange i de lokale systemer, som man i forvejen anvender til administration af interne adgange – eksempelvis et Active Directory (AD), et Identity Management system (IdM) eller lignende. Ved at myndigheden udstiller en IdP, behøver de fælleskommunale systemer ikke operere med lokale brugerdatabaser eller udstede fx kodeord til brugerne. De primære fordele er flg.: Brugerne administreres ved ”kilden”, hvilket giver den bedste datakvalitet eksempelvis når de stopper eller skifter job. Dobbelt-administration undgås (både lokal og ekstern administration). Brugere får ikke nye akkreditiver (fx passwords) til nye systemer, men kan tilgå eksterne systemer med single sign-on og genbrug af eksisterende akkreditiver. Eksisterende interne procedurer og værktøjer anvendes til genåbning af adgang ved glemt kodeord. 4. Hvordan ser en IdP ud? En IdP består af software, der afvikles fra en server, som kan kaldes af et eksternt system, når en bruger skal logge på. En IdP vil typisk blive placeret fysisk sammen med KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 4/21 myndighedens øvrige infrastruktur – men den kan også drives separat fra denne. Konkrete eksempler findes sidst i dokumentet. IdP’ens snitflade mod omverdenen er baseret på profiler af den åbne SAML 2.0 standard. Dette betyder, at myndigheden har fuldstændig frihed til at vælge den teknologi og det produkt, som IdP’en er baseret på – så længe den overholder den specificerede snitflade mod omverdenen. 5. Produkter som kan udstille en SAML 2.0 Identity Provider Der findes en lang række både kommercielle og open source produkter 1, som kan implementere en SAML-baseret Identity Provider. Der kan være mange faktorer i myndigheders valg af løsning, herunder integrationen med den infrastruktur, myndigheden har i forvejen. En række kommuner har allerede gode erfaringer med at etablere en SAML 2.0 Identity Provider via føderationer mod Danmarks Miljøportal, WAYF-løsningen, Silkeborg Data mv. KOMBIT har på nuværende tidspunkt kendskab flg. typer af kommunale IdP-løsninger: Microsoft AD FS 2.0 produktet kan etablere en Identity Provider, som er forbundet til et Active Directory brugerkatalog (Ballerup Kommune). NetIQ Identity Manager og Access Manager produktsuiten kan bruges som en ”Identity Management suite”, der samtidig kan udstille en IdP (Faaborg-MidtFyn kommune) SafeWhere Identify produktet benyttes af nogle kommuner som føderationsserver, som enten kan operere mod eget brugerkatalog eller mod et lokalt AD (Odense kommune) Disse konkrete produkter og teknologier er blot nævnt som eksempler og til inspiration, og en IdP kan sagtens etableres med anden teknologi. Der henvises til siden http://en.wikipedia.org/wiki/SAML-based_products_and_services for en liste over kendte SAML implementeringer (>70). I slutningen af denne guide præsenteres udvalgte eksempler fra det kommunale landskab i større detaljer. 1 Fx SimpleSAML PHP KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 5/21 6. Krav og anbefalinger til Identity Provider Nedenfor angives en række krav til den IdP, som myndigheder skal etablere – enten selv eller med hjælp fra en leverandør/konsulenter. Standarder: IdP’en skal overholde KOMBIT’s Attributprofil2 af SAML 2.0 standarden samt OIOSAML version 2.0.9. Dette sikrer en veldefineret snitflade til Støttesystemerne. IdP’en skal konfigureres, så der anvendes de samme brugernavne i SAML billetter, som der udstilles via støttesystemet Organisation. Dette sikrer, at supplerende opslag på brugeren i Organisation udført af et fagsystem vil ramme den korrekte bruger. Der kommer en vejledning til Organisation, der behandler denne problemstilling. IdP’ens sikkerhedsniveau (assurance level) skal vurderes og angives ved tilslutning til Støttesystemerne. Sikkerhedsniveau’er angives i intervallet 1 – 4, og der vil på et senere tidspunkt blive udgivet en vejledning i, hvorledes det bestemmes. IdP’en skal kunne autentificere alle brugere i organisationen, som skal kunne tilgå støttesystemer, SAPA, KY eller KSD, samt kunne levere en liste med de jobfunktionsroller, som brugerne er tildelt. Dette betyder, at IdP’en skal understøtte de akkreditiver (fx domænelog-in, passwords, 2-faktor løsninger eller medarbejdersignatur), som myndigheden ønsker disse brugere benytter til autentifikation mod eksterne løsninger. SLA’er: IdP’en skal overholde myndighedens ønskede krav til oppetid og svartider etc. Bemærk at adgang til støttesystemer, SAPA, KY og KSD ikke er muligt, når systemet er nede, så derfor bør oppetidskravene i udgangspunktet være høje. Hvis man i forvejen har etableret en IdP, bør det overvejes om den nuværende infrastruktur er robust nok til at understøtte forretningskritiske applikationer eksempelvis om der er anvendt redundans etc. I modsat fald bør infrastrukturen opgraderes. o Et fornuftigt niveau kunne være 99.5 – 99.9% oppetid og en svartid på 1,5 sekund i 90% af tilfældene for en brugerautentifikation. IdP’en skal overholde myndighedens krav til kapacitet, herunder det forventede antal medarbejdere, der samtidigt skal kunne logge på eksterne systemer. o Et fornuftigt startniveau kunne være antallet af medarbejdere, som skal bruge SAPA, KY og KSD. IdP’en skal overholde myndighedens krav til skalérbarhed, herunder i forhold til forventet vækst i antal brugere og systemer. o Mange IdP-løsninger kan skaleres horisontalt ved at tilføje flere nye servere, men det valgte produkts skaleringsevne bør dokumenteres. Andre krav: 2 https://sharekomm.kombit.dk/P024/Delte%20dokumenter/Bilag%202.%20Sikkerhed%20version%20 1.3%2018.%20marts%202014.pdf KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 6/21 Løsningen skal overholde persondatalovens og sikkerhedsbekendtgørelsens krav, herunder krav til kontrol med afviste adgangsforsøg (SBK §18) og logning (SBK §19). Identity Provideren skal overholde de fællesoffentlige politikker for logning og tidssætning som beskrevet på http://www.digst.dk/Loesninger-oginfrastruktur/NemLogin/Tekniske-krav. Der skal udstedes et TLS-certifikat til IdP’en, som bærer det navn, serveren er registreret som i DNS (fx login.testkommune.dk). Certifikatet skal naturligvis være accepteret som troværdigt af alle de computere (samt deres web browsere), der skal benytte IdP'en. Anbefalinger: Myndighedens Identity Provider bør ikke udstille et domænelog-in direkte på internettet (dvs. log-in med brugernavn og statisk password). Hvis IdP’en ønskes udstillet på internettet, bør den af sikkerhedsmæssige grunde kombineres med 2-faktor autentifikation, certifikater, deviceautentifikation eller anden form for sikker autentifikation, inden et domænelog-in kan forsøges. Herved undgås, at eksterne angribere kan forsøge at gætte et kodeord for en myndighedsbruger eller kan spærre brugerens konto ved at indtaste forkert kodeord flere gange. IdP’en skal overholde myndighedens sikkerhedspolitik og skal understøtte lokalt definerede processer og instrukser for brugerhåndtering. Det anbefales at foretage et kritisk serviceeftersyn af de eksisterende processer for oprettelse/nedlæggelse af brugere i brugerkataloget og vedligeholdelse af deres adgange, idet der nu kan gives adgang til nye systemer med følsomme data. Det anbefales, at IdP’en etableres med en kvalitet og robusthed modsvarende anden kritisk infrastruktur – eksempelvis med dublerede komponenter (fx clustering) og fail-over. IdP’en bør omfattes af myndighedens backupprocedurer, it-beredskab og underlægges it-revision. IdP’en bør testes grundigt inden produktionssætning og der bør være et anvendeligt testmiljø til dette. IdP’en bør hærdes og sikkerhedstestes som et sikkerhedskritisk system. 7. Implementeringsovervejelser I dette afsnit beskrives en række implementeringsovervejelser i forbindelse med etablering af en lokal IdP. Beskrivelsen i det følgende er teknologineutral, men i efterfølgende afsnit gives eksempler fra kommuner, som har benyttet specifikke produkter. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 7/21 7.1 Overvejelser relateret til etablering af Identity Provider Den netværksmæssige placering af Identity Provideren skal besluttes. Kommunikationen mellem Støttesystemernes komponenter (ContextHandler) og IdP’en sker via brugerens browser, så det er tilstrækkeligt, at browseren kan tilgå IdP’en direkte. IdP’en kan derfor både placeres på et internt netværk (helt isoleret fra internettet) eller i en DMZ zone3, som kan tilgås fra internettet – eller som en kombination med en proxy i DMZ. Generelt anbefales det i udgangspunktet at IdP’en placeres på et internt netværk for at reducere angrebsfladen – med mindre der eksplicit er behov for at logge på fra enheder, som ikke har adgang til det interne netværk. Bemærk i den forbindelse, at man fra hjemmearbejdspladser med VPN-adgang typisk vil have adgang til det interne netværk. Beslutningen om placering er dermed en afvejning af forhold vedr. sikkerhed og tilgængelighed. IdP’en skal have forbindelse til brugerkataloget, så log-in kan valideres, og så jobfunktionsroller og andre attributter om brugeren kan hentes. Typisk sker dette via LDAP protokollen eller lignende. IdP’en skal evt. konfigureres til at tilgå andre ”kataloger” med brugerinformation (fx organisationsinformation fra organisationssystemer) som skal indlejres i udstedte SAML tokens. IdP’en skal konfigureres med konverteringsregler (”claims rules”) som omformer attributter fra brugerkataloget til det format, der forventes i SAML tokenet i henhold til KOMBIT’s attributprofil4. Dette kunne eksempelvis bestå i at oversætte et gruppenavn i et brugerkatalog til et modsvarende rollenavn udtrykt via en URI, hvis roller bliver implementeret som lokale grupper. Et andet eksempel kunne være at opsætte attributter, som anvendes i dynamiske dataafgrænsninger – eksempelvis attributter som fortæller brugerens organisatoriske tilhørsforhold. Man bør tage stilling til, om IdP’ens log-in side både skal kunne håndtere browsere fra PC’er og mobile enheder. Dette skal registreres i Administrationsmodulet. Man bør afklare, om IdP’en evt. kun må tilgås fra særlige enheder (pc’er, tablets, mobile enheder), der er under myndighedens kontrol. Eksempelvis kan man udstyre enheder med device certifikater, benytte MDM-løsninger eller på anden måde sikre sig, at brugere kun kan logge på fra autoriserede enheder. Dette kan give et ekstra lag af sikkerhed. Der bør udformes en politik for logning af afviste adgangsforsøg og opfølgning på samme, spærring af brugere etc. 3 Endpoint for SOAP baseret logout skal placeres i DMZ. Hvis kommunen kun udbyder protokoller for single logout, der kommunikerer via browseren (Redirect eller POST binding), er de ikke nødvendigt at have en proxy i DMZ af hensyn til logout. 4 Denne er udgivet som bilag på 2 under integrationsvilkår på https://sharekomm.kombit.dk/P024/Delte%20dokumenter/Forms/Vejledninger%20og%20vilkaar.asp x KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 8/21 8. Implementeringsmønstre Implementeringen af en Identity Provider vil afhænge af den enkelte myndigheds itportefølje herunder netværksdesign, platforme og produktvalg. Da disse varierer betydeligt fra myndighed til myndighed, kan KOMBIT ikke opstille en komplet kogebog, der dækker alle situationer. På baggrund af en række surveys over myndighedsløsningerne, er det imidlertid KOMBIT’s hypotese, at der kan etableres nogle ”arketypiske” implementeringsmønstre, der dækker alment udbredte konfigurationer. Dette dokument vil blive udvidet med mere detaljerede implementeringsovervejelser til hver af de identificerede mønstre, efterhånden som de identificeres. En del af dette vil bestå i indsamling af implementeringserfaringer, der allerede er gjort af de kommuner, som er langt fremme på området, således at disse erfaringer kan udbredes. Via surveys er der identificeret flg. udbredte brugerstyringsløsninger hos kommuner: Microsoft AD løsning (alene) AD i kombination med NetIQ Identity Manager AD i kombination med SafeWhere Identify Ovenstående liste skal opfattes som første kandidater, der skal kvalificeres yderligere. 8.1 Mønster 1: Directory, APOS og IdM system Figuren nedenfor illustrerer en logisk arkitektur hos en myndighed, der anvender et brugerkatalog, et lokalt organisationssystem (fx APOS) samt et lokalt IdM-system: KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 9/21 Identity Provider komponenten udstiller / leverer udadtil en SAML 2.0 snitflade mod rammearkitekturen, og afskærmer derved den lokale implementering fra denne. IdP’en kan typisk leveres af en ”access management” komponent fra en ”IdM-suite” (fx NetIQ Access Manager) eller som en udvidelse af en directory løsning (fx Microsoft Active Directory Federation Services). Den kommunale Identity Provider har kun én integration til rammearkitekturen, nemlig til ContextHandleren, som indpakker de bagvedliggende brugervendte systemer. Identity Provideren kalder indadtil (via interne integrationer) de øvrige komponenter hos kommunen med henblik på at kunne autentificere brugerne samt udstede tokens indeholdende jobfunktionsroller: IdP’en kalder en Domain Controller for autentifikation af brugerne. Derved oplever brugeren single sign-on i forhold til det lokale domæne – og skal derfor ikke foretage sig noget aktivt for at logge på IdP’en, hvis vedkommende allerede er logget på domænet. Typisk kan dette ske med Kerberos protokollen. IdP’en henter attributter om brugeren i det lokale LDAP brugerkatalog. Det kan fx være brugerens navn, unikke ID etc. men også jobfunktionsroller, hvis disse gemmes i brugerkataloget (fx som grupper der mappes til udgående roller). IdP’en henter attributter om brugeren i det lokale organisationssystem (fx APOS). Disse attributter kan fx være organisatorisk tilhørsforhold eller tildelte jobfunktionsroller, hvis disse gemmes her. På baggrund af brugerautentifikationen og de hentede attributter, kan IdP’en nu udstede et SAML token til Context Handleren med brugerens attributter. Under KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 10/21 tokenudstedelse kan der være behov for at transformere de hentede attributter til nye værdier i det udgående token, hvilket mange IdP’er håndterer via mulighed for at definere transformationsregler. Et typisk eksempel kunne være dannelse af et Unikt ID af attributterne, opsætning af parametre til dynamiske dataafgrænsninger ud fra organisationsinfo etc. På ”bagsiden” af brugerkatalog og organisationssystem kan et lokalt IdM system oprette og nedlægge brugerne, ændre rolletildelinger etc. baseret på workflows, regler, organisatorisk placering og andre data (eksempelvis fra et HR system). Det er naturligvis helt frivilligt for myndigheder at benytte et IdM system, og ved en arkitektur som den viste, er der ingen direkte integrationer mellem IdP og IdM systemerne. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 11/21 8.1.1 Odense Kommune’s IdP-løsning Odense Kommune har etableret en IdP-løsning baseret på AD og AD FS produkterne fra Microsoft samt Identify produktet fra SafeWhere. Dette er således et eksempel på det beskrevne mønster ”1”. Løsningen er etableret på baggrund af en række ønsker og forretningsbehov: Mange tusinde medarbejdere har ikke en AD konto men har brug for adgang til intranetapplikationer hjemmefra. Flere og flere applikationer står uden for kommunens perimeter (fx i skyen) Ønske om en agil og fleksibel infrastruktur til understøttelse af brugeradgange Ønske om forbedret sikkerhed i legacy-løsninger (fx eliminering af fællesbrugere) Ønske om understøttelse af NemID via NemLog-in. Komponenterne i løsningen er: APOS, IDM, AD, ADFS og IdP 8.1.1.1 Odense kommune nuværende setup Illustreret i tegning 1. 1) Nuværende APOS1 til oprettelse/ændring af organisatoriske enheder og medarbejdere 2) Data fra APOS1 med nye medarbejdere går til IDM system a. IDM systemet giver brugeren et brugernavn(initialer til windows login) i. Brugernavn(initialer) skrives tilbage til APOS1 b. IDM opretter AD konto, hjemme drev og lægger brugeren i de rigtige organisatoriske grupper i. De organisatoriske grupper oprettes i dag manuelt i AD ved siden af 3) Stamdata på brugeren(telefon nr., stillingebetegnelser m.m.) skrives fra IDM system til AD kontoen for brugeren 4) IdP’en autentificerer brugeren via ADFS op imod AD’et, og henter de nødvendige attributter for brugeren (medarbejderen). KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 12/21 8.1.1.2 Tanker om Odense kommunes planer fremadrettet og for understøttelse af støttesystemerne Illustreret i tegning 2. Som det fremgår af Tegning 1 ovenfor, så er mulighederne for at hente attributter til SAML2 tokenet begrænset til de oplysninger, som findes i AD’et, hvilket forudsætter, at de nødvendige attributter er tilstede i AD’et. Der vil helt sikkert i forhold til autentifikationen være behov for tilgang til AD’et, men i forhold til autorisationen dvs. hvilke jobfunktionsroller, den enkelte bruger mappes til, og dermed hvad brugeren via Context Handleren får adgang til det pågældende system, ser vi et behov for at kunne hente oplysninger/attributter fra andre systemer/databaser. Hvilke systemer/databaser, der er behov for at hente attributter fra, er endnu ikke helt afklaret, men APOS2 vil være et centralt element, specielt også i forhold til dynamisk dataafgrænsning i forhold til fx hvilken afdeling, som man sidder i, så der gives adgang (autorisation) til et bestemt område/funktionalitet i fagsystemet. Ligeledes kan en opmærkning og mapning af KLE numre tænkes at ligge i APOS2. OBS: Nedenstående Tegning 2 er blot de indledende tanker, idet der er flere muligheder i forhold til hvilke attributter, som skal komme fra hvilke systemer. Ligeledes skal det bemærkes, at der i Tegning 2 ikke er beskrevet hvorledes at et evt. IDM system skal indgå. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 13/21 8.1.1.3 Odense kommune og potentialet i en IdP løsning for medarbejdere OBS: afsnittet skal udvides og er ikke helt færdig skrevet endnu. Illustreret i tegning 3 Ved etableringen af vores IdP løsning var en af de centrale gevinster, at vi fik mulighed for at give alle medarbejdere i Odense kommune adgang til Intranettet, også selvom de ikke havde en AD konto, idet at de jo ville kunne logge på med NemID. Alternativet var på daværende tidspunkt, at de ca. 10.000 ikke-AD brugere, som skulle have adgang til vores Intranet, skulle oprettes i AD’et, og vi dermed ville få en ekstra omkostning til dette. IdP løsningen giver dermed mulighed for flere forskellige login metoder så potentielt alle medarbejdere vil have mulighed for at logge på. En IdP løsning giver mulighed for tilkobling af flere forskellige autoritative databaser med brugeroplysninger, som kan sendes med i en SAML token, hvor netop en specifik autoritativ oplysning er nødvendig. IdP’en kan orkestrere denne brugerinformation. Da IdP løsningen vil kunne anvendes ikke kun til støttesystemløsningerne med til alle andre både nye og eksisterende systemer/løsninger i den enkelte kommune, så vil IdP KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 14/21 løsningen blive en meget forretningskritisk infrastruktur komponent. Derfor at det vigtigt, at gøre sin ledelse opmærksom på dette og sikre, at der er ledelsesmæssig opbakning til dels at etablere et driftsstabilt setup (redundant løsning og load balancer) som vedligeholdes og opgraderes løbende, men ligeledes etablering af en økonomisk model for sikring af finansiering af den løbende vedligehold/opgradering af løsningen og en tilslutningspris for systemer, som skal tilkobles IdP’en. 8.1.1.4 Odense kommune og potentialet i en IdP løsning for borgere OBS: afsnittet skal udvides og er ikke helt færdig skrevet endnu. Etableringen af en IdP giver ikke kun muligheder for at opnå Single Sign On(SSO) og flere forskellige loginmetoder for medarbejdere, men vil også kunne anvendes til at tilbyde dette for borgere. Både medarbejder- og borgerdelen kan i princippet håndteres af en IdP løsning, men der kan være forskellige krav til oppetider og login metoder, hvilket kan betyde, at der skal etableres flere IdP miljøer, et IdP miljø til medarbejdere og et IdP miljø til borgere. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 15/21 8.2 Mønster 2: Microsoft AD og AD FS alene Microsoft Active Directory Federation Services (AD FS) kan være et godt match for de kommuner, som har brugerne oprettet i et Active Directory, som ønsker at tildele jobfunktionsroller via AD, og som ikke har planer om overgang til en Identity Management løsning. Dermed kan man naturligt udbygge infrastrukturen ved at koble AD FS oven på det eksisterende AD. AD FS komponenten medfølger som en del af Windows Server og kræver derfor ikke yderligere licensanskaffelser. Dog kan der i visse konfigurationer blive behov for licenser til databaseservere (se diskussion nedenfor). En AD FS-baseret Identity Provider kan autentificere en AD bruger med en browser via SPNEGO protokollen. I Microsofts implementering kaldes dette også for ”Integrated Windows Authentication”, og herved slipper brugeren for at indtaste sit AD brugernavn og kodeord ved log-in til IdP’en gennem sin browser (forudsat brugeren i forvejen er logget på domænet). KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 16/21 8.3 Tekniske overvejelser om AD FS Danmarks Miljøportal har udgivet en pakke til kommuner, som på udmærket vis guider opsætning af en AD FS server. Pakken findes på adressen https://faq.miljoeportal.dk/viewtopic.php?f=29&t=18 og det relevante dokument hedder ”Introduktion til automatisk login mod Danmarks Miljøportal”. Det skal dog bemærkes, at sigtet for nærværende dokument ikke er integration til DMP - men integration til den fælleskommunale rammearkitektur (specifikt ContextHandler komponenten). Herunder gennemgås en række væsentlige forhold, man bør overveje i en AD FS løsning: Man skal beslutte sig for versionen af AD FS; den mest udbredte version er 2, men der kommet en version 3 af produktet, som på en række punkter er anderledes end version 2. Nedenstående beskrivelse tager afsæt i version 2. AD FS 2.0 kan installeres på Windows Server 2008 og senere versioner af Windows Server. Den er kompatibel med SQL Server 2005 og SQL Server 2008. AD FS kan afvikles enten på virtuelle eller dedikerede servere. Det anbefales i udgangspunktet, at AD FS 2.0 placeres på dedikerede servere af sikkerhedsog stabilitetshensyn. Rent driftsmæssigt og kompetencemæssigt kan AD FS 2.0-serveren sidestilles som en webserver med store krav til sikkerheden og oppetiden. Det skal afklares, om der er behov for dublerede servere eller blot en enkelt server. Igen vil anbefalingen være, at der opereres med dublerede servere ud fra hensyn til driftstabilitet. Hvis der skal være adgang til IdP’en fra internettet, skal der installeres en AD FS proxy i DMZ mens de egentlige AD FS servere placeres på det interne net (bagved DMZ). IdP'en skal kunne kommunikere direkte med mindst en AD Domain Controller fra det domæne, som IdP-serveren er indmeldt i. Der skal foretages valg af den underliggende database, som enten kan være WID (Windows Integrated Database) eller Microsoft SQL Server – Microsofts databaseserver, som findes i et større antal varianter. WID kan generelt ikke anbefales til dubleret, driftskritisk infrastruktur. Der skal opsættes en mapning mellem objekter i AD og jobfunktionsroller, som indlejres i tokens. Som eksempel kan man oprette en sikkerhedsgruppe per jobfunktionsrolle og i AD FS opsætte regler, der mapper brugerens grupper i AD til de navne på jobfunktionsroller (URI’er), som anvendes udadtil. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 17/21 9. Skabelon til beskrivelse af kommuneløsninger Dette afsnit indeholder en skabelon, som kommuner kan udfylde med beskrivelse af deres IdP-løsninger, således at andre kan få viden om løsning og erfaringer. 1. Info om kommunen og kontaktperson 2. Valgt løsning (produkt / teknologi) 3. Overordnet beskrivelse af løsning Fordele Ulemper 4. Erfaringer som kan videregives Tekniske, driftsmæssige, implementeringstid / indsats, økonomi 5. Arkitekturtegning 6. Teknisk beskrivelse Netværk Dublering / clustering Fremtidig videreudvikling Sikkerhedsovervejelser KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 18/21 10. Appendiks A: Overvejelser i forhold til NIST 800-63 standarden Den meget anvendte NIST 800-63 standard [NIST] definerer en række retningslinjer for autentifikation til myndighedstjenester over åbne net (”remote authentication of users ... interacting with government IT systems over open networks”). Standarden opstiller fire niveau’er af sikkerhed for brugerens identitet med tilhørende krav til hvert niveau (både tekniske og organisatoriske) og er endvidere grundlaget for arbejdet for autenticitetssikring i fællesoffentlig brugerstyring [OIO-A-LEVEL]. I relation til den fælleskommunale rammearkitektur vurderes det, at NIST standarden er relevant for de autentifikationer, der foregår over det åbne internet (markeret med sorte pile på figuren). Her anvender rammearkitekturen som tidligere beskrevet digitale signaturer og SAML Assertions, der fint kan honorere standardens tekniske krav til autentifikationsmekanismer på niveau 3. Det er relevant at bemærke, at NIST’s krav til autentifikation på niveau 3 ikke tillader brugernavn / koderord som autentifikationsmekanisme, idet denne vurderes at medføre en række risici ved autentifikation over åbne net, hvor angrebsfladen er stor og det omgivende miljø ikke kan kontrolleres (alle har i princippet mulighed for at forsøge at tilgå servicen). Bemærk at NIST-standarden ikke udtaler sig om interne autentifikationer, hvor der som tidligere nævnt kan etableres en række supplerende kontroller. På baggrund af ovenstående overvejelser, er det KOMBIT’s klare vurdering, at det er muligt at opnå autentifikation til brugervendte applikationer via rammearkitekturen, som opfylder kravene på NIST niveau 3 via digital signatur og SAML, som er udstedt på baggrund af en lokal autentifikation på myndighedens interne domæne med brugernavn og kodeord. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 19/21 11. Appendiks B: Overvejelser om persondataloven Persondataloven og sikkerhedsbekendtgørelsen stiller en række krav til behandling af personoplysninger (herunder adgangsstyring). Som eksempler kan nævnes sikkerhedsbekendtgørelsens krav til kontrol med afviste adgangsforsøg (§18) og logning (§19), der er særligt relevante for emnet i dette notat. Den samlede løsning (myndighedens lokale systemer og den fælleskommunale rammearkitektur) skal i sagens natur kunne leve op til lovgivningens krav. Det har været KOMBIT’s forudsætning ved design af den fødererede model, at sikkerheden for brugerens identitet er på samme niveau, som hvis brugeren havde anvendt lokalt log-in til en applikation, der stod direkte på Myndighedens interne domæne. Den føderede model betyder naturligvis, at forhold vedr. logning etc. skal gribes anderledes an, men selve autenticitetssikringen vurderes at være analog til traditionelt log-in til interne applikationer. Det vurderes samtidig, at lokal adgang baseret på autentifikation med brugernavn og kodeord som autentifikationsmekanisme er foreneligt med persondatalovens krav, når de specifikke forholdsregler i sikkerhedsbekendtgørelsen overholdes (eksempelvis logning samt kontrol med afviste adgangsforsøg). Der er således en lang række fortilfælde for, at myndighedsbrugere på deres interne domæne kan tilgå applikationer med personfølsomme oplysninger på baggrund af autentifikation med brugernavn og kodeord. Dermed medfører den fødererede model ikke i sig selv, at myndigheder har behov for at ændre på deres lokale autentifikationsmekanisme (forudsat den i forvejen lever op til persondataloven). Typisk vil den lokale autentifikation på det interne domæne være omgivet af en række supplerende kontroller som fx: Brugeren skal fysisk sidde på myndighedens interne netværk / befinde sig på myndighedens lokation. Brugeren skal anvende udstyr, der udleveres af myndigheden, og er under dennes kontrol. Myndigheden har konfigureret udstyret med passende beskyttelsesforanstaltninger som firewall, antivirus etc. og holder platformen opdateret med løbende sikkerhedsopdateringer. Brugerens konto på domænet spærres ved et antal på hinanden følgende antal forkerte adgangsforsøg. Brugerens kodeord er underlagt en lokal politik, der sikrer kvaliteten af kodeord. Brugerne er oplyst om organisationens sikkerhedspolitik og har fået udleveret en sikkerhedshåndbog etc. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 20/21 12. Referencer [NIST] ”Electronic Authentication Guideline”, NIST special publication 800-63-1. http://csrc.nist.gov/publications/nistpubs/800-63-1/SP800-63-1.pdf [OIO-A-LEVEL] Vejledning vedrørende niveauer af autenticitetssikring, http://digitaliser.dk/resource/363424, IT- og telestyrelsen, 2006. KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk kombit@kombit.dk CVR 19 43 50 75 Side 21/21
© Copyright 2024