Portalintegrationsprojektet Føderationstilslutning ERFA møde 9. januar 2008

Agenda •Lidt om føderationer •Tilslutningsprocessen •Oversættelse af brugeridentiteter •Key Management •Logning

Om føderationer •En føderation er et forbund af selvstændige organisationer, der anvender et fælles sæt af aftaler, standarder og teknologier til overførsel af brugeres identitet og rettigheder på tværs af organisationer. •Tilslutning til den fællesoffentlige føderation er en forudsætning for, at services kan leveres på borgerportalen. •Stiller krav til serviceudbydere om at understøtte OIO-SAML profilen samt føderationens politikker.

Hvilken funktionalitet tilbydes?! Identity Provider Logintjeneste AutorisationApplikation Bruger Serviceudbyder Føderation Attributservice

”Guide til Føderationstilslutning” •Formålet med guiden er at: –Skabe overblik og klarhed for serviceudbydere –Udgøre et værktøj for planlægning af arbejdet –Gøre forløbet så effektivt som muligt –Beskrive de væsentligste udfordringer –Være et opsamlingssted for erfaringer med tilslutning •Guiden er teknologineutral

Indhold af guide •Overblik over tilslutningsprocessen •Beskrivelse af vigtigste opgaver og aktiviteter •Fordeling af roller og ansvar •Vigtige tekniske valg •Tekniske problemstillinger, tips •Beskriver ikke –Portalintegration –SAML produktspecifikke overvejelser –Indhold af integrationstest

Gennemgang af aktiviteter (1) •Foranalyse –Muligheder og konsekvenser ved tilslutning –Business cases –Politiske og organisatoriske forhold –Valg af applikationer / services, der skal tilsluttes. •Kun web applikationer til Internettet •Applikationer som skal på borger.dk er et must, hvis de skal kende brugeren •Evt. udfasning af eksisterende loginløsninger •Største gevinst for applikationer med mange brugere

Gennemgang af aktiviteter (2) •Indgå tilslutningsaftale med BSS –Fastlægger rammer, ansvar og pligter •Etablering af organisation –Projektorganisation –Driftsorganisation og procedurer •Risikovurdering –Fastlæg nødvendigt niveau af autentitetssikring for hver applikation / service –Organisationer underlagt DS-484 skal iøvrigt foretage en konsekvens- og risikovurdering

Gennemgang af aktiviteter (3) •Fastlæg driftsbehov / servicekvalitet –Applikationer –Infrastrukturkomponenter (SAML bokse) –Risikovurderingen giver input –Sammenhold med føderationens servicekvalitet og overvej evt. beredskab

Gennemgang af aktiviteter (4) •Etablér SAML 2.0 kapabilitet –Kan findes i eksisterende SW (f.eks. Identity Management suiter) –En række kommercielle produkter på markedet. Se Wiki! –Open source værktøjer •Kriterier for valg –It strategi og sikkerhedsstrategi –Eksisterende teknologiplatform –Øvrige behov/løsninger til identity management i organisationen –Produktkendskab

Gennemgang af aktiviteter (5) •Arkitektur, design og udvikling –Integration mellem SAML produkt og serviceudbyderens infrastruktur og applikationer –Behov for integration og udvikling vil variere meget fra serviceudbyder til serviceudbyde –Relevante spørgsmål: •Hvad har applikationen brug for at vide om brugeren?! Hvordan skal den have det at vide?! •Hvordan styres adgange i dag og i fremtiden?! •Hvad har infrastrukturen brug for at vide om brugeren (f.eks. specifikke eller generiske rettigheder, styrke af autentitetssikring)

Gennemgang af aktiviteter (6) •Etablering af miljøer –Opsætning af servere, netværk, infrastruktur –Brug af fælles tidsserver –Installering og konfigurering af SAML produkt –Udveksling af meta data med Identity Provider –Generering af testdata til applikationer –Testbrugere (OCES test certifikater) –Eksterne systemer (fx CPR, TDC) –Nøgler, certifikater, key management –Sikkerhed –Procedurer

Gennemgang af aktiviteter (7) •Integrationstest –Verificerer at ”opkoblingen” til Identity Provideren er udført teknisk / funktionelt korrekt –Serviceudbyder selv ansvarlig for test af •applikationsspecifik funktionalitet •ikke-funktionelle aspekter (inkl. sikkerhed) –Test cases og test data for integrationstest er beskrevet i særskilt dokument –Integrationstest mod portaler udføres efter integrationstesten

Teknik

Oversættelse af brugeridentiteter •Serviceudbyder vil modtage et SAML token, der beskriver brugerens identitet på et ”fælles” format. •Den eksterne identitet skal oversættes til den interne identitet, brugeren er kendt under hos serviceudbyderen. •Derefter skal den gøres tilgængelig for applikationer og evt. infrastruktur (fx via HTTP headere)

”Account mapping” via OCES attr. Identity Provider Logintjeneste AutorisationApplikation Bruger Serviceudbyder Attributservice CPR= PID= CN=Hans Jensen Bruger- katalog UserID CPR Navn : Hansj Hans Jensen Pto Peter Olsen Ingen eksplicit relation mellem brugerID hos SP og IdP! SAML Token

”Account linking” via pseudonymer Identity Provider Logintjeneste AutorisationApplikation Bruger Serviceudbyder Attributservice Pseudonym= xa1823 Bruger- katalog UserID Pseudonym Navn : Hansj xa1823 Hans Jensen Pto qx3234 Peter Olsen Bruger- katalog Pseudonym CPR SP : xa itst.dk qx oes.dk Eksplicit relation mellem SP og IdP! SAML Token

Key Management •Håndtering af kryptografiske nøgler er vigtigt for sikkerheden men ofte et forsømt område. •Serviceudbyderens virksomhedssignatur anvendes til at underskrive meddelelser og til at modtage krypterede meddelelser fra Identity Provideren. •Adgangen til nøglerne er kritisk at sikre. •Serviceudbydere bør etablere procedurer for sikker generering, opbevaring, brug, backup, fornyelse og genetablering af nøgler.

Logning •BSS udgiver en logningspolitik, som fortæller hvilke data, serviceudbyderne skal logge. •Formålet er: –At sikre sporbarhed af tværgående transaktioner –At sikre konsistens af logning –At relevant lovgivning opfyldes –Tilgodese efterforskningsmæssige hensyn