Page History
...
- 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 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: 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.
...