Nedenfor gives korte trin-for-trin opskrifter på, hvorledes
forskellige behov relateret til adgangsstyring og brugeradministration
kan håndteres.
Øvrige ressourcer i gruppen går i dybden med de enkelte trin, så
fokus er her på at formidle et overblik.
B1: Udstilling af en ajourføringsservice
Trin:
- Myndighed og it-leverandør tilsluttes NemLog-in.
- Web service udvikles med tokenbaseret adgangskontrol.
- Web service oprettes i NemLog-in’s administrationsmodul med
angivelse af certifikat og roller.
- Myndighed godkender anmodninger om adgange til web service fra systembrugere.
B2: Kald af en ajourføringsservice
Trin:
- Myndighed og it-leverandør tilsluttes NemLog-in.
- Klient udvikles, så den kan forespørge NemLog-in’s STS om tokens
via WS-Trust protokollen, og så den kan medsende tokens i web
service kald.
- Klient (systembruger) oprettes i NemLog-in’s administrationsmodul.
- Der oprettes en anmodning i NemLog-in om adgang til at kalde den
ønskede ajourføringsservice. Efter denne er godkendt, vil NemLog-in
STS kunne udstede de nødvendige tokens for adgang til servicen.
B3: Administration af kommunale brugeres adgange og føderering af
deres log-in til en web applikation
Trin:
- It-leverandøren indgår en tilslutningsaftale med KOMBIT.
- Applikationen tilsluttes KOMBIT’s fælleskommunale infrastruktur
som et brugervendt system.
- Applikationen integreres med KOMBIT’s Context Handler via SAML 2 protokollen.
- I KOMBIT’s Administrationsmodul defineres applikationens roller og dataafgrænsninger.
- Herefter kan kommuner tildele applikationens roller til deres
medarbejdere, og de vil kunne få adgang til applikationen via et
token udstedt af Context Handler.
B4: Administration og føderering af brugere i en statslig myndighed
Her kan være flere muligheder. Nedenfor beskrives trinene i en model,
hvor brugerne oprettes i myndighedens lokale brugerkatalog (fx AD) og
log-in fødereres til applikationen med single sign-on:
- Der etableres en SAML-baseret Identity Provider i myndighedens
infrastruktur, som er integreret med det lokale brugerkatalog.
- Den brugervendte applikation udvikles med understøttelse af
fødereret log-in via SAML 2 protokollen.
- Applikationen konfigureres til at truste tokens udstedt af
myndighedens IdP.
- Format og indhold af udvekslede tokens aftales – herunder behov
for særlige roller, der kan medsendes for de forskellige typer af medarbejderadgang.
- Myndighedens Identity Provider konfigureres til at danne de
ønskede tokens – fx ved mapning af grupper i det lokale
brugerkatalog til udgående roller i tokens.
B5: Behov for decentral / delegeret brugeradministration for
brugere i private virksomheder
Herunder beskrives en løsningsmodel, hvor brugeradministration sker i
NemLog-in’s brugeradministrationsløsning:
- Myndighed og it-leverandør tilsluttes NemLog-in.
- Applikation udvikles med tokenbaseret adgangskontrol ved
integration med NemLog-in’s Web SSO komponent (via SAML 2 protokollen).
- Applikationens roller defineres i NemLog-in’s administrationsmodul.
- Brugeradministratorer i virksomheder kan herefter tildele deres
medarbejdere de definerede roller. Herefter vil NemLog-in kunne
udstede adgangsgivende tokens til applikationen.
B6: Behov for single sign-on for brugere på tværs af klienter /brugerflader
Dette behov opnås ved at uddelegere log-in til eksterne Identity
Providere, som dækker de ønskede brugertyper som fx.:
- NemLog-in IdP for borgere eller virksomhedsbrugere, som logger på
med NemID eller medarbejdercertifikat (se B5).
- KOMBIT Context Handler for brugere, der er medarbejdere i kommuner
(se B3).
- Lokale Identity Providers for statslige myndigheder (se B4).
B7: Behov for signering af dokumenter i klient
Dette behov kan dækkes af NemLog-in’s signeringstjeneste for brugere
med et privat NemID eller OCES medarbejdersignatur:
- Myndighed og it-leverandør tilsluttes NemLog-in.
- Applikation integreres med NemLog-in’s signeringstjeneste, således
at NemLog-in kan varetage signering, signaturvalidering og
arkivering af signaturbevis.
B8: Udstilling af data via Datafordeleren
(skal udarbejdes)