Kravspecification IdP løsning Resume IT-Forsyningen, som varetager IT-drift for Ballerup, Egedal og Furesø Kommuner, ønsker at anskaffe en IdP/Føderationsserverløsning, der kan understøtte en række forretningsmæssige behov som de 3 kommuner står overfor. Løsningen skal kunne håndtere de 3 forskellige kommune-domæner, men vi lægger vægt på at ikke-domæneafhængige dele af løsningen kan implementeres som shared service. Løsningen skal kunne anvendes til følgende hovedformål: 1) Kunne give medarbejdere fødereret adgang til cloud-services og webbaserede fag- og administrationssystemer, der er hosted af leverandørerne ved brug af SAML 2.0 eller OAUTH2 standarderne. Der skal kunne fødereres konti, som medarbejderne anvender til dagligt fx windows konti, Uni*login m.fl. Der skal kunne etableres SSO. 2) Medarbejdere der ikke er oprettet som IT-brugere, skal kunne tilgå fx intranet. Løsningen skal derfor kunne indeholde brugerkatalog over denne medarbejdergruppe, samt evt. borgere, virksomheder og samarbejdspartnere, der skal indgå i digitale samarbejder med kommunen. NemID skal her kunne anvendes til sikring af retsgyldighed af identitet. 3) Løsningen skal kunne anvendes som Access Manager. Dvs. at man via løsningen skal kunne stille login til rådighed udefra til interne ressourcer på Kommunens LAN. Man skal kunne differentiere i sikkerhedsniveau og loginmetode både ift. hvem den påloggende bruger er, men også ift. hvilken intern ressource der tilgås. 4) I forbindelse med KOMBIT monopolbrud og ibrugtagning af den Fælleskommunale Rammearkitektur skal løsningen kunne anvendes til at logge på Kombits systemer. Løsningen skal kunne indsamle data fra forskellige kilder i forbindelse med token-dannelse. Fx AD, IDM-system, Organisations- og Klassifikationssystem. 5) I takt med modernisering af IT-systemer, hvor tendensen er at brugeradministration bliver fjernet fra systemerne til fordel for en fødereret, SAML-baseret adgang, skal løsningen også kunne være ID provider ift. til disse såvel interne som eksterne systemer. 6) Løsningen skal kunne logge på et detaljeret niveau hvem der har logget på, hvorfra og hvornår. Konti skal kunne låses automatisk ift. opstillede regler. Personhenførbare data må ikke gemmes i de dele af løsningen, der er tilgængelig fra WAN.
Indhold 1. Forretningsmæssige behov 1) Adgang fra WAN til interne ressourcer for kommunens IT-brugere 2) Adgang fra WAN til interne ressourcer for medarbejdere der ikke er registreret i AD 3) Adgang for samarbejdspartnere og leverandører fra WAN til interne ressourcer 4) Adgang for borgere og virksomheder til selvbetjeningsservices via NemID 5) Fødereret adgang for kommunens medarbejdere til webbaserede systemer og tjenester, der er SAML2, OAUTH2 eller OIO-SAML kompliante 6) Anvendelse af forskellige sikkerhedsniveauer i login 2. Krav til IT-miljø 1) Løsningens placering og omfang 2) Tekniske krav og skalerbarhed 3) Security Token Service 3. Krav til brugergrænseflade og administration 1) Roller og konfiguration 2) Afrapportering 4. Krav til sikkerhed og logning 1) Logning 2) Personhenførbare data 3) Sikkerhedsregler 4) Reset af password 5. Ønske om stordriftsfordele 1) Fælles ressourcer og domænespecifikke ressourcer 6. Løsningens implementering og udvikling 1) Løsningens modulære struktur 2) Løsningens håndtering af interne ressourcer (arkitektur) 3) Inkludering af nuværende ADFS løsninger 4) Initial implementering af moduler 5) Fremadrettet udvikling af løsningen 7. Priser 1) Licenser pr. bruger 2) Basis implementering 3) Årlig licens udgift 4) Supportaftaler 5) Pris pr. yderligere logonprovidere
Kravspecifikation detaljer Krav Beskrivelse nr. 1 Forretningsmæssige behov 1.1 Adgang fra WAN til interne ressourcer for kommunens IT-brugere. Det skal være muligt i løsningen at give kommunens IT-brugere adgang til interne ressourcer fx Citrix, Intranet, Alfresco, Outlook OWA hvor de anvender deres windows netværkslogin. 1.2 Adgang fra WAN til interne ressourcer for medarbejdere der ikke er registreret i AD. Kommunerne har et stort antal medarbejdere, der ikke er oprettet som ITbrugere (windows login). Disse medarbejdere skal kunne tilgå interne ressourcer fx Intranet med andre login metoder. NemID, Uni*login eller NemID første gang, hvor der oprettes en konto på løsningen. 1.3 Adgang for samarbejdspartnere og leverandører fra WAN til interne ressourcer. Det skal være muligt for inviterede samarbejdspartnere og leverandører at logge ind via løsningen for adgang til interne ressourcer fx Alfresco (Projektværktøj). P.t. kan leverandører gives adgang til servere og andet som de skal vedligeholde vha. VPN opkobling. I bedes beskrive hvorledes løsningens access manager vil kunne overtage denne funktion. Login vil kunne være NemID eller windows konto, som har adgang til servere mm. 1.4 Adgang for borgere og virksomheder til selvbetjeningsservices via NemID. Borgere og virksomheder, der skal anvende vore selvbetjeningsløsninger, der er sat op på hjemmesiden, skal anvende NemID i disse løsninger. Vi forestiller os at en IdP vil kunnne fungere som NemID-broker, der gør, at vi kan redirigere NemLogin til IdP en, som så identificerer anvenderen og evt. trækker diverse data fra CPR registret og returnere disse data til selvbetjeningsløsningen. Desuden vil vi gerne kunne anvende NemID modulet i løsningen til digital underskrift i selvbetjeningsløsninger. 1.5 Fødereret adgang for kommunens medarbejdere til webbaserede systemer og tjenester, der er SAML2, OAUTH2 eller OIO-SAML kompliante. Løsningen skal kunne indsamle data fra forskellige brugerkataloger internt fx AD, IDM, APOS2 som samles i den token der skal anvendes til fødereret login til diverse eksterne webbaserede systemer og tjenester. Specielt skal den kommende adgang til KOMBIT monopolbrudssystemer og støttesystemer kunne håndteres. Såvel system til system adgang som bruger til system adgang skal kunne håndteres. 1.6 Anvendelse af forskellige sikkerhedsniveauer i login. I forbindelse med opsætning af login til forskellige brugergrupper, skal det være muligt at differentiere på sikkerhedsniveauet både ift. de forskellige brugergrupper, men også ift. de ressourcer der stilles til rådighed. Umiddelbart forestiller vi os disse niveauer: 1. NemID 2. Windows login/uni*login med 2 faktor funktion. fx SMS
3. Windows login/uni*login 4. IdP bruger med 2 faktor funktion fx SMS 5. IdP bruger login I bedes angive i hvor høj grad løsningen vil kunne tilbyde disse. 2 Krav til IT-miljø 2.1 Løsningens placering og omfang. I bedes angive løsningens arkitektur, antal servere, servertyper og platforme, samt placering (internt DMZ) Desuden angive om løsningen kan driftes lokalt og/eller i skyen 2.2 Tekniske krav og skalerbarhed. I bedes skitsere hvorledes løsningen kan skaleres, samt hvilke afhængigheder der kan være til andre infrastrukturkomponenter fx AD, ADFS, MS WAP m.fl. 2.3 Security Token Service. Løsningen skal kunne anvendes generelt til interne systemer, der skal interagere med eksterne systemer fx KOMBIT støttesystemer. 3 Krav til brugergrænseflade og administration 3.1 Roller og konfiguration. I bedes skitsere hvorledes vi selv kan administrere systemet gerne vi GUI. Hvad vil være muligt at styre selv, og hvad vil kræve leverandør adgang fx mht. publicering af nye interne ressourcer. Hvilke roller er der i adgangen til systemet. 3.2 Afrapportering. I bedes beskrive hvorledes man fra løsningen kan trække information som systemet har logget. Også evt. lister over oprettede brugere og deres adgangssikkerhedsniveau o.l. 4 Krav til sikkerhed og logning 4.1 Logning. Løsningen skal kunne registrere følgende om de der logger på: a. Hvem logger på b. Pålogningsmetode c. Tidspunkter for login og logout d. IP nr., hvorfra pålogning sker e. Hvordan kan logs monitoreres I bedes beskrive om dette opfyldes i løsninger og gerne hvis der kan logges yderligere. 4.2 Personhenførbare data. Må ikke gemmes i løsningen såfremt denne er tilgængelig fra Internettet. Hvis sådanne data skal gemmes skal det foregå på en intern databaseserver e.l. I bedes beskrive hvordan I håndterer denne problematik. 4.3 Sikkerhedsregler. Det vil være ønskeligt hvis løsningen kan konfigureres med forskellige former for sikkerhedsregler: fx - Midlertidig lukning af konto hvis pålogning forsøges fra ind og udland med samme konto. - Antal af mulige loginforsøg med samme konto - Kun én logon instans pr. konto
4.4 Reset password Vi ønsker at løsningen kan stille servicen Reset password til rådighed for såvel vore AD-brugere, som de brugere der oprettes i løsningens eget brugerkatalog. I bedes angive om dette er muligt. 5 Ønske om stordriftsfordele 5.1 Fælles ressourcer og domænespecifikke ressource. Da løsningen implementeres i IT-forsyningen, som betjener 3 kommuner, vil det være ønskeligt om der kan opnås stordriftsfordele. Dele af løsningen kunne således være fælles for de 3 kommuner, og andre dele kunne være domænespecifikke. I bedes belyse hvorledes i kunne etablere jeres løsning i dette lys. 6 Løsningens implementering og udvikling 6.1 Løsningens modulære struktur. Vi ønsker at løsningen kan bestå af moduler, således at vi kan starte med at dække vore nuværende forretningsbehov, for så siden at kunne tilføje ny funktionalitet i form af nye moduler der tilknyttes løsningen. Beskriv hvorledes jeres løsning tilfredsstiller denne strategi. 6.2 Løsningens håndtering af interne ressourcer (arkitektur). Vi ønsker at kunne bevare vores nuværende interne placering af ressourcer, som skal stilles til rådighed gennem access manageren. Løsningen skal derfor rumme eller kunne anvende en proxy anordning, der kan viderestille til de interne ressourcer. 6.3 Inkludering af nuværende ADFS løsninger. Vi har i dag allerede 6-7 kørende fødererede SSO løsninger kørende i Microsoft ADFS, hvor medarbejderne kan logge på webbaserede fag- eller administrationssystemer i skyen. Disse løsninger skal inkluderes i den kommende IdP løsning, således at vi ikke får behov for at køre med flere separate IdP løsninger. Hvis løsningen ikke inkluderer ADFS som et hele, skal den kunne føderere claims fra AD på tilsvarende vis. Beskriv hvordan i kan løse denne problematik. 6.4 Initiel implementering af moduler. Som anført ovenfor ønsker vi at starte på et niveau, hvor vi kan få dækket vore umiddelbare forretningsmæssige behov. Derfor har vi i tankerne at løsningen fra starten skal kunne: a. Videreføre de nuværende ADFS løsninger b. Anvende NemID som logonmetode c. Anvende Uni*login som logonmetode d. Anvende Windows domæne login e. Brugere, der kun har NemID skal kunne oprettes med nyt brugernavn og kode i løsningen. f. Der skal kunne knyttes 2-faktor login fx i form af SMS kode til alle disse login metoder g. Løsningen skal kunne hente data / claims fra såvel AD som andre kilder fx IDM, der udstiller roller og identer via webservice h. Brugere, der enten har en windows netværks konto eller en konto i løsningens eget brugerkatalog skal kunne resette deres password via en 2-faktor login metode. I bedes beskrive i hvor høj grad jeres løsning vil kunne honorere disse
punkter. 6.5 Fremadrettet udvikling af løsningen. Når og hvis det bliver aktuelt, skal løsningen kunne tilføjes nye forbindelser til systemer i skyen, som anvender fødereret adgang. Der skal kunne tilføjes nye login providere hvis det bliver aktuelt fx WAYF, Facebook, Google e.l. Beskriv i hvilket omfang dette vil kunne lade sig gøre. 7 Priser 7.1 Licenser pr. bruger. Her bedes beskrevet hvordan licens politikken er for løsningen. I de 3 kommuner tilsammen er der ca. 14.000 medarbejdere. 7.2 Basis implementering. I bedes angive priser på såvel basis system som de enkelte moduler løsningen består af (som anført under pkt. 6.4.). Desuden pris på konsulenthonorar for den initiale implementering og konfiguration af de ønskede moduler. 7.3 Årlig licens udgift. Foruden den initiale implementering vil der måske være en årlig licensbetaling, som I bedes angive her. 7.4 Supportaftaler og timepris. I bedes angive priser på supportaftaler på de forskellige niveauer af support i tilbyder. Desuden bedes angivet timepris på udvikling af nye funktioner eller moduler, samt timepris på support, hvis man ingen supportaftale har. 7.5 Pris pr.o yderligere logonprovidere. Hvis vi ønsker at etablere nye login metoder bedes I her angive priser for etablering af yderligere logonprovidere. Desuden bedes, angivet i runde tal, prisen på etablering af en fødereret adgang til et nyt cloudbaseret fag- eller administrationssystem.