Sammenhængende log-in - SSO til applikationer i et andet sikkerhedsdomæne

Transkript

1 > Sammenhængende log-in - SSO til applikationer i et andet sikkerhedsdomæne IT- & Telestyrelsen, Kontor It-infrastruktur og Implementering februar 2010

2 Indhold > 1 Introduktion Føderationsfordele 4 2 Arkitekturkomponenter 6 3 Grundlæggende scenarie 8 4 Overvejelser Oprette tillidsforhold Metadata udveksling Repræsentation af adgangsrettigheder Identity Provider discovery-funktion 11 5 Identity Provider integration Autentifikation af bruger Opbevarelse af information om adgangsrettigheder Overvejelser ved oprettelse af netværk 15 6 Service Provider integration Adgangskontrol Integration med lokale adgangskontrolsystemer Overvejelser ved oprettelse af netværk 18 Appendix A: References 19

3 Dokument Historie Version Dato Initialer Ændringer TG Dokument oprettet

4 1 Introduktion > Denne guide beskriver hvordan to organisationer kan indgå i en føderation vha. den danske OIOSAML-profil af OASIS SAML-standarden 1. Fokus vil være på den offentlige sektor, men teknikkerne kan også bruges i andre sektorer. Den grundlæggende ide bag konceptet sammenhængende login er at ansatte i organisation (A) kan tilgå (web-)applikationer stillet til rådighed af organisation (B) i et andet sikkerhedsdomæne sømløst og sikkert uden at skulle logge på eller anskaffe en ny brugerkonto hos (B). OIOSAML løser dette problem ved at levere arkitekturkomponenter og protokoller. Denne guide beskriver hvordan offentlige organisationer kan oprette føderationer i praksis samt integrere med en eksisterende infrastruktur såsom LDAP register. Figur 1: Føderationskonceptet Bemærk at OIOSAML også bruges i andre føderationsscenarier hvor en central tredjepart er ansvarlig for at autentificere brugere (f.eks NemLog-in løsninger). Scenariet bruges ofte for borgerrettede applikationer, hvor brugeren ikke tilhører en reel organisation, som kan stå inde for vedkommendes identitet. Disse scenarier er ikke en del af denne guide, som udelukkende fokuserer på identity providers i lokale organisationer. 1.1 Føderationsfordele Der er mange fordele ved at bruge de føderationsmekanismer, der vil blive beskrevet i denne guide: 1 Security Assertions Markup Language se [SAMLCore] for detaljer. 4

5 > Brugeradministrationen reduceres. En organisation, der stiller en applikation (B) til rådighed, behøver ikke administrere en anden organisation(a) s brugere/ansatte samt deres rettigheder til at bruge applikationen. I stedet bliver brugere administreret i deres egen organisation, hvilket betyder en reduktion i den administrative byrde. Bedre sikkerhed. Når brugerne er administreret i deres egen organisation bliver sandsynligheden for, at deres rettigheder er korrekte væsentligt forøget, hvilket forbedrer sikkerheden. Hvis f.eks. en ansat i organisation(a) skifter stilling eller forlader organisationen, er det sandsynligt at den lokale administrator bliver kontaktet og sørger for at opdatere adgangsrettighederne. Nogle organisationer har endda udrullet identitetstyringssystemer, som sørger for at adgangsrettigheder automatisk bliver opdateret, når en ansats stamdata ændres (f.eks i en HR database). Hvis ansatte har brugerkonti hos andre organisationer, er sandsynligheden for at deres adgangsrettigheder bliver opdateret meget mindre. Mindre udgifter til integration. Integration med OIOSAML er baseret på åbne, internationale standarder, hvilket sænker udgiften til integration. Hvis offentlige organisationer fødererer med flere forskellige partnere, kan de samme integrationskomponenter genbruges. Kommercielle standardprodukter og gratis open source referenceimplementationer af OIOSAML er tilgængelige [REFIMPL]. Brugeroplevelsen bliver forbedret. Brugere undgår at blive tildelt nye brugerkonti for hver applikation, de skal bruge (f.eks. nyt bruger ID og password, som de skal huske og ændre med jævne mellemrum). Derudover opnår de single sign-on, så de ikke behøver at logge ind gentagne gange på en arbejdsdag, hvilket betyder at brugerens oplevelse og produktivitet forbedres. Portaler kan samle applikationer sømløst. Ved at opnå single-sign on til (web)applikationer er det muligt at bygge portaler, der samler og integrerer adskillige applikationer fra forskellige organisationer. Hvis applikationerne er integreret i portalen via en web-browser (f.eks. iframing eller link), er det ikke nødvendigt at modificere applikationer der bruger SSO, men er udviklet til selvstændigt brug, for at applikationerne kan bruges i en portal. Den danske borgerportal (borger.dk) og virksomhedsportal (virk.dk) er eksempler på portaler, der bruger integration via web-browser. 5

6 2 Arkitekturkomponenter > Før de forskellige scenarier kan blive beskrevet, skal de individuelle roller og komponenter i arkitekturen præsenteres. SAML Identity Provider Denne komponent bliver udrullet i organisationer, hvor medarbejderne har brug for adgang til applikationer hos andre organisationer. Identity Provider-komponenten kan autentificere lokale bruger og derefter udstede en såkaldt SAML assertion (se herunder), som identificerer brugeren og hans rettigheder overfor applikationer i et andet sikkerhedsdomæne. Dvs. at Identity Provider attesterer de lokale brugeres identiteter overfor andre organisationers applikationer. Når Identity Provider har brug for at autentificere en lokal bruger, kan brugeren logge ind direkte med sine brugeroplysninger, eller organisationen kan gøre brug af en SSOmekanisme såsom Kerberos. Autentifikation overfor Identity Provider er dog udenfor rammerne af OIOSAML. Det kan være nødvendigt for Identity Provider at hente en brugers adgangsrettigheder, når den skal lave en SAML assertion f.eks. fra et LDAP register, hvor den lokale organisation administrerer lokale brugere. Dette er også udenfor rammerne af OIOSAML. Flere detaljer om integration af SAML Identity Provider-komponenter vil kunne ses senere i denne guide. SAML Service Provider Denne komponent bliver udrullet i organisationer, der tilbyder webapplikationer til andre organisationer. Komponenten arbejder sammen med Identity Provider i brugerens egen organisation for at autentificere brugeren og få adgangsrettigheder, som kan bruges til at afgøre, om brugeren har adgang til applikationen. Dvs. at Service Provider stadig definerer og kontrollerer adgangen til applikationer, mens Identity Provider kun tildeler rettigheder til brugere. SAML Service Provider og SAML Identity Provider stoler på hinanden og kommunikerer i overensstemmelse med protokoller defineret i OIOSAML. Før de kan kommunikere, skal de 2 komponenter udveksle metadata som beskriver kommunikations-endpoints(url er), certifikater til digital signaturer og kryptering, understøttede attributter etc. SAML Assertion En SAML assertion er et XML-dokument, som dannes af Identity Provider ved modtagelse af en forespørgsel om autentificering af en bruger fra en Service Provider. Den indeholder information om brugerens identitet, hvornår brugeren blev autentificeret, styrken af autentifikationen og attributter om brugeren, der kan indeholde information om adgangsrettigheder forventet af Service Provider (f.eks. roller). OIOSAML definerer indholdet af assertions i den offentlige sektor samt et antal standardiserede identitetsattributter. Da information om adgangsrettigheder varierer fra implementation til implementation, er attributterne ikke defineret i OIOSAML og må defineres lokalt enten efter aftale mellem en lokal Identity Provider og Service Provider eller for en sektor (f.eks. sundhedssektoren). OIOSAML opstiller regler for hvordan lokale attributter skal defineres, bl.a. navngivningskonventioner. 6

7 > Applikation Applikationen er en webapplikation eller portal der kræver brugerautentifikation før beskyttede ressourcer kan tilgås. I scenarierne herunder er autentifikationsprocessen delegeret til separate SAML Service Provider-komponenter (som til gengæld delegerer til en Identity Provider-komponent i brugerens organisation). Service Provider-funktionaliteten kan også implementeres direkte i applikationen. 7

8 3 Grundlæggende scenarie > Herunder er et grundlæggende scenarie beskrevet, som illustrerer hvordan en bruger i en organisation kan bruge en lokal SAML 2.0-baseret Identity Provider til at få adgang til applikationer i et andet sikkerhedsdomæne. Scenariet vil være et vejledende eksempel igennem hele dette dokument, og de efterfølgende afsnit vil præcist beskrive forskellige aspekter af dette scenarie især integration med SAML-komponenter. I figur 2 er den lokale autentifikationsløsning i brugerens organisation et Active Directory (Kerberos), men andre løsninger kan også bruges. Figur 2: Flow i det grundlæggende scenarie Trinene er som følger: 1. Brugeren logger ind til sit lokale netværk i starten af en arbejdsdag. 2. På et tidspunkt laver brugeren via sin browser en forespørgsel til en webapplikation, der stilles til rådighed af organisation B. 3. Applikationen kræver autentifikation og autorisation af brugeren, så applikationen videresender brugeren til dens lokale SAML-baserede autentifikationsserver. 4. Autentifikationserveren finder brugerens Identity Provider (Discoverymekanismen bliver beskrevet senere) og sender en SAML autentifikationsforespørgsel til den. 5. SAML Identity Provider autentificerer brugeren via den lokale domain controller og henter information om brugerens adgangsrettigheder frem fra det lokale register, som er relevant for organisation B. Derudover laver den en session med brugeren og sætter sin identifikator i brugerens common domain cookie. 6. SAML Identity Provider laver en SAML 2.0 assertion der indeholder brugerens autentifikations- og autorisationsinformation og returnerer den. 8

9 > 7. SAML-serveren hos organisation (B) validerer den tilsendte SAML assertion, udtrækker information om adgangsrettigheder, omformaterer om nødvendigt informationen til et internt format, og returnerer det. 8. Applikationen laver en session med brugeren og ekspederer forespørgslen baseret på brugerens identitet og den supplerede adgangsrettighedsinformation. Forudsætningerne og antagelserne i det ovenstående scenarie er: At organisation (B) stoler på organisation A s autentifikation af deres egne brugere og administration af adgangsrettigheder til applikationer. De 2 organisationer har udvekslet SAML metadata, herunder hvilke adgangsrettigheder (grupper, roller, privilegier), organisation (B) behøver. Organisation (B) har skilt sin SAML-implementation ud fra applikationen (trin 3). I nogle tilfælde kan SAML-implementationen være direkte indlejret i applikationen. Administratorer i organisation A har tildelt de påkrævede adgangsrettigheder til lokale brugere. Service Provider (org. B) kan afgøre hvilken Identity Provider, den skal sende autentifikationsforespørgslen til (se discovery-funktionalitet nedenunder). SAML Identity Provider i organisation (A) skal kun bruge den lokale domain controller til bruger autentifikation ved første anvendelse. Derefter har den sin egen session med brugeren og kan udstede et token automatisk. 9

10 4 Overvejelser > Dette kapitel beskriver en række overvejelser, der er relevante, når man skal oprette en føderation mellem organisationer i den offentlige sektor. OIOSAML vedrører kun arkitektur, protokoller og policies, men der er mange andre ting at overveje, eksempelvis juridiske og organisatoriske spørgsmål, hvordan adgangsrettigheder bliver repræsenteret, og integration med den eksisterende infrastruktur. 4.1 Oprette tillidsforhold En grundlæggende forudsætning i en føderation er, at der er et tillidsforhold mellem Identity Provider og Service Provider. F.eks. skal en Service Provider have tillid til at Identity Provider autentificerer brugere korrekt, at Identity Provider kan stå inde for brugernes identitet, tildele de rigtige adgangsrettigheder, samt drive et sikkert system og følge aftalte procedurer og politikker. Som udgangspunkt skal enhver Identity Provider, der ønsker at deltage i den fællesoffentlige føderation, indgå en aftale med sekretariatet for det fællesoffentlige brugerstyringssamarbejde i Økonomistyrelsen. Føderationen har defineret en række krav, der skal mødes af alle Identity Providere i føderationen, herunder tekniske krav, sikkerhedskrav og krav til logning, tid etc. Når en Identity Provider har opfyldt disse føderationskrav, bliver dens metadata føjet til en såkaldt white list på den fællesoffentlige føderations netsted. Her kan en Service Provider undersøge om en Identity Provider findes på føderationens white list og dermed have tillid til, at føderationskravene er opfyldt Lokale aftaler En Service Provider-organisation vil typisk kræve en godkendelse af et sæt vilkår og betingelser for brug af deres applikationer, som går ud over føderationskravene (som er applikations- og datauafhængig). Omvendt kan en Identity Provider-organisation også have krav til Service Provider f.eks. angående kvalitet af service, fordi den givne applikation kan være kritisk for Identity Provider-organisationens forretningsprocesser. Hvis det er tilfældet, er det nødvendigt at lave en lokal aftale mellem Identity og Service Provider. Aftalen kan regulere mange områder bl.a. roller og ansvar, procedurer, kvalitet af service, sikkerhedskrav såsom til adgangskontrol til applikationen, krav til håndtering af følsomme data udstillet af applikationen, og krav til Identity Provider-organisationen om korrekt håndtering af brugeradgang til applikationen i henhold til Service Providers procedurer. 4.2 Metadata udveksling Efter tillidsforhold og juridiske aftaler er blevet oprettet mellem organisationerne, er det nødvendigt at udveksle metadata mellem Identity og Service Provider (dvs.importere partnerens metadatafil i sit eget system). En organisations metadatafil indeholder teknisk information om SAML installationen såsom end-points (URL er) for SAML services, certifikater brugt til signering og kryptering og understøttede attributter. Formatet for metadata er standardiseret og yderligere specificeret i OIOSAML. 10

11 > Ved at importere partnerens metadatafil er et teknisk tillidsforhold implicit etableret. Dvs. at SAML servere nu vil acceptere og bruge SAML forespørgsler signeret af partnerens digitale signatur. 4.3 Repræsentation af adgangsrettigheder Mange applikationer kræver ikke kun brugerautentifikation, men også information om brugerens adgangsrettigheder, hvilket kan være gruppemedlemskab, roller eller privilegier til at differentiere adgang. Hos lokale Identity Provider-organisationer bør information om adgangsrettigheder administreres af en lokal administrator i brugerens egen organisation. For at dette scenarie skal virke, skal Service Provider på forhånd kommunikere til Identity Provider hvilke informationer om adgangsrettigheder, der er påkrævet, såvel som semantik og procedurer. F.eks kan en applikation påkræve en attribut rolle som kan have værdierne bestyrer, indkøber, admin eller almindelig_ansat. Dette kommunikeres til Identity Provider, som skal sørge for at den lokale administrator internt tildeler disse roller til brugere, som har brug for adgang til applikationen, og at de tildelte roller ved afvikling bliver inkluderet i de udstedte SAML assertions til denne applikation. Service Provider skal definere den påkrævne adgangsrettighed som et sæt SAML attributnavne med associerede værdier, som kan blive inkluderet i en SAML assertion. For at undgå overlappende attributnavne kræver OIOSAML, at attributnavne defineret af en organisation (f.eks. Service Provider) er en URL med organisationens domænenavn som præfiks. Eksempel: <saml:attribute Name= urn:dk:dmp:attributes:roles NameFormat= urn:oasis:names:tc:saml:2.0:attrname-format:basic > <saml:attributevalue>miljoe_natur_naturdata_fdc,miljoe_natur_naturdata_laes </saml:attributevalue> </saml:attribute> Service Provider-organisationen kan have flere applikationer, som hver har et forskelligt sæt adgangsrettighedsattributter. For ikke at blotlægge denne kompleksitet til alle organisationer, som bruger applikationen, kan man bruge role mapping. Det betyder, at Service Provider udadtil kun kræver, at Identity Provider bruger nogle få konsoliderede roller, som internt oversættes til applikationsroller, for på denne måde at skærme af for kompleksiteten. Service Provider-krav til adgangsrettighedsattributter kan blive kommunikeret som metadata eller via en out-of-band mekanisme til Identity Provider. En SAML metadatafil kan f.eks. indeholde et <AttributeConsumingService> element, som er en liste med attributnavne krævet af en applikation. 4.4 Identity Provider discovery-funktion Et centralt spørgsmål er hvordan en Service Provider finder en brugers Identity Provider, når brugeren prøver at tilgå en applikation. For afgøre dette, skal en Service Provider gøre følgende: 11

12 > 1. Først skal den prøve at læse common domain cookie (domænet er fobs.dk for den fællesoffentlige føderation) for at undersøge, om den kan identificere brugerens nuværende Identity Provider. Det er obligatorisk for OIOSAMLkompatible Identity Providere at oprette en common domain cookie, når brugeren er autentificeret, således at hvis en bruger har en session med en Identity Provider, vil en common domain cookie være oprettet. 2. Hvis common domain cookie ikke kan identificere en brugers Identity Provider, skal Service Provider bede brugeren om at vælge en Identity Provider fra en liste af Identity Providere, som den har fødereret med (brugeren vælger sin egen organisation). Common domain cookie i OIOSAML er transient, hvilket betyder, at den vil blive fjernet når, browseren genstartes. 12

13 5 Identity Provider integration > Dette kapitel beskriver den integration, som normalt er påkrævet af en Identity Provider-organisation. Det antages, at Identity Provider har anskaffet en SAMLkomponent f.eks. enten et kommercielt produkt eller en open source implementation 2. En række overvejelser om integration af eksisterende infrastruktur er beskrevet herunder. Detaljerne i integrationen vil variere en del afhængig af både SAML-produkt og eksisterende infrastruktur for brugerstyring. 5.1 Autentifikation af bruger Identity Provider er ansvarlig for at autentificere lokale brugere, inden den udsteder SAML assertions til applikationen. Det kan gøres på forskellige måder: Autentifikation med brugeroplysninger opbevaret i organisationens LDAP register. Autentifikation vha. single sign-on løsning udrullet i organisationen (f.eks. Kerberos). Autentifikation med digitalt certifikat udstedt af en ekstern Certificate Authority (CA) - f.eks. det danske OCES medarbejdercertifikat. Den valgte autentificeringsmekanisme skal være integreret med et SAML-produkt (f.eks. login siden). De fleste SAML-produkter tillader brugen af tilpassede loginmekanismer og mange understøtter også Kerberos og LDAP registre uden tilpasning (så integrationen er en konfigurationsudfordring, ikke et programmeringsspørgsmål). En vigtig detalje er, at styrken af autenticitetssikringen skal være afspejlet i den udstedte SAML assertion. OIOSAML specificerer en obligatorisk attribut AssuranceLevel, som har en værdi mellem 1 og 4. Jo højere tal, jo højre tillid til den påståede identitet. Normalt korrelerer autentifikation med brugernavn/password til niveau 2 og autentifikation med digital signatur (softwarebaseret) korrelerer til niveau 3, men andre faktorer end autentifikationsmetoden har også indflydelse, såsom proceduren for den initielle autentifikation af brugeren, når akkreditivet skal udstedes. Identity Provider skal analysere hvilken AssuranceLevel, der opnås ved en given autentifikation, og inkludere det i den udstedte assertion. Mere information om AssuranceLevel kan findes i [AUTH-LEV] og [AUTH-LEV2]. Bemærk, at en Servicer Provider kan vælge at give adgang til følsomme applikationer (og data) på baggrund af den AssuranceLevel, der bliver tilskrevet hos Identity Provider. Service Provider skal som følge af kravene i forbindel med føderationstilslutningen lave en risikoanalyse for deres applikationer og data for at fastslå den påkrævede AssuranceLevel. Det betyder, at brugere fra en organisation der implementerer en lav AssuranceLevel muligvis ikke kan tilgå følsomme applikationer. 2 Open source reference implementationer af OIOSAML i Java og.net kan hentes fra 13

14 > 5.2 Opbevaring af informationer om adgangsrettigheder Service Providere kan definere adgangsrettighedsattributter, som Identity Provider organisationen skal tildele brugere og inkludere i de tildelte SAML assertions. Der er flere måder at opbevare denne information på: Adgangsrettigheder kan blive gemt i et brugerkatalog (f.eks. LDAP) som allerede indeholder information om brugere og deres adgangsrettigheder til interne applikationer. En relationel database kan oprettes til formålet. Funktionalitet fra et Identity Provider produkt kan bruges. Valget af, hvilken metode, man skal bruge, vil afhænge af, hvordan organisationen i forvejen administrerer brugere internt. Hvis en organisation eksempelvis har en brugeradministrationsløsning for interne applikationer, kan denne bruges, så der ikke bliver skabt et nyt administrativt område. Derudover skal et Identity Provider-produkt kunne hente informationen, når den skal udstede SAML assertions. De fleste SAMLprodukter kan hente brugerinformation fra mange forskellige slags datakilder, og denne funktionalitet bør overvejes, når et produkt evalueres i forbindelse med en anskaffelse. Herunder er vist et eksempel, hvor information fra en bruger-database bliver inkluderet i en SAML assertion. Når brugeren Bob prøver at tilgå en applikation hos organisation B, laver den lokale Identity Provider hos organisation A en forespørgsel til databasen og finder ud af, at organisation B forventer en attribut ved navn roller, og at værdien tildelt til Bob (af den lokale administrator i organisation A) til denne attribut er manager,administrator. Derfor inkluderer Identity Provider denne som en attribut i den SAML assertion, der bliver sendt til Service Provider. Figur 3: Inkludering af information om adgangsrettigheder fra bruger-database i SAML assertion. En gængs løsning er at opbevare information om adgangsrettigheder i et LDAP directory såsom et Active Directory. Det giver to muligheder: 14

15 > a) Informationen kan gemmes vha. grupper fra Active Directory. b) Informationen kan gemmes som brugerdefinerede attributer til brugerobjektet. Når informationen er gemt som et LDAP gruppemedlemskab (a), vil værdien ofte være gruppens Distinguished Name (DN). Dette kan være problematisk, fordi Service Provider udvælger værdierne til adgangsrettighedsattributter og på den måde direkte gruppe objekter ind i Identity Provider s LDAP. Hvis denne fremgangsmåde er under overvejelse, bør en mapning af DN foretages for ikke at forurene Identity Providers LDAP. Det kan i stedet være en fordel at opbevare information om adgangsrettigheder som brugerdefinerede attributter til brugerobjektet i LDAP (b) eller i en separat relationel database. Generelt bør Service Provider definere attributnavne og -værdier til adgangsrettigheder, som kan gemmes både i LDAP og i relationelle databaser. Til sidst er det muligt at Identity Provider vil opbevare attributter, så de er identificeret med den Service Provider, der skal bruge dem. En assertion til en specifik Service Provider bør kun indeholde de attributter, der er påkrævet af denne. 5.3 Overvejelser om netværk Den server, der hoster Identity Provideren, behøver ikke normalt at være forbundet med internettet fordi kommunikation med Service Provider sker via brugerens browser (med http redirect og post binding). En undtagelse er, hvis en SAML single logout protokol er brugt med en SOAP binding (som er valgfrit i OIOSAML). Det betyder, at Identity Provider komponenten ofte kan installeres i en intern netværkszone (f.eks. en zone dedikeret til servere, som også hoster brugerkataloget, så kataloget kan bruges til brugeridentifikation). Hvis der er brug for en single logout via SOAP binding, skal Identity Provideren placeres i en netværkszone, der tillader både ind- og udgående forbindelser til/fra internettet. Dette kan enten være en demilitariseret zone 3 (DMZ) eller en speciel zone afhængigt af den brugte netværkstopologi. Når man installerer en Identity Provider komponent, er det meget vigtigt at beskytte den private nøgle, der bruges til at signe assertions med, da dette er systemets kronjuvel. Hvis det lykkes en hacker at stjæle den private nøgle, kan han lave sine egne SAML assertions og tilgå Service Provider applikationer på vegne af enhver bruger i Identity Provider organisationen. Derfor, hvis den private nøgle er gemt i en fil, bør den adgangsbeskyttes vha. de muligheder, styresystemet stiller til rådighed, samt krypteres med et password af høj kvalitet. 3 En DMZ tillader normalt ikke udgående forbindelser til internettet ifølge best practice, så alle undtagelser i firewall bør afgrænses til en bestemt server for en bestemt port. Mange organisationer har sandsynligvis allerede netværkszoner, der tillader udgående forbindelser. 15

16 6 Service Provider integration > Dette kapitel beskriver den integration, som normalt er påkrævet af en Service Provider-organisation. Det antages, at Service Provider har anskaffet en SAMLkomponent f.eks. enten et kommercielt produkt eller en open source implementation 4. En række overvejelser om integration af eksisterende infrastruktur er beskrevet herunder. Detaljerne i integrationen vil variere en del afhængigt af både SAML-produkt og eksisterende infrastruktur for brugerstyring. 6.1 Adgangskontrol Inden en Service Provider udstiller applikationer til eksterne brugere, bør den analysere sine krav til sikkerheden af brugerautentifikationen og udfærdige en politik for adgangskontrol. Som tidligere nævnt er AssuranceLevel et udtryk for, hvor sikker man kan være på, at en brugers påståede identitet er korrekt. Den afhænger af både organisationens procedurer og kontrol så vel som tekniske mekanismer. En Service Provider skal som det første klassificere sine applikationer (se AUTH-LEV2) for at afgøre, hvilke sikkerhedskrav, der skal opfyldes for at få adgang. Det vil f.eks. afhænge af hvilke data, applikationen udstiller. Identity Provider kan informere om AssuranceLevel for den nuværende bruger via SAML assertions. Service Provider skal konfigurere sit system til at undersøge denne attribut og kun give adgang til applikationer, hvis sikkerhedskravet er opfyldt. Ydermere skal Service Provider analysere sine applikationer for at afklare, hvilke privilegier, der er påkrævet. Eksempelvis kan en applikation kræve, at brugeren har en bestemt rolle, er medlem af en bestemt gruppe etc. Hvis Service Provider udstiller applikationer med forskellige krav, kan det være en fordel at definere et sæt abstrakte, konsoliderede roller (synlige for Identity Provider) og mappe dem til interne applikationsroller (usynlige for Identity Provider). Adgangskontrollen skal kommunikeres til Identity Provider organisationen, så privilegier kan blive konfigureret i systemet og tildelt til brugere. Information om de påkrævne SAML attributter (syntaks) kan være en del af metadatafilen eller blive kommunikeret på anden måde. Dog er en beskrivelse ofte nødvendig for at forklare hvordan adgangsrettigheder skal tildeles af brugeradministratorer. 6.2 Integration med lokale adgangskontrolsystemer Brugerens identitet og adgangsprivilegier modtages via en SAML assertion fra Identity Provider ved runtime. Service Provider skal bruge den information til at afgøre, om brugeren skal have adgang til den efterspurgte applikation eller ej. Det medfører at en form for integration mellem SAML-komponenten og adgangskontrolkomponenten 5 er nødvendig (medmindre de ikke er en del af det 4 Open source referenceimplementationer af OIOSAML i Java og.net kan hentes fra 5 Dette komponent kaldes et Policy Enforcement Point (PEP). 16

17 > samme system). Integrationen vil afhænge af, hvordan Service Provider håndterer adgangskontrol i sin it-arkitektur. Adgangskontrol kan f.eks. håndteres på følgende måder: a) Det kan være en del af et SAML-produkt (f.eks. en access control suite der understøtter SAML). b) Der kan være en separat server, der varetager adganskontrollen for alle organisationens applikationer (f.eks. en reverse proxy, der kun tillader forespørgsler at passere, hvis de er i overenstemmelse med specifikke krav). c) Den kan varetages af applikationsserveren (container), der hoster applikationen (f.eks. J2EE deklarativ sikkerhed). d) Den kan varetages af selve applikationen (ikke anbefalet, men meget almindeligt). En typisk metode er at få SAML-komponenten til at validere SAML assertions først og derefter videresende vigtig information som key/value-par til processering hos en separat server, der varetager adgangskontrol: Figur 4: Et eksempel på en adgangskontrolkomponent Et andet typisk integrationsmønster (punkt c) er at skrive plug-ins til middleware i den bagvedliggende applikationsserver, som implementerer autentifikation og adgangskontrol såkaldte Pluggable Authentication Modules (PAMs). Ideen er at adskille autentifikations- og autorisationslogik, så det senere hen kan blive erstattet, uden at det er nødvendigt at røre ved applikationerne. Disse plug-ins er som regel realiseret ved at implementere nogle få klasser med fast definerede snitflader, der tillader servermiddleware at forespørge efter informationer om f.eks. brugeridentitet, gruppemedlemsskab og roller. På den måde er kun det plugin, der behøver at kende brugeren, og middleware varetager resten, bl.a. sessionshåndtering og adgangskontrol vha. af prædefinerede adgangspolitikker. Dette er illustreret i figuren herunder, hvor en specialfremstillet SAML-plug-in (den røde boks) gør det muligt at føderere med adskillige applikationer. Læg mærke til at en forudsætning for denne integration er, at applikationer er blevet designet til at uddelegere brugerstyring til applikationsserveren (f.eks. vha. deklarativ sikkerhed). Hvis applikationerne har indkodet egen adgangskontrollogik, skal dette nødvendigvis kodes om. 17

18 > Figur 5:Specialfremstillet plug-in til applikationsserver Eksempler på plug-in-arkitekturer er RoleProvider og MembershipProvider i ASP.Net og JAAS-moduler i Java. Kodeeksempler med.net plug-ins til Umbraco CMS vha. OIOSAML.NET referenceimplementationen kan findes på Softwarebørsen Overvejelser ved netværk Den server, der hoster Service Provider-komponenten, behøver ikke normalt at være forbundet med internettet fordi kommunikation med Identity Provideren sker via brugerens browser (med http redirect og post binding). En undtagelse er, hvis en SAML single logout protokol er brugt med en SOAP binding (som er valgfrit i OIOSAML). Det betyder, at Service Provider-komponenten ofte kan installeres i en intern netværkszone. Hvis der er brug for en single logout protokol via SOAP binding, skal Service Provideren placeres i en netværkszone, der tillader både ind- og udgående forbindelser til/fra internettet. Dette kan enten være en demilitariseret zone eller en speciel zone afhængigt af den brugte netværkstopologi. Når man installerer en Service Provider-komponent, er det meget vigtigt at beskytte den private nøgle, der bruges til at signere autentifikationsforespørgsler og dekryptere svar. Hvis det lykkes en hacker at stjæle den private nøgle kan han dekryptere assertions og tilegne sig viden om indholdet af følsomme attributter. Hvis den private nøgle er gemt i en fil, bør den derfor beskyttes vha. de muligheder, styresystemet stiller til rådighed og krypteres med et password af høj kvalitet

19 Appendix A: Referencer > [OIOSAML] [SAMLCore] [SAMLGlos] [AUTH-LEV] [AUTH-LEV2] [REFIMPL] OIO Web SSO Profile V2.0.6, IT- og Telestyrelsen. Assertion and Protocols for the OASIS Security Assertion Markup Language 2.0, OASIS Standard os.pdf Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard. Vejledning vedrørende niveauer af autenticitetssikring. Vejledning til autenticitetssikringsniveau for den fællesoffentlige log-inløsning, Økonomistyrelsen, Version Referenceimplementationer af OIOSAML i Java og.net:

20