Page History
...
| Service | Beskrivelse |
|---|---|
| DGWS | |
| /sts/services/NewSecurityTokenService | Udstedelse af SOSI Idkort (brugeridkort og systemidkort) |
| /sts/services/SecurityTokenService | Legacy udgave af ovennævnte service (uden erstatning af NameId). Benyt NewSecurityTokenService hvis muligt |
| Medarbejderomveksling | |
| /sts/services/Sosi2OIOSaml | Omveksler SOSI brugeridkort til OIO Saml sikkerhedsbillet rettet mod et specifikt audience, f.eks. sundhed.dk. Bemærk, at det SOSI Idkort, der veksles, skal være udstedt af /sts/services/NewSecurityTokenService STS udsteder en billet, der er krypteret og er tænkt anvendt til Sikker Browseropstart (SBO) |
| /sts/services/OIOSaml2Sosi | Omveksler OIO Saml sikkerhedsbillet til SOSI Idkort. Bemærk, at den OIO Saml sikkerhedsbillet, der veksles, skal være signeret af troværdig tredjepart (i praksis NemLog-in) |
| /sts/services/BST2SOSI | Omveksler OIO Saml bootstrap token til SOSI brugeridkort. Bemærk, at bootstrap token skal være signeret af troværdig tredjepart: Lokal IdP, SEB eller NemLog-in |
| Borgeromveksling | |
| /sts/services/Bst2Idws | Omveksler OIO Saml bootstrap token til OIO IDWS sikkerhedsbillet rettet mod et givet audience, f.eks. FMK, Dokumentdelingsservice eller MinSpærring. Bemærk, at bootstrap token skal være signeret af troværdig tredjepart: SEB eller NemLog-in |
| /sts/services/JWT2Idws | Ombytter JSON Web token (JWT) til OIO IDWS sikkerhedsbillet rettet mod et givet audience, f.eks. FMK, Dokumentdelingsservice eller MinSpærring. Bemærk, at JWT tokenet skal være signeret af troværdig tredjepart (pt. en OpenID Connect Provider) |
| /sts/services/JWT2OIOSaml | Omveksler JSON Web token (JWT) til OIO Saml sikkerhedsbillet rettet mod et specifikt audience, f.eks. forløbsplaner.dk Billetten er krypteret og et tiltænkt Sikker Browser Opstart (SBO). Bemærk, at JWT tokenet skal være signeret af troværdig tredjepart (pt. en OpenID Connect Provider) |
Anvendere af STS skal sættes op og tilføjes til STS konfiguration, inden de kan begynde at anvende udstedelses- og omvekslingsservices. Anvendere identificeres vha CVR nummer, som er inkluderet i OCES certifikater. Når en anvender autentificerer sig overfor STS vha et OCES certifikat, så konsulterer STS sin konfiguration og tjekker, om det pågældende CVR nummer er konfigureret, og om det f.eks. har adgang til det specificerede intended audience. De specifikke valideringer og regler gennemgåes i afsnitene nedenfor vedr DGWS, medarbejderomvekslinger og borgeromvekslinger.
Som nævnt i de forgående afsnit, så autentificerer anvendere sig overfor STS ved hjælp af OCES certifikater. Alle OCES-certifikater udstedes af Nets DanID der varetager denne opgave for Digitaliseringsstyrelsen. OCES certifikater kan tilbagekaldes (revokeres), hvis f.eks. den private nøgle bliver kompromiteret. Tilbagekaldte certifikater publiceres på revokeringslister (CRL = Certificate Revocation Lists). Revokeringslisterne hentes løbende og opbevares i en database (CRL database på tegningen). Oplysningerne vedrørende revokering tjekkes i forbindelse med kald af STS udstedelses- eller omvekslingsservices. Således kan revokerede/spærrede certifikater ikke anvendes til at få udstedt/vekslet sikkerhedsbilletter.
STS indeholder synkroniseret data fra følgende registre:
- Autorisationsregisteret: Angiver sammenhæng mellem CPR numre på sundhedspersoner samt disses autorisationsid(er). Muliggør berigelse af sikkerhedsbilletter med autorisationsid for sundhedspersoner.
- Nationale roller: STS synkroniserer med faste intervaller de i SEB administrerede roller. Denne synkronisering muliggør berigelse af sikkerhedsbilletter med nationale roller for medarbejdere (med/uden sundhedsfaglig autorisation)
De enkelte services kan kræve speciel opsætning af STS (f.eks. whitelisting af anvenders CVR nummer). De specifikke krav og opsætninger gennemgåes i afsnitene nedenfor vedr DGWS, medarbejderomvekslinger og borgeromvekslinger.
STS indeholder synkroniseret data fra følgende registre:
- Autorisationsregisteret: Angiver sammenhæng mellem CPR numre på sundhedspersoner samt disses autorisationsid(er). Muliggør berigelse af sikkerhedsbilletter med autorisationsid for sundhedspersoner.
- Nationale roller: STS synkroniserer med faste intervaller de i SEB administrerede roller. Denne synkronisering muliggør berigelse af sikkerhedsbilletter med nationale roller for medarbejdere (med/uden sundhedsfaglig autorisation)
STS har også integration til de tre services PID-CPR, RID-CPR og UUID2CPR udbudt af Nets. Denne integration muliggør verifikation af et påstået (claim) CPR nummers sammenhæng med PID, RID eller UUID. Disse egenskaber er f.eks tilstede i MOCES certifikater og OIO Saml sikkerhedsbilletter udstedt af NemLog-in. Derudover validerer STS anvendte OCES certifikater. Alle OCES-certifikater udstedes af Nets DanID, der varetager denne opgave for Digitaliseringsstyrelsen. OCES certifikater kan tilbagekaldes (revokeres), hvis f.eks. den private nøgle bliver kompromiteret. Tilbagekaldte certifikater publiceres på revokeringslister (CRL = Certificate Revocation Lists). Revokeringslisterne hentes løbende og opbevares i en database (CRL database på tegningen). Oplysningerne vedrørende revokering tjekkes i forbindelse med kald af STS udstedelses- eller omvekslingsservices. Således kan revokerede/spærrede certifikater ikke anvendes til at få udstedt/vekslet sikkerhedsbilletterSTS har også integration til de tre services PID-CPR, RID-CPR og UUID2CPR udbudt af Nets. Denne integration muliggør verifikation af et påstået (claim) CPR nummers sammenhæng med PID, RID eller UUID. Disse egenskaber er f.eks tilstede i MOCES certifikater og OIO Saml sikkerhedsbilletter udstedt af NemLog-in.
Digitaliseringsstyrelsens fuldmagtsregister giver borgere i Danmark mulighed for at tildele fuldmagt til venner og pårørende til at opnå dataadgang. Borgere kan vedligeholde deres fuldmagtstildelinger via portalen http://borger.dk. I forbindelse med borgerbilletter har STS via fuldmagtsregisteret mulighed for at tjekke claims om fuldmagt, som angives i forbindelse med omveksling af borgerbilletter.
...
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Pilene på tegningen viser følgende flow:
- Anvendersystemet er i besiddelse af en OIO SAML billet eller en OIOSAML-baseret bootstraptoken for en given medarbejder (i praksis udstedt af NemLogin, SEB eller andre af SOSI STS trustede lokale IdP'er/udstedere). Denne sendes i en forespørgsel til STS på omvekslingsendpointet. Der kan være brug for at det udstedte SOSI Idkort er beriget med flere oplysninger, end dem, der er til stede i den af NemLogin udstedte OIO SAML billet eller bootstraptoken. Disse specificeres af anvendersystemet i en af dette system defineret SAML billet (i praksis kan denne SAML billet betragtes som en holder for anvendersystemets claims) eller angives som WS Trust claims.
- STS validerer den indgående billet (den grønne i diagrammet) dvs at den udstedte billet ikke er udløbet, at det er udstedt af en troværdig udsteder (i praksis udstedt af NemLogin, SEB eller andre af SOSI STS trustede lokale IdP'er/udstedere) samt at ingen af de anvendte certfikater i forespørgslen er at finde på de publicerede certifikatspærrelister (CRL). De supplerende oplysninger (claims) defineret af den af anvendersystemet udstedte SAML billet eller medstendte WS Trust claims (den røde i diagrammet) valideres af STS på følgende måde:
- Hvis anvendersystemet har definerer et CPR nummer som et claim valideres dette. Det gøres ud fra RID oplysninger i billetten (vha RID-CPR service) hvis de er til stede, ellers ud fra det medsendte medarbejder uuid (vha UUID2CPR service).
- Hvis anvendersystemet ikke har defineret et CPR nummer, slås det op med RID-CPR servicen eller UUID2CPR servicen.
- Hvis anvendersystemet har claimet en national rolle, så valideres denne.
- Hvis BST tokenet har indlejret en liste af nationale roller, valideres i forhold til denne.
- Findes rollen ikke i indlejret liste, valideres i forhold til de registrerede stamdata (roller i SEB-registeret).
- Hvis anvendersystemet har claimet et autorisationsnummer for medarbejderen, så valideres dette op i mod autorisationsregisteret.
- Hvis anvendersystemet hverken har claimet rolle eller autorisation og medarbejderen identificeret i den indkommende billet har netop én autorisation i autorisationsregisteret, vil denne automatisk indsættes i det udstedte SOSI Idkort.
- Hvis anvendersystemet hverken har claimet rolle eller autorisation og medarbejderen har netop én national rolle (i enten indlejret liste eller SEB-registeret) og ingen autorisationer, vil denne rolle automatisk indsættes i det udstedte SOSI Idkort.
- Hvis anvendersystemet har claimet en lokal (ikke national) rolle, så kopieres denne til det udstedte SOSI Idkort uden yderligere validering.
- Hvis forespørgslen er i orden danner STS et SOSI Idkort med oplysninger fra hhv OIO SAML billetten og claims og underskriver dette med sit eget certifikat.
- Det udstedte SOSI Idkort sendes tilbage til anvendersystemet.
- Anvendersystemet anvender det nye SOSI Idkort i forespørgelser mod NSP-komponenter. Bemærk at et SOSI Idkort kan anvendes til flere forespørgelser mod flere forskellige services, så længe det endnu ikke er udløbet.
- NSP-komponenten verificerer at SOSI Idkort er signeret af føderationens certifikat. Den offentlige nøgle for STS'ens certifikat er kendt af alle komponenter i føderationen.
...
Når en anvender skal i gang med at bruge STS på NSP skal følgende være på plads:
- Anvenderen skal være i besiddelse af et OCES certifikat (test- hhv produktionsføderationen).
- Der kan findes test OCES certifikater til at komme i gang med her.
- Anvendere kan desuden kontakte NETS med henblik på at få en tjenesteudbyderaftale, hvilket vil gøre det muligt at få udstedt egne OCES certifikater til både test og produktion.
- Anvenderen skal oprettes som anvender til STS. Dette gøres i praksis ved at rette henvendelse til servicedesk på nspop.dk. Henvendelsen skal indeholde oplysninger om:
- Det certifikat/de certifikater, som anvenderen ønsker at benytte i forbindelse med brugen af STS.
- Angivelse af hvilke (hvis nogen) omvekslingsservices, der ønsker benyttet.
- Ekstra informationer (i forbindelse med de enkelte STS services) inkluderes. Brug tabellen nedenfor.
.
De konkrete krav variere fra service til service. Nedenstående tabel viser de krav, der hører til de konkrete snitflader.
| Service | Skal der konfigureres på NSP STS siden, inden service kan kaldes af anvender? | Særlige tilfælde |
|---|---|---|
| DGWS | Nej | Anvender skal "trustes" af SOSI STS, hvis anvender ønsker at anvende lokalt administrerede nationale roller (forbeholdt offentlige myndigheder). I dette tilfælde skal der oplyses følgende:
|
| Sosi2OIOSaml | Nej | Tjenesteudbydere, der ønsker at udbyde en Sikker Browseropstart snitflade oprettes i SOSI STS. I denne forbindelse skal der oplyses følgende:
|
| OIOSaml2Sosi | Nej | |
| BST2SOSI | Det anvendte OCES certifikat, der benyttes til signering af kaldet, skal whitelistes. I praksis oplyses det anvendte certifikat. Dog foretages den praktiske whitelisting på certifikatets Distinguished Name (der ikke ændres ved certifikatfornyelse). | Nye udstedere af bootstrap tokens (f.eks. lokale IdP'er) skal sættes op i SOSI STS. I dette tilfælde oplyses følgende:
|
Det skal oplyses hvilket audience, der ønskes vekslet til.
Hvis der er tale om et nyt audience, skal der leveres følgende information:
- URL på modtagerapplikation
- Den offentlige nøgle som skal anvendes til kryptering af den omvekslede token
- Om ID-kort/bootstrap token skal inkluderes i den svarede assertion
- Udsteder af bootstraptokens
- Certifikat(er) til signering af bootstraptoken
- Eventuelt anvendt krypteringsnøgle(r) til token
- Det NSP audience, der ønskes veklses til
Hvis det er en ny udsteder, så kræver oprettelsen uddybende information vedr formål, certifkater osv.
|
| ||
| Bst2Idws | Det anvendte OCES certifikat, der benyttes til signering af kaldet, skal whitelistes. I praksis oplyses det anvendte certifikat. Dog foretages den praktiske whitelisting på certifikatets Distinguished Name (der ikke ændres ved certifikatfornyelse). | |
| JWT2Idws | Det anvendte OCES certifikat, der benyttes til signering af kaldet, skal whitelistes. I praksis oplyses det anvendte certifikat. Dog foretages den praktiske whitelisting på certifikatets Distinguished Name (der ikke ændres ved certifikatfornyelse). | Nye udstedere af JWT tokens skal sættes op i SOSI STS. I dette tilfælde oplyses følgende: |
|
Hvis det er en ny udsteder, så kræver oprettelsen uddybende information vedr formål, certifkater osv.
- URL på modtagerapplikation
- Hvilke scopes der inkluderes i JWT token, og hvorledes disse skal mappes til NSP audience
- Den offentlige nøgle som anvendes til kryptering af det omvekslede token
- Om token skal inkluderes i den svarede assertion
- Udsteder af JWT tokens
| ||
| JWT2OIOSaml | Det anvendte OCES certifikat, der benyttes til signering af kaldet, skal whitelistes. I praksis oplyses det anvendte certifikat. Dog foretages den praktiske whitelisting på certifikatets Distinguished Name (der ikke ændres ved certifikatfornyelse). | Tjenesteudbydere, der ønsker at udbyde en Sikker Browseropstart snitflade oprettes i SOSI STS. I denne forbindelse skal der oplyses følgende:
|
Anvenderen skal være i besiddelse af et OCES certifikat (test- hhv produktionsføderationen) til flere af de ovenstående services.
Der kan findes test OCES certifikater til at komme i gang med her.
Anvendere kan desuden kontakte NETS med henblik på at få en tjenesteudbyderaftale, hvilket vil gøre det muligt at få udstedt egne OCES certifikater til både test og produktion. Se feks. https://www.nets.eu/dk-da/kundeservice/nemid-tjenesteudbyder/implementering/Pages/adgang-til-testsystem.aspx
For de services, hvor anvenderen skal konfigureres i SOSI STS (feks whitelisting), skal der rettes henvendelse til servicedesk på nspop.dk.
Henvendelsen skal indeholde oplysninger om:
- Den service, der ønskes anvendt
- De informationer, der skal konfigureres. Brug tabellen ovenfor.