1. No category

Lokal implementering af
Identity Provider
En vejledning til kommunernes og ATP’s opgaver
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 0/23
Indhold
1.
2.
3.
4.
5.
6.
7.
Baggrund ................................................................................................................... 2
Hvad er en Identity Provider? .................................................................................... 2
Hvorfor en IdP? ......................................................................................................... 3
Hvordan ser en IdP ud? ............................................................................................ 3
Produkter som kan udstille en SAML 2.0 Identity Provider ....................................... 4
Krav og anbefalinger til Identity Provider .................................................................. 4
Implementeringsovervejelser .................................................................................... 6
7.1
Overvejelser relateret til etablering af Identity Provider ..................................... 6
8. Implementeringsmønstre........................................................................................... 7
9. Appendiks A: Overvejelser i forhold til NIST 800-63 standarden ............................ 20
10. Appendiks B: Overvejelser om persondataloven .................................................... 21
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 1/23
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 2/23
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
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
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 3/23
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.
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.
1
Fx SimpleSAML PHP
https://sharekomm.kombit.dk/P024/Delte%20dokumenter/Bilag%202.%20Sikkerhed%20version%201.3%2018.%20marts%202014.pdf
2
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 4/23


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:
 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
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 5/23





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.
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.
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.
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 6/23




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.
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.
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:
4
Denne er udgivet som bilag på 2 under integrationsvilkår på https://sharekomm.kombit.dk/P024/Delte%20dokumenter/Forms/Vejledninger%20og%20vilkaar.aspx
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 7/23
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
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
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 8/23
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 9/23
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
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).
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 10/23
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(MO) 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 MO.
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 11/23
Odense kommune og potentialet i en IdP løsning for medarbejdere (Tegning 3):
OBS: 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.
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.
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 driftstabilt setup(redundant løsning og load balancer) som
vedeligeholdes og opgraderes løbenden, men ligeledes etablering af en økonomisk
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 12/23
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.
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.
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 13/23
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 14/23
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øb, 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 itlandskab, 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 Nemlogin
Hvilke typer enheder understøtter Identity Provideren? Jeg forstår ikke helt spørgsmålet
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 f.t. støttesystemerne, så kommer den til at spille en kritisk
rolle if.t. 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.
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 15/23
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 vhja. NemLogin
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.
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 16/23
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”, NemLogin, 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.
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 17/23
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 først ADFS 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 itlandskab, 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å reundans 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.
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 18/23
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)
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
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 19/23
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
9. 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.
KOMBIT A/S Halfdansgade 8 2300 København S Tlf 3334 9400 www.kombit.dk [email protected] CVR 19 43 50 75
Side 20/23
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.
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 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 21/23
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 22/23