Page History
| Navitabs | ||||||
|---|---|---|---|---|---|---|
| ||||||
| Table of Contents |
|---|
Introduktion
Formål med dokumentet
Nærværende dokument henvender sig til nuværende og kommende brugere af STS (Secure Token Service).
...
Derudover giver dokumentet et overblik over de af STS understøttede brugsscenarier med udgangspunkt i konkrete eksempler og med links til mere uddybende dokumentation af disse.
Læsevejledning og forudsætninger
Dokumentet henvender sig primært til IT arkitekter, udviklere og forretningskonsulenter med fokus på sikkerhedsinfrastrukturer og applikationssikkerhed i forhold til National Service Platform (NSP).
...
Dokumentet vil løbende linke til ekstern dokumentation, hvor dette er relevant.
Hvad er STS?
STS er i dette dokument synonymt med en konkret NSP service - SOSI STS. Men STS kan også opfattes som et koncept: I denne sammenhæng står STS for Security Token Service (se f.eks. https://en.wikipedia.org/wiki/Security_token_service).
...
Det er vigtigt at forstå, at det alene er service-udbyderens ansvar at foretage adgangsstyring i forhold til den udbudte service og de adgangskritierier, som denne kræver. Beslutning om adgang/ikke-adgang træffes altså udelukkende af service-udbyderen. Grundlaget for denne beslutning er sikkerhedsbilletten og dennes indhold (attributter) og service-udbyderens trust til den udstedende Security Token Service.
STS på National Service Platform (NSP)
Der findes i dag en række forretnings- og støtteservices på NSP. Disse services dækker forskellige formål - fra datadeling via Dokumentdelingsservice (DDS) til logning via MinLog2.
...
- SOSI Idkort (medarbejder og systemadgang til DGWS beskyttede services)
- OIO IDWS billet (borgerbilletter til f.eks. adgang til OIO IDWS beskyttede services)
- OIO SAML billet (medarbejderbillet eller borgerbillet feks. til sikker browseropstart til løsningerne sundhed.dk eller forløbsplaner.dk)
Anvendelse af STS på NSP
Som beskrevet i afsnittet ovenfor, så skal en potentiel anvender til en NSP service først integrere med STS og autentificere sig overfor denne med henblik på at få udstedt en til formålet passende sikkerhedsbillet.
...
De enkelte beskrivelser vil have links til mere detaljeret dokumentation.
Overblik over STS
I diagrammet nedenfor vises et overblik over STS.
...
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
De viste services i figuren udenfor er uddybet i tabellen nedenfor.
| 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 |
| /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 eller SEB |
| 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 |
| /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) |
| eHDSI omveksling | |
| /sts/services/DKNCPBST2EHDSIIdws | Omveksler et eHDSI IDWS XUA Bootstrap token (DKNCPBST) udsted af "Danish National Contact Point" til et eHDSI IDWS XUA Identity Token (IDWS-eHDSI) Bemærk, at den OIO Saml sikkerhedsbillet, der veksles, skal være signeret af troværdig tredjepart |
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.
...
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.
Anvendelseområder
De ovenfor nævnte anvendelsesområder uddybes i følgende afsnit. Hvert område beskrives kort med hensyn til overordnet formål. Dernæst skitseres flowet indenfor det pågældende område. Hver beskrivelse afsluttes med link til uddybende dokumentation.
Anvendelse: DGWS
STS indeholder to services til udstedelse af SOSI Idkort. Det overordnede formål er, at udstede SOSI Idkort der gør det muligt for anvendere at tilgå DGWS services på National Service Platform f.eks. MinSpærring, DRS eller andre Forretningsservices.
...
- Anvendersystemet bygger et SOSI Idkort indeholdende informationer om brugeren/systemet og signerer det med et certifikat (VOCES/FOCES/MOCES certifikat udstedt af CA rodcertifikatet i den fællesoffentlige føderation).
SOSI Idkortet sendes i udstedelsesforespørgsel til STS, der validerer signaturen. Ydermere tjekkes det om certifikatet er spærret (revokeret) for anvendelse.
Korrektheden af attributterne i anvendersystemets SOSI Idkort verificeres af STS. En del af attributterne i SOSI Idkortet vil kunne valideres op i mod det anvendte certifikat. I tilfældet med Bruger Idkort (signeret med MOCES certifikat) vil en del af attributterne være at betragte som claims. Disse attributter valideres på følgende måde (se i øvrigt overblikket over STS ovenfor):
CPR nummer: RID-CPR servicen hos Nets anvendes til at verificere, om et givent CPR nummer hører sammen med et givent RID i det anvendte MOCES certifikat.
Autorisationsnummer: Til dette formål anvendes STS'ens kopi af autorisationsregisteret til at verificere, at det angivne autorisationsnummer hører sammen med det angivne CPR nummer.
- Uddannelseskode: Til dette formål anvendes STS'ens kopi af autorisationsregisteret til at verificere, at den angivne uddannelseskode hører sammen med det angivne CPR nummer.
National rolle: Hvis der er angivet en national rolle, så tjekker STS op i mod sin kopi af stamdata, at den pågældende bruger er i besiddelse af den angivne rolle. Hvis en anvender ikke har angivet en national rolle i claim, men den pågældende medarbejder er i besiddelse af netop én nationale rolle vil denne automatisk inkluderes i det udstedet SOSI Idkort. Der er en whitelist for trustede CVR-organisationer, som selv administrere nationale roller lokalt. For disse trustes den nationale rolle der er claimet - dvs. ingen opslag i stamdata.
- Hvis der kaldes med et MOCES certifikat og CVR validering er slået til, så tjekkes at CVR nummeret findes i konfigurationstabellen whitelistedUserIdCardCvr ellers afvises kaldet.
- STS opbygger et nyt SOSI Idkort med STS opbygger et nyt SOSI Idkort med de samme informationer som det SOSI Idkort, der udgjorde forspørgslen fra anvenderen. Dette Idkort signeres med STS'ens eget certifikat.
- STS sender det nye SOSI Idkort retur til anvendersystemet, der gemmer dette i brugerens/systemets session.
- 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. SOSI STS'ernes certifikater er kendte af alle komponenter i føderationen.
Der henvises til STS - Guide til anvendere: DGWS for yderligere detaljer.
Anvendelse: Medarbejderomveksling
STS indeholder tre services til brug for medarbejderomveksling:
...
Der henvises til STS - Guide til anvendere: Medarbejderomvekslinger for yderligere detaljer.
Anvendelse: Borgeromveksling
Der er to typer af borgeromvekslinger:
...
Der henvises til STS - Guide til anvendere: Borgeromvekslinger for yderligere detaljer.
Anvendelse: eHDSI omveksling
Der findes en enkelt omveksling her:
- Omveksling fra DKNCP Bootstrap token til eHDSI Idws Xua token
Det udstedte eHDSI IDWS XUA token indeholder altid et audience, der angiver, hvordan billetten er tænkt anvendt.
Adgang til STS
Når en anvender skal i gang med at bruge STS på NSP skal følgende være på plads.
...
| 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:
|
| 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:
|
| 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:
|
| DKNCPBST2EHDSIIdws | 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). |
Anvenderen skal være i besiddelse af et OCES certifikat (test- hhv produktionsføderationen) til flere af de ovenstående services.
...