Anbefalinger der sendes i hring vedrrende OIO Referencemodel

Anbefalinger, der sendes i høring vedrørende OIO Referencemodel for tværgående brugerstyring Oplæg 2. september 2005 Søren Peter Nielsen

Agenda n n Review af scope Anbefalingerne fra høringsdokumenterne n Arkitektur for tværgående autenticitetssikring n n n n Niveauer af autenticitetssikring Basisattributter til beskrivelse af bruger Unik id-nøgle til matchning og synkronisering af brugerkonti Anbefaling vedrørende RBAC standarden Rettighedsstyring for eksterne brugere – Diskussion af scenarier Videre arbejde Diskussion

Hvad er brugerstyring? Brugerstyring handler bl. a om hvorledes brugere identificeres, hvilke rettigheder de skal have og hvorledes der sikres sporbarhed i forhold til brugernes handlinger, samt den nødvendige bagvedliggende administration. Discalimer: Ordet brugerstyring er i sig selv måske ikke særlig retvisende, da det ikke drejer sig om at ”styre brugere”. En mere korrekt betegnelse er fx Administration og anvendelse af it-brugeres og it-systemers identiteter og rettigheder. Imidlertid er det en temmelig lang betegnelse, og det har vist sig at betydningen af ordet brugerstyring i forbindelse med digital forvaltning generelt ikke misforstås. Derfor holdes fast i betegnelsen brugerstyring, som dækkende administration og anvendelse af it-brugeres og it-systemers identiteter og rettigheder indtil der eventuelt foreslås en bedre betegnelse

Brugerstyring er en delmængde af it-sikkerhed It-sikkerhed er et af flere formål med etablering af brugerstyringssystemer i forbindelse med digital forvaltning: n n It-sikkerhed – risikominimering Overholdelse af lovmæssige krav – fx i forhold til persondataloven Bedre service til borgere og virksomheder Effektivisering n n n Hensigtsmæssig administration Brugervenlighed Fleksibilitet og interoperabilitet n Via standardisering og integration

Hvad er en referencemodel? En referencemodel udpeger og fastlægger et sæt af modeller, som løser en veldefineret og afgrænset opgave. Referencemodellen fastlægger gennem modeller og beskrivelser her af konsistente mønstre, standarder eller en arkitekturstil for løsningen. Fastlæggelsen af hvilke modeller og modellernes konkrete udseende, fortolkning og kvalitative egenskaber skal ske gennem en fællesoffentligt høringsproces. Formålet er at sikre opbakning blandt parthavere og interessenter inden for det område, løsningen har betydning, for en fælles løsning, således at alle implementeringer følger modellen.

Overordnet referencemodel for opgaverne ved brugerstyring Administration og styring Autenticitetssikring Lagring Udstedelse af akkreditiver Autorisation Logning og kontrol

Bruger-identitet og rettigheder – Eksempler på tværgående udfordringer <- TILLID -> Organisation A Organisation B Brugerkatalog Rettighedsstyring Processer & Data Sporbarhed? Processer & Data Rettigheder? Identitet? Privacy? Teknik og begreber? Hvad kan med fordel laves som fælles løsninger?

Høringsdokumenterne n n n Fem dokumenter med anbefalinger, og et diskussionspapir i høring på http: //www. oio. dk/arkitektur/brugerstyring/hearing Niveauer af autenticitetssikring Arkitektur for tværgående autenticitetssikring n n Basisattributter til beskrivelse af bruger Unik id-nøgle til matchning og synkronisering af brugerkonti Anbefaling vedrørende RBAC standarden Rettighedsstyring for eksterne brugere – Diskussion af scenarier

Behov vedr. arkitektur n n Støtte at forskellige myndigheder kan anvende en fælles login-service Simplified Sign-On (SSO) Etablere struktur som giver basis for tværgående rettighedsstyring i følgende faser Hvordan finder forretningsløsninger og login-services hinanden ude i den store vide verden uden af brugeren skal gøre det hele manuelt? Og uden at vi laver centrale monolit-løsninger?

Til gennemgangen taler vi om tre logiske ting Portal – som indgang til forskellige løsninger og en eller flere login-services Login-service = CS (Credential Service), ofte også kaldet Idp (Identity Provider) Løsninger = AA (Agency Application), ofte også kaldet SP (Service Provider) Portal, CS og AA kan være i forskellige organisationer, men behøver det ikke. Fx kan en AA og have ”sin egen” Portal

Step #1: User goes to Portal to select the AA and CS Portal AAs ECPs Step #2: The user is redirected to the selected CS with an AA identifier. The portal also cookies the user with their selected CS. ©p AAx CS Users Step #3: The CS authenticates the user and ©c hands them off to the selected AA with their identity information. The CS also cookies the user as Authenticated. MD SSO Options: * SAML 2. 0 AAx Auth. Z

Portal Step #2: The user is redirected to the portal with the AA ID ©p AA Step #3: After selecting their CS the user is cookied and redirected as usual AA CS ©c Step #1: User Starts at AA Step #4: The user is handed off to the AA as usual. AAx

SSO Portal Inklusiv Portalcookien med valgte CS © p Step #2: The user is redirected to the portal with the ©c AA ID AA Trin #3: Portalen kan evt. checke om Autenticitets-niveau er højt nok. Hvis ikke kan brugeren vælge ny CS – ellers redirectes direkte til CS med CS -cookie AA CS ©c ©c ©p Step #1: User Starts at AA Trin #4: CS checker at brugeren ikke har blokeret for at indgå i SSO – eller andre privacy-valg forhindrer SSO Step #5 : The user is handed off to the AA as usual. AAx

Løsninger fra følgende leverandører er i dag certificeret til dette koncept http: //www. cio. gov/eauthentication/documents/Approved. Providers. htm

Step 1: User starts at the portal and is guided through the selection of an CS and AA Portal Step 2: User gets a cookie with the CS identifier and is redirected to the selected CS with an application identifier ©p Step 3: User authenticates ©c CS To the CS and gets cookie Step 4: User is redirected to the selected agency application with a SAML Artifact Step 5: the AA uses the SAML artifact to retrieve user identity and attributes from the CS over SOAP/SSL AAn

SSO Step 2: The AA redirects any ©p Portal unauthenticated user to the portal with the application identifier for authentication. The portal’s cookie is Step 3: automatically sent User is redirected to the selected CS along by the from the cookie with the application browser identifier. The CS’s authentication cookie is automatically send along by the browser ©c ©p ©c CSn Step 4: The CS reads the cookie, determines the user is already logged in, and redirects the user to the AA with a SAML artifact Step 5: the AA uses the SAML artifact to retrieve user identity and attributes from the CS over SOAP/SSL Step 1: User starts at any AA AAn

Niveauer for autenticitetssikring n n n Niveau 1 identitet Niveau 2 Niveau 3 Niveau 4 identitet - Lille eller ingen tiltro til påståede - Nogen tiltro til påståede identitet - Høj tillid til påståede identitet - Meget høj tillid til påståede Anbefalet niveau bestemmes ud fra vurdering af risici n = hvilke konsekvenser, der kan forekomme ved fejl og sandsynligheden herfor

Til hvert niveau er der tekniske foranstaltninger, fx n Niveau 1 – fx Ingenting, Cookies n n Niveau 2 – fx Brugernavn/kodeord n n n Høj tillid til påståede identitet Niveau 4 – fx Flerfaktor tokens, Biometriske løsninger, . . n n Nogen tiltro til påståede identitet Niveau 3 – fx Digital Signatur n n Lille eller ingen tiltro til påståede identitet Meget høj tillid til påståede identitet Vejledningen dækker ikke anbefalinger om konkrete teknologier. Der henvises til Electronic Authentication Guideline fra NIST Hvilke tekniske foranstaltninger der passer til hvert niveau kan revurderes med mellemrum UDEN at der er behov for nogen risiko/forretnings-mæssige vurdering af eksisterende løsninger. De bestemte niveauer for autenticitetsikring er stadig valide.

Anbefaling om basisattributter for bruger Basisattributter: n sn - Efternavn n cn - Navn – det som personen omtaler sig som n uid - Brugerid n Mail - Mailadresse Mulige attributter n unique. Account. Key – unik Id-nøgle n cvr. Number – Ansættelsesmæssigt tilknytningsforhold Plus anbefaling om at navngivning af attributter følger LDAPNavngivning så vidt muligt

Eks. Hvad så med forskellige loginmetoder? Fx brugerid/ kodeord Vs Digital Signatur Mulighed: Portal ved at AA Step 2: The AA redirects any © p Portal behøver Dig Sig, unauthenticated user to the portal with the application og sender identifier for authentication. brugeren direkte The portal’s cookie is til en login. Step 3: automatically sent User is redirected to the selected CS service for along by the from the cookie with the application browser Dig. Sig, ellers identifier. The CS’s authentication cookie is automatically send along by the browser ©c ©p ©c Step 4: The CS reads the cookie, determines the user is already logged in, and redirects the user to the AA with a SAML artifact Step 1: Brugeren er logget User starts at any AA ind andetsteds med id/kodeord – niveau 2 I konvolutten står at brugeren har niveau 2: • Kan få CS til at lave ”step-up” til niveau 3 CSn • Kan sende brugeren til ”sin” niveau 3 CS • Kan sige ”sorry” Step 5: the AA uses the SAML artifact to retrieve user identity and attributes from the CS over SOAP/SSL Her kræves AAn Dig Sig niveau 3

Portal CS CS CS AA AA Aftalt SSO AA

Tværgående SSO kan også lade sig gøre uden tekn. ændringer – kræver blot at CS og AA har en aftale Portal CS CS CS AA AA SSO AA AA AA

Rollebaseret adgangskontrol

For god ordens skyld n n n Ikke en anbefaling om, at al rettighedsstyring skal være rollebaseret. Ikke en anbefaling om, at der skal defineres fælles roller for hele den offentlige sektor Ikke en anbefaling, som angiver implementeringsspecifikke anvisninger. n n Der anbefales en række mindstekrav for et rollebaseret adgangskontrolsystem. Disse vil skulle suppleres med en række andre krav i forhold til den enkelte organisations behov Vedrører ikke definition af en metode til identifikation af roller. Diskussionspapir vedr. dette vil senere blive sendt i høring

Anbefalinger n n n Det anbefales, at adgangsrettigheder baseres på roller og regler, således at rettigheder kun behøver at blive administreret for individuelle brugere i situationer, hvor roller og regler ikke kan anvendes. Det anbefales, at der for systemer til administration af rollebaserede rettigheder stilles mindstekrav om, at de skal overholde RBAC-kernens definitioner og krav i RBAC-standarden. Det anbefales, at der ved anskaffelse eller udvikling stilles et mindstekrav om, at it-systemer, hvor det er relevant, skal understøtte rollebaseret adgangskontrol som beskrevet i RBAC-kernen af RBAC-standarden.

RBAC-kernen Derudover funktionelle krav til rollesystemet, fx • Mulighed for samlede overblik • Alle roller tilknyttet en bruger • Alle privilegier tilknyttet en rolle

Rettighedsstyring for eksterne brugere – Diskussion af scenarier Diskuterer behov og udvikling indenfor styring af rettigheder for tværgående brugere

Standarder som anbefales i forbindelse med tværgående brugerstyring n n n LDAP 3. 0 SAML 2. 0 RBAC n WS-Security OCES n Boblere n n n XACML 2. 0 SPML (eller efterfølger)

Baseret på bred dialog n n Udarbejdes i af arbejdsgruppe under It. Arkitekturkomiteen i fællesoffentligt regi Bred interessentkreds n n n Løsningsejere Regulatorer Interesseorganisationer Løsnings- og pakke-leverandører Internationale initiativer Workshops er et vigtigt element

Afrunding n Arbejdet med at definere en fælles tilgang til brugerstyring i offentlige løsninger er en lang rejse, hvor det første skridt langt om længe er taget n n n Fokus på tværgående problemstillinger med henblik på mere fleksibilitet og bedre interoperabilitet Baserer sig i videst muligt omfang på internationale standarder og internationalt arbejde Opmærksomhed på hvordan vi finder den mest effektive vej frem fra de nuværende løsningsteknikker til standardbaserede fleksible og interoperable løsninger

Anbefalinger i høring fordelt på seks dokumenter n n Niveauer af autenticitetssikring Arkitektur for tværgående autenticitetssikring (Incl. SSO) n n Kerneattributter med information om bruger Struktur for id-nøgle til sammenknytning af forskellige brugerkonti RBAC-standarden til rollebaseret adgangskontrol Diskussionspapir vedrørende styring af rettigheder for eksterne brugere

Opsummering af anbefalinger Det anbefales at systemejere anvender vejledning vedrørende niveauer af autenticitetssikring i forbindelse med tværgående brugerstyring, som basis for en fælles opfattelse af nødvendige niveauer af autenticitetssikring. Ved etablering af tværgående autenticitets-sikringsservices anbefales det at anvende Anbefaling om fælles arkitektur for tværgående autenticitetssikring Til match eller oprettelse af brugere i tværgående sammenhænge anbefales det at anvende Anbefaling til kerneattributter for bruger Til kobling eller synkronisering af brugerinformationer i tværgående sammenhænge anbefales det at anvende en fælles nøgle, som defineret i Anbefaling til unik Id-nøgle Det anbefales at anvende rollebaseret adgangskontrol baseret på RBAC-standarden (i kombination med regelbaseret adgangskontrol)

Niveauer af autenticitetssikring Baggrund Multi-Factor Token PKI/ Digital Signature Increased $ Cost Knowledge-Based Pin/Password Click-wrap Low Surfing the Internet High Very High Medium Standard Access to Protected Website Applying for a Loan Online Obtaining Govt. Benefits Increased Need for Identity Assurance Employee Screening for a High Risk Job

Niveauer for autenticitetssikring n n n Niveau 1 identitet Niveau 2 Niveau 3 Niveau 4 identitet - Lille eller ingen tiltro til påståede - Nogen tiltro til påståede identitet - Høj tillid til påståede identitet - Meget høj tillid til påståede Anbefalet niveau bestemmes ud fra vurdering af risici n = hvilke konsekvenser, der kan forekomme ved fejl og sandsynligheden herfor

Kategorier af mulige risici inkluderer n n n Ulempe, kval, eller tab af anseelse Økonomisk tab eller ansvarspådragelse Skade på myndighedsinitiativer eller andre offentlige interesser Ikke-autoriseret frigivelse af sensitiv information Brud på personlig sikkerhed Mulighed for at begå/modvirke opklaring af ulovligheder

Muligt omfang af risici n n n Lille skade eller virkning Moderat skade eller virkning Stor skade eller virkning Eksempel Risiko for - Ulempe, kval, eller tab af anseelse Lille – Giver højest kortvarig ulempe, kval eller forlegenhed til hvilken som helst organisation eller person Moderat – Giver højest betænkelig kortvarig eller begrænset længerevarende ulempe, kval eller tab af anseelse til hvilken som helst organisation eller person. Stor – Alvorlig eller betænkelig længerevarende ulempe, kval eller tab af anseelse til hvilken som helst organisation eller person (reserveres generelt til situationer med særligt alvorlige konsekvenser, eller som vedrører mange personer).

Match af risici med sikkerhedsniveau

Bestemmelse af sikkerhedsniveau 1. Udfør risikovurdering for det givne it-system. 2. Match identificerede risici til nødvendigt niveau af autenticitetssikring 3. Vælg teknologi til autenticitetssikring. 4. Valider efter implementering at systemet i drift har det nødvendige niveau af autenticitetssikring. 5. Revurdér periodisk om systemet har behov for teknisk opgradering af autenticitetssikringen. Det nødvendige niveau af autenticitetssikring skal ses i sammenhæng med øvrigt sikkerhedsforanstaltninger i en løsning

Til hvert niveau er der tekniske foranstaltninger, fx n Niveau 1 – fx Ingenting, Cookies n n Niveau 2 – fx Brugernavn/kodeord n n n Høj tillid til påståede identitet Niveau 4 – fx Flerfaktor tokens, Biometriske løsninger, . . n n Nogen tiltro til påståede identitet Niveau 3 – fx Digital Signatur n n Lille eller ingen tiltro til påståede identitet Meget høj tillid til påståede identitet Vejledningen dækker ikke anbefalinger om konkrete teknologier. Der henvises til Electronic Authentication Guideline fra NIST Hvilke tekniske foranstaltninger der passer til hvert niveau kan revurderes med mellemrum UDEN at der er behov for nogen risiko/forretnings-mæssige vurdering af eksisterende løsninger. De bestemte niveauer for autenticitetsikring er stadig valide.

Slut på niveauer af autenticitetssikring

Anbefaling om Arkitektur for tværgående autenticitetssikring Formål: n Støtte at forskellige myndigheder kan anvende en fælles login-service n Simplified Sign-On (SSO) n Etablere struktur som giver basis for tværgående rettighedsstyring i følgende faser

Vi taler om tre logiske ting Portal – som indgang til forskellige løsninger og en eller flere login-services Login-service = CS (Credential Service), ofte også kaldet Idp (Identity Provider) Løsninger = AA (Agency Application), ofte også kaldet SP (Service Provider) Portal, CS og AA kan være i forskellige organisationer, men behøver det ikke. Fx kan en AA og have ”sin egen” Portal

Step #1: User goes to Portal to select the AA and CS Portal AAs ECPs Step #2: The user is redirected to the selected CS with an AA identifier. The portal also cookies the user with their selected CS. ©p AAx CS Users Step #3: The CS authenticates the user and ©c hands them off to the selected AA with their identity information. The CS also cookies the user as Authenticated. MD SSO Options: * SAML 2. 0 AAx Auth. Z

Portal Step #2: The user is redirected to the portal with the AA ID ©p AA Step #3: After selecting their CS the user is cookied and redirected as usual AA CS ©c Step #1: User Starts at AA Step #4: The user is handed off to the AA as usual. AAx

SSO Portal Inklusiv Portalcookien med valgte CS © p Step #2: The user is redirected to the portal with the ©c AA ID AA Trin #3: Portalen kan evt. checke om Autenticitets-niveau er højt nok. Hvis ikke kan brugeren vælge ny CS – ellers redirectes direkte til CS med CS -cookie AA CS ©c ©c ©p Step #1: User Starts at AA Trin #4: CS checker at brugeren ikke har blokeret for at indgå i SSO – eller andre privacy-valg forhindrer SSO Step #5 : The user is handed off to the AA as usual. AAx

Arkitekturen med anvendelse af SAML

Step 1: User starts at the portal and is guided through the selection of an CS and AA Portal Step 2: User gets a cookie with the CS identifier and is redirected to the selected CS with an application identifier ©p Step 3: User authenticates ©c CS To the CS and gets cookie Step 4: User is redirected to the selected agency application with a SAML Artifact Step 5: the AA uses the SAML artifact to retrieve user identity and attributes from the CS over SOAP/SSL AAn

Hvad skal SAML konvolutten så indeholde? n n n Basis attributter for bruger Niveau af autenticitetssikring Hvis login med OCES info vedr certifikat Yderligere specifikationer med hensyn til mindsteindhold i SAML-konvolutten (en såkaldt profile), navn på virtuelt domæne, og indhold i cookies vil blive dokumenteret i samarbejde med partnere i et fællesoffentligt pilotprojekt. Efter en høring vil disse specifikationer blive publiceret som anbefalinger vedrørende implementering af tværgående autenticitetssikring.

Anbefaling om basisattributter for bruger Basisattributter: n sn - Efternavn n cn - Navn – det som personen omtaler sig som n uid - Brugerid n Mail - Mailadresse Mulige attributter n unique. Account. Key – unik Id-nøgle n cvr. Number – Ansættelsesmæssigt tilknytningsforhold Plus anbefaling om at navngivning af attributter følger LDAPNavngivning så vidt muligt

Anbefaling om unik id-nøgle Formål: at kunne identificere brugere entydigt – men begrænset til den kontekst brugeren optræder i - på tværs af it-systemer og over tid dvs. sporbarhed samt at kunne matche og synkronisere information om brugeren n n Baseret på e. Xtensible Ressource Identifier (XRI) rammen 3 -leddet størrelse med to typer: n n Fælles dansk rod-organisation – fx @DK-XRI CVR-nummer for oprettende organisation + tidsstempel n n n Type af bruger: Ansat eller Borger Identifier, som er unik indenfor egen organisation n n Eller organisationens egen registrerede enhed i XRI Fx løbenummer Nøglen behøver ikke at have nogen betydning udover at være et unikt ”nummer” som kan knytte eksisterende information om brugeren sammen på tværs af systemer

Slut på n n n Arkitektur for tværgående autenticitetssikring Basisattributter for bruger Unik id-nøgle

Anbefaling om rollebaseret adgangskontrol Formål: n Medvirke til en mere effektiv, mere sikker, mere fleksibel administration af rettigheder i it-systemer ved hjælp af rollebaseret adgangskontrol n Definere fælles begreber, som forudsætning for fælles sprog og fælles tilgangsmåde i forhold til rollebaseret adgangskontrol n Definere en anbefaling om mindstekrav til it-systemer, der understøtter og anvender rollebaseret adgangskontrol n Skabe en af de grundlæggende byggesten for løsninger, der automatiserer tildeling, vedligeholdelse og fratagelse af ressourcer og adgangsrettigheder for it-brugere (også kaldet provisioneringsløsninger)

For god ordens skyld n n n Ikke en anbefaling om, at al rettighedsstyring skal være rollebaseret. Ikke en anbefaling om, at der skal defineres fælles roller for hele den offentlige sektor Ikke en anbefaling, som angiver implementeringsspecifikke anvisninger. n n Der anbefales en række mindstekrav for et rollebaseret adgangskontrolsystem. Disse vil skulle suppleres med en række andre krav i forhold til den enkelte organisations behov Vedrører ikke definition af en metode til identifikation af roller. Diskussionspapir vedr. dette vil senere blive sendt i høring

Anbefalinger n n n Det anbefales, at adgangsrettigheder baseres på roller og regler, således at rettigheder kun behøver at blive administreret for individuelle brugere i situationer, hvor roller og regler ikke kan anvendes. Det anbefales, at der for systemer til administration af rollebaserede rettigheder stilles mindstekrav om, at de skal overholde RBAC-kernens definitioner og krav i RBAC-standarden. Det anbefales, at der ved anskaffelse eller udvikling stilles et mindstekrav om, at it-systemer, hvor det er relevant, skal understøtte rollebaseret adgangskontrol som beskrevet i RBAC-kernen af RBAC-standarden.

RBAC er: § Role Based Access control § En model, der tager udgangspunkt i medarbejderes opgaver, funktioner, kompetencer, ansvar og bemyndigelse § Baseret på brugere, roller, rollehierarkier, relationer og begrænsninger(f. eks. funktionsadskillelse) § Et grundlag for styring af hvem, der kan udføre hvad, hvornår, hvorfra, i hvilken rækkefølge, … § Et over 10 år gammelt koncept. NISTS model er i dag (pr. 2/2004) en ansi standard.

ANSI INCITS 359 -2004 n Del 1: Referencemodel n n n Definerer egenskaber, grundkomponenter og begreber til brug for specifikation af krav og afgrænsning af funktionalitet (ordbog) Fastlægger elementer, mængder og relationer Del 2: Funktionalitets specifikation n Krav til administrative operationer til vedligeholdelse af RBAC elementer. Krav til administrative ”views” Funktioner på systemniveau (f. eks. Egenskaber vedr. dannelse af en brugersession)…

ANSI INCITS 359 -2004 - fortsat n 4 komponentgrupper: n n n Kernefunktionalitet (obligatorisk i alle RBAC impl. ) Hierarkier af roller Statisk funktionsadskillelse Dynamisk funktionsadskillelse/rettighedsstyring 5 Elementtyper: n n n Brugere Roller Rettigheder Operationer Objekter

RBAC-kernen

ANSI INCITS 359 -2004 n Anvendelse: n n n Som framework for leverandører Som basis for at beskrive arkitekturspecifikke API’er Som grundlag for videreudvikling af RBAC systemer og teknologier – tekniske standarder. Som grundlag for kravspecifikationer Begrænsning n n n Sikrer ikke interoperabilitet Sikrer ikke portabilitet Fastlægger kun konceptuelt, hvad RBAC handler om

Slut på RBAC

Rettighedsstyring for eksterne brugere – Diskussion af scenarier Diskuterer behov og udvikling indenfor styring af rettigheder for tværgående brugere

Standarder som anbefales i forbindelse med tværgående brugerstyring n n n LDAP 3. 0 SAML 2. 0 RBAC n WS-Security OCES n Boblere n n n XACML 2. 0 SPML (eller efterfølger)

Høring n n Dokumenterne sendes i 30 dages høring jf. Fællesoffentligt it-standardisering Høring forventes påbegyndt den 19. August 2005

Portal CS CS CS AA AA Aftalt SSO AA

Tværgående SSO kan også lade sig gøre uden tekn. ændringer – kræver blot at CS og AA har en aftale Portal CS CS CS AA AA SSO AA AA AA

Policy Management Provisioning Administration og. Classification styring Federation Trust services Udstedelse af akkreditiver ignature services Personalization Directory services Lagring Directory Integration Meta-Directory Logning og kontrol Validation Autenticitets. Authentication sikring Cryptographic services Authorisation Access Control -Role based Autorisation -Rule based Privacy Services -Purpose based Audit & Logging

Brugerstyring på tværs i offentlige virksomheder/ for steder med offentlig adgang Directory services A Organisation B Access Control -Role based Brugerkatalog -Rule based -Purpose based Brugerkatalog Policy Management Rettighedsstyring Authorisation Processer & Data Privacy Services Processer Rettighedsstyring. Trust services. Rettighedsstyring Personalization Processer & Data Authentication Federation Organisation C Classification Trust services For alle transaktioner i de følgende eksempler gælder At der skal være mulighed for -Sporbarhed -Uafviselighed -Fortrolighed Administration Provisioning Directory services Meta-Directory Integration & Data Bruger Audit & Logging Validation Signature services Cryptographic services

Udkast til konceptuel referencemodel Provisioning Federation Trust services Administration Self service Delegated Policy Management Validation Authorisation Authentication Access Control -Role based -Rule based -Purpose-based (Privacy) -Rights-based (DRM) Directory services Meta-Directory / Directory Integration Personalization Signature services Cryptographic services Classification Audit & Logging

SSO Step 2: The AA redirects any ©p Portal unauthenticated user to the portal with the application identifier for authentication. The portal’s cookie is Step 3: automatically sent User is redirected to the selected CS along by the from the cookie with the application browser identifier. The CS’s authentication cookie is automatically send along by the browser ©c ©p ©c CSn Step 4: The CS reads the cookie, determines the user is already logged in, and redirects the user to the AA with a SAML artifact Step 5: the AA uses the SAML artifact to retrieve user identity and attributes from the CS over SOAP/SSL Step 1: User starts at any AA AAn

Løsninger fra følgende leverandører er i dag certificeret til dette koncept http: //www. cio. gov/eauthentication/documents/Approved. Providers. htm

Opsummering af anbefalinger (2) Det anbefales, at adgangsrettigheder baseres på roller og regler, således at rettigheder kun behøver at blive administreret for individuelle brugere i situationer, hvor roller og regler ikke kan anvendes. Det anbefales, at der for systemer til administration af rollebaserede rettigheder stilles mindstekrav om, at de skal overholde RBAC-kernens definitioner og krav i RBACstandarden. Det anbefales, at der ved anskaffelse eller udvikling stilles et mindstekrav om, at it-systemer, hvor det er relevant, skal understøtte rollebaseret adgangskontrol, som beskrevet i RBAC-kernen af RBAC-standarden.