Adgangsstyring for brugere

Fælleskommunal Adgangsstyring for brugere sikrer, at brugere kun tilgår de informationer og de it-systemer, som de har rettigheder til.
Om Integrationer Vejledninger Metadata FAQ

Central styring af rettigheder

Fælleskommunal Adgangsstyring for brugere foregår ud fra autentifikation og autorisation:

  • Autentifikation: Bestemmer en brugers identitet og tilhørsforhold til en myndighed
  • Autorisation: Bestemmer en brugers rettigheder (hvad brugeren må)

Myndigheder styrer deres brugeres rettigheder ved hjælp af jobfunktionsroller i Fælleskommunalt Administrationsmodul og via deres lokale brugerstyring.

I en jobfunktionsrolle er en brugers rettigheder sammensat af brugersystemroller (hvad brugeren må i it-systemet) og afgrænsninger (hvilke data, brugeren må se og arbejde med). Fx kan en jobfunktionsrolle være et udtryk for rettigheden ”du må læse dokumenter, men kun de dokumenter, der omhandler dagpenge”:

  • Brugersystemrolle: ”Se dokument”
  • Dataafgrænsning: ”KLE 32.30” (KLE-nummer for Dagpenge ved sygdom og barsel)

Context Handler

Adgangsstyring for brugere er teknisk implementeret i form af komponenten Context Handler. 

Context Handler er en SAML IdP-proxy, der udsteder adgang for brugere på vegne af myndigheders Identity Providere (IdP’er) til de it-systemer, der bruger Adgangsstyring for brugere.

Et it-system, der bruger Adgangsstyring for brugere, kaldes i infrastrukturen for brugervendt system.

Et brugervendt system og en IdP integrerer begge til Context Handler. Det betyder, at et brugervendt system ikke kommunikerer direkte med en myndigheds lokale IdP, men at Context Handler fungerer som ”proxy” for myndigheden og oversætter brugeres rettigheder.

Alle kommuners IdP'er er tilsluttet Context Handler, hvilket gør, at en kommunes brugere automatisk kan logge på et it-system, der bruger Adgangsstyring for brugere - hvis brugerne altså er tildelt rettigheder til it-systemet.

Context Handler understøtter OIOSAML 2 og OIOSAML 3, samt NIST- og NSIS-sikringsniveauer.

 

Vilkår for Adgangsstyring for brugere

Et it-system, der bruger Adgangsstyring for brugere, skal overholde vilkår for anvendelse af sikkerhedsmodellen. 

Læs også servicebeskrivelse og vilkår for Context Handler 2.

Du kan desuden læse mere om adgangsstyring i infrastrukturen i beskrivelsen af sikkerhedsmodellen.

Integrationer - Adgangsstyring for brugere

SF1511
Adgangsstyring
Sikkerhed - Hent Token fra Context Handler
Integrationen giver et brugervendt fagsystem mulighed for, at en slutbruger på én gang kan logge ind i alle fagsystemer, som er tilsluttet Context Handler. Herigennem sikrer integrationen, at brugeren har præcis de rettigheder til data og funktionalitet, som han eller hun er blevet tildelt i de respektive systemer. Integrationen er henvendt kommunale, brugervendte fagsystemer, dvs. systemer med en grænseflade for slutbrugere, som vil anvende single-sign-on (SSO). Integrationen indgår således i kommunens opsætning og implementering af den fælleskommunale sikkerhedsmodel for adgangsstyring for brugere.
Læs mere
SF1515
Adgangsstyring
Sikkerhed - SAMLSingleLogout
Integrationen giver mulighed for, at en slutbruger på én gang kan logge ud i alle fagsystemer, som er tilsluttet Context Handler. For et login af en slutbruger via Context Handler henvises til SF1511. Integrationen er henvendt kommunale, brugervendte fagsystemer, dvs. systemer med en grænseflade for slutbrugere, som skal anvende single-sign-on (SSO). Integrationen indgår således i kommunens opsætning og implementering af den fælleskommunale sikkerhedsmodel for adgangsstyring for brugere.
Læs mere

Vejledninger - Adgangsstyring for brugere

Generelle beskrivelser

For it-systemer (brugervendte systemer)

Hvis du skal tilslutte et it-system til Adgangsstyring for brugere, kan du med fordel følge KOMBITs tilslutningsguide.

Du kan også finde hjælp i disse vejledninger og eksempler:

For Identity Providere (IdP'er)

Hvis du skal tilslutte en Identity Provider til Adgangsstyring for brugere, kan du finde hjælp i denne vejledning og eksempel:

For kommuner

 

FAQ - Adgangsstyring for brugere

Context Handler 2 kræver to-faktor autentifikation, når brugere skal logge på it-systemer, der kræver høje sikringsniveauer (NIST 3 eller 4, NSIS ”Betydelig” eller ”Høj”).

Som bruger vil du derfor blive bedt om to-faktor-godkendelse, når du skal logge på et it-system, der kræver et af disse sikringsniveauer.

Det betyder, at du skal være tildelt en mulighed for at autentificere dig med to faktorer/to-trins godkendelse. Det er din kommune, der skal give dig mulighed for at bruge jeres lokale løsning til to-faktor-login.

Særligt for IdP’er registreret med profilen “OIOSAML2 – Without requestet LoA”

Din kommune kan dog have valgt at registrere din kommunes IdP med OIOSAML-profilen OIOSAML2 – Without requestet LoA i Fælleskommunalt Administrationsmodul.

Hvis din kommune har valgt det, vil Context Handler 2 ikke sende et krævet sikringsniveau med til IdP’en. Det er i så fald din kommune, der har ansvaret for, at du og kommunens øvrige brugere er autentificeret på det nødvendige sikringsniveau i jeres IdP. Som bruger vil du derfor ikke nødvendigvis opleve at blive bedt om to-trins-godkendelse, når du logger på et it-system, der kræver NIST 3 eller 4, da din kommune kan have sikret autentifikation på en anden måde.

Din kommune kan have valgt profilen OIOSAML2 – Without requestet LoA for at give softwarerobotter adgang til it-systemer, der kræver NIST-sikring. Du kan læse mere om OIOSAML-profiler og softwarerobotter i denne nyhed.

I Fælleskommunalt Administrationsmodul registreres en OIOSAML-profil for en Identity Provider (IdP). Det er OIOSAML-profilen, der bl.a. ”bestemmer” hvordan et sikringsniveau bliver kommunikeret mellem Context Handler 2 og IdP’en.

Ved hjælp af OIOSAML-profilerne, har kommuner samme muligheder for at lade deres softwarerobotter logge på it-systemer med NIST-sikringsniveauer via Context Handler 2, som de har via Context Handler 1.

Der er seks forskellige OIOSAML-profiler at vælge imellem ved registrering i Administrationsmodulet, heriblandt specifikke profiler beregnet til IdP’er, der ikke kan modtage et NIST-sikringsniveau, og til ADFS-IdP’er, der skal kunne modtage et NSIS-sikringsniveau. Du kan læse mere om udvidelsen af antallet af OIOSAML-profiler i denne nyhed.

Vær opmærksom på, at softwarerobotter (RPA) kun må logge på et it-system via Context Handler 2, hvis systemet kræver NIST-sikringsniveau.

NSIS-standarden understøtter p.t. kun fysiske personer og juridiske enheder, og derfor må en RPA-bruger ikke logge på et it-system, der kræver et NSIS-sikringsniveau. KL og KOMBIT afventer en afklaring fra Digitaliseringsstyrelsen på, hvordan dette skal løses.

Du kan vælge hvilken assertion encryption, dit it-system ønsker at modtage fra Context Handler 2.

Det gør du ved at angive den ønskede krypteringsalgoritme i it-systemets SAML-metadata under ”Encryption certificate” med attributten ”EncryptionMethod Algorithm”. 

Den valgte krypteringsalgoritme vil så fremgå af den SAML-metadata for it-systemet, som du uploader/linker til i registreringen af dit brugervendte system i Fælleskommunalt Administrationsmodul.

Mulige symmetriske ciphers til kryptering:

  • EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"
  • EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc”
  • EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes128-gcm”
  • EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes192-gcm”
  • EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes256-gcm"

Om netværkssikkerhed i infrastrukturen
Du finder oplysninger om hvilke ciphers, der kan benyttes, når dit it-system skal bruge infrastrukturen på denne side i Digitaliseringskataloget.

KOMBIT stiller testværktøjer til rådighed for myndigheder til test af IdP'er. Testværktøjerne giver mulighed for at inspicere login-flowet i en browser i forbindelse med test af Context Handler.

Eksternt testmiljø

Produktionsmiljø

Hvis du som myndighed skal skifte SAML-metadata på din tilsluttede IdP (fx hvis du skal opdatere IdP'ens certifikat), skal du gøre følgende:

  • Planlæg skiftet, så det påvirker din organisations brugere mindst muligt - det er ikke muligt at undgå nedetid
  • Dan nye SAML-metadata i din IdP – bemærk, at SAML-metadatafilen kun må indeholde ét certifikat
  • Slet de gamle IdP SAML-metadata registreret for din IdP i Fælleskommunalt Administrationsmodul
  • Upload nye IdP SAML-metadata for din IdP i Fælleskommunalt Administrationsmodul (bemærk, at AD FS-metadata kan indlæses direkte i Administrationsmodulet uden ændringer, så længe det indeholder ét certifikat)

Herefter vil der gå et kort stykke tid, mens Administrationsmodulet lægger data over i Context Handler. Derefter kan I igen bruge IdP'en til at logge på.

Hvis du har behov for hjælp, kan du kontakte Serviceplatformens Helpdesk.

Du kan også orientere dig i Brugervejledning til Administrationsmodulet for myndigheder.

Digitaliseringsstyrelsen (DIGST) har accepteret NSIS-anmeldelse af Context Handler 2. Det betyder, at Context Handler 2 kan videreformidle NSIS-sikringsniveauerne "Lav", "Betydelig" og "Høj".

Når en kommune gerne vil have deres IdP til at kunne sende NSIS-sikringsniveauer via Context Handler 2, skal kommunen sende en mail til leverandøren af Fælleskommunalt Administrationsmodul (helpdesk@serviceplatformen.dk), hvor kommunen beder om, at der i Administrationsmodulet bliver registreret det NSIS-sikringsniveau, som kommunens IdP er anmeldt til.

Herefter kontrollerer leverandøren af Fælleskommunalt Administrationsmodul om den konkrete IdP er på Digitaliseringsstyrelsens NSIS-positivliste. Hvis IdP’en er på positivlisten, tilpasser leverandøren registreringen i Administrationsmodulet.

På denne side kan du læse mere brugen af certifikater i infrastrukturen, og hente de offentlige nøgler for funktions- og SSL-certifikater for infrastrukturløsningerne: https://digitaliseringskataloget.dk/teknik/certifikater