Lokal implementering af Identity Provider

Transkript

1 Lokal implementering af Identity Provider En vejledning til kommunernes og ATP's opgaver Version 1.1, december 2015 KOMBIT A/S Halfdansgade København S Tel kmj@kombit.dk

2 Indhold 1. Baggrund Hvad er en Identity Provider? Hvorfor en IdP? Hvordan ser en IdP ud? Produkter som kan udstille en SAML 2.0 Identity Provider Krav og anbefalinger til Identity Provider Implementeringsovervejelser Implementeringsmønstre Appendiks A: Overvejelser i forhold til NIST standarden Appendiks B: Overvejelser om persondataloven Side 2/19

3 1. Baggrund En grundlæggende 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 (login) 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. En konceptuel illustration af en IdP findes nedenstående figur: Side 3/19

4 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 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 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 Side 4/19

5 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 KOMBITs Attributprofil 2 af SAML 2.0 standarden samt OIOSAML version 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. Sikkerhedsniveauer 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 % 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: 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å 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. login 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. 2 Side 5/19

6 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 itrevision. 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. Overvejelser relateret til etablering af Identity Provider Den netværksmæssige placering af Identity Provideren skal besluttes. Kommunikationen mellem Støttesystemernes komponenter (Context Handler) 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 zone 3, 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 KOMBITs attributprofil 4. 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 login 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å Side 6/19

7 8. Implementeringsmønstre Implementeringen af en Identity Provider vil afhænge af den enkelte myndigheds it-portefø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 KOMBITs 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. 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: 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 Context Handleren, 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: Side 7/19

8 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 token udstedelse 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. Side 8/19

9 Odense Kommunes 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 Odense kommune nuværende setup (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.) skrive fra IDM system til AD kontoen for brugeren 4) IdP en autentificere brugeren via ADFS op imod AD et og henter de nødvendige attributter for brugeren(medarbejderen). Side 9/19

10 Tanker om Odense kommunes planer fremadrettet og for understøttelse af støttesystemerne (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 der er 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 at den enkelte bruger mappes til og dermed hvad brugeren via Context Handleren får adgang til det pågældende system, så 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 Medarbejder og Organisations (AMMO) kataloget vil være et centralt element, specielt også i forhold til dynamisk dataafgrænsning i forhold til fx hvilken afdeling som man sidder i og så dermed giver 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 AMMO. Bemærk: 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å. Odense kommune og potentialet i en IdP løsning for medarbejdere (Tegning 3): Bemærk: afsnittet skal udvides og er ikke helt færdig skrevet endnu. 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. Side 10/19

11 Alternativet var på daværende tidspunkt at de ca 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. 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 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 stabilt driftsetup (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 tilslutnings pris for systemer som skal tilkobles IdP en. Odense kommune og potentialet i en IdP løsning for borgere (Tegning 4): OBS: afsnittet skal udvides og er ikke helt færdig skrevet endnu. Etableringen af en IdP giver ikke 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. Side 11/19

12 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 gør at det kan tænkes at der skal etableres en IdP miljøer, et IdP miljø til medarbejdere og et IdP miljø til borgere. Side 12/19

13 Spørgeskema: Esbjerg kommunes IdP løsning 1. Hvilket Identity Provider produkt har I valgt? I Esbjerg Kommune forventer vi at implementere Safewhere Identify og AD FS 3.0 nyindkøbt, der erstatter eksisterende føderationsløsning. Vi har fravalgt vores eksisterende løsning, da vi på sigt ønsker at anvende både AD et og en lokal organisationskomponent, hvilket det nuværende setup ikke kan understøtte. I dag benytter vi eksempelvis AD et til rolleafgrænsninger, hvilket giver en stor mængde af AD grupper, som skal vedligeholdes ved organisationsændringer mv. 2. Samspil med andre komponenter - Arkitekturen [Hvordan spiller den valgte Identity Provider sammen med andre komponenter i jeres it-landskab, herunder brugerkatalog, Identity Management System, Organisationskomponent, m.m.] Den valgte Identity Provider skulle spille godt sammen med både AD et, lokal organisationskomponent osv. Vores IDM løsning forventes at opdatere AD et og den lokale organisationskomponent, med de oplysninger, som IdP en har brug for, men der er ikke en direkte integration med IdP en Hvordan autentificerer de lokale brugere til Identity Provideren? Det er muligt både med autentifikation via AD et og med NemId via NemLog-in Hvilke typer enheder understøtter Identity Provideren? Hvordan opsamler Identity Provideren information om brugerens roller og anden relevant information? Ved opslag i AD og lokal organisations komponent Hvordan tilgås Identity Provideren af brugerne? (via internt netværk, tilgængeligt fra internettet) Det er muligt både via internt netværk og tilgængelig fra internettet. Når det er via internettet, så er der 2 faktor autentifikation 3. Fremtidsperspektiv / Business Case [Forventes det at Identity Provideren skal anvendes til andet end Støttesystemerne, og I hvilket omfang har dette lagt til grund for valg af netop den løsning I har købt. Hvilket fremtidsperspektiv og business case ser I mht. anvendelse af Identity Provider i jeres organisation] Vi anvender allerede i dag den eksisterende Identity Provider i stor stil, både internt og eksternt fra. Der bliver løbende indgået nye føderationsaftaler, så det er ikke kun på grund af støttesystemerne, vi vælger som vi gør. Identity Provideren er en del af vores infrastruktur og fremadrettet i forhold til Støttesystemerne, så kommer den til at spille en kritisk rolle i relation til sagsbehandlernes adgang til KY, KSD og SAP. Vedr. fremtidsperspektivet, så forventer vi at IdP en kan hjælpe os med borgernes adgang til egne sager mv. og det kan tænkes at kommunale samarbejder bliver lettere at implementere. Side 13/19

14 Spørgeskema: Ballerup kommunes IdP løsning 1. Hvilket Identity Provider produkt har I valgt Vi er p.t. ved at forberede et udbud i samarbejde med vore it-forsyningspartnere Egedal- og Furesø kommuner. Vi mener at en føderationsløsning som SafeWhere Identity eller NetIQ i højere grad vil kunne honorere kravene fra KOMBIT rammearkitekturen, samt det faktum at flere og flere fagsystemer bliver webbaserede og hosted hos leverandørerne. Yderligere er der tegn i sol og måne på at brugeradministration fjernes fra fagsystemer og fagsystemerne i højere grad tilgås via SAML tokens. Udviklingen går fra provisionering til føderering. Yderligere vil vi også gerne kunne tilbyde vore ikke-ad oprettede ansatte adgang til fx Intranet og andre interne datakilder fx vha. NemLog-in 2. Samspil med andre komponenter Arkitekturen 3. Fremtidsperspektiv / Business Case Vi har identificeret en lang række webbaserede fagsystemer, portaler og administrative systemer som allerede nu anvender SAML teknologien og kan tilgås via IdP og SSO. Foreløbigt har vi 3 løsninger kørende på vores ADFS 3.0 setup: Silkeborg Data Løn, Schultz Fasit, Access Technology CareAccess. Yderligere 2 er under planlægning: Emply-Ofir, Miljøportalen. Vores fornemmelse er at denne udvikling vil fortsætte og formentlig på sigt helt vil erstatte lokal brugeradministration i fremtidens systemer. Denne udvikling medfører store besparelser til brugeradministration og har stor sikkerhedsmæssig betydning tillige. Desuden er disse lidt større IdP løsninger spækket med andre funktioner som Reset password, Nem- Log-in, brugerdatabase for ikke-ad ansatte, adgang udefra til en række interne services (Intranet, Citrix, OWA, Alfresco m.fl.). Vi vil også kunne håndtere Borgere og Virksomheders logon til evt. selvbetjeningsløsninger, som ikke er omfattet af borger.dk / virk.dk. Side 14/19

15 Spørgeskema: Aalborg kommunes IdP løsning 1. Hvilket Identity Provider produkt har I valgt Svar: Aalborg Kommune anvender ADFS og forventer at anvende dette produkt til STS. Anvendes til Miljøportalen og Silkeborg Data. Fordele ved ADFS er at den er nem at integrere med eksisterende AD og benytte AD attributter og sikkerhedsgrupper til at danne indhold i tokens. Det er vores erfaring, at når ADFS først er konfigureret, så kører det meget stabilt og uden problemer. Der kan være lidt udfordringer i forhold til implementering af de enkelte service providere, så der bør afsættes god tid til dette. Vi anvender primært Microsoft produkter 2. Samspil med andre komponenter - Arkitekturen [Hvordan spiller den valgte Identity Provider sammen med andre komponenter i jeres it-landskab, herunder brugerkatalog, Identity Management System, Organisationskomponent, m.m. Svar: se den vedhæftede tegning Løsningen består af to Windows Server 2012 R2 servere som er installeret i en ADFS Farm for at opnå redundans på løsningen. Foran disse to servere er konfigureret en Hardware Loadbalancer som sikrer at trafik sendes til sekundær server hvis den primære server ikke svarer. Løsningen er ikke tilgængelig udenfor kommunes infrastruktur og heller ikke i DMZ. Hvordan autentificerer de lokale brugere til Identity Provideren? Svar: Autentificering sker via AD Hvilke typer enheder understøtter Identity Provideren? Svar: Miljøportalen, Office 365 Hvordan opsamler Identity Provideren information om brugerens roller og anden relevant information? Hvordan tilgås Identity Provideren af brugerne? (via internt netværk, tilgængeligt fra internettet) Side 15/19

16 Svar: Vores IdP kan kun tilgås på kommunens netværk. 3. Fremtidsperspektiv / Business Case [Forventes det at Identity Provideren skal anvendes til andet end Støttesystemerne, og I hvilket omfang har dette lagt til grund for valg af netop den løsning I har købt. Hvilket fremtidsperspektiv og business case ser I mht. anvendelse af Identity Provider i jeres organisation] Svar: Vi forventer at IdP skal anvendes til stadig flere systemer. Valget af denne IdP er baseret på leverandøren, idet Aalborg Kommune fortrinsvis anvender Microsoft produkter Side 16/19

17 Skabelon til beskrivelse af kommuneløsninger Dette afsnit indeholder en skabelon, som kommuner kan udfylde med beskrivelse af deres IdPlø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 Side 17/19

18 9. Appendiks A: Overvejelser i forhold til NIST standarden Den meget anvendte NIST 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 niveauer 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 KOMBITs 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. Side 18/19

19 10. 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 KOMBITs 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 login 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. Referencer [NIST] Electronic Authentication Guideline, NIST special publication [OIO-A-LEVEL] Vejledning vedrørende niveauer af autenticitetssikring, IT- og telestyrelsen, Side 19/19