1. No category

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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] CVR 19 43 50 75
Side 21/21