Page History
...
ArchiMate-diagram 1. Klik på kasserne for at læse mere.
Adgang til NSP-komponenters services er begrænset med autentificering. Denne autentifikation er baseret på OCES-certifikater, hvormed anvendere er i stand til at identificere sig. Det betyder dog ikke at alle services skal validere alle anvenderes certifikater og tilhørende information. Dette vil være et stort ansvar at fordele på så mange komponenter. Derfor er STS en fælles komponent, som kan udstede adgangsgivende billetter, som kun kræver simpel verifikation i NSP-komponenterne.
Dette betyder at en anvender udelukkende skal identificere sig overfor STS med sit OCES-certifikat og får herefter et id-kort, der er underskrevet med (STS) føderationens certifikat. Dette id-kort agerer som nøglen, der identificerer anvenderen, og kan give adgang til de andre komponenter på NSP. Komponenternes ansvar er derfor kun at kende til STS'ens ene certifikat og verificere dette i id-kortet. STS verificerer og beriger desuden id-kortet med en række af attributter. F.eks. verificeres slutbrugerens personnummer og dennes autorisation.
STS kræver ingen whitelisting og ingen specifikke WSDL'er eksisterer for STS'ens services.
| HTML |
|---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/24e0d66c.html" name="test" height="950" width="800">You need a Frames Capable browser to view this content.</iframe> |
ArchiMate-diagram 2. Klik på kasserne for at læse mere.
STS består af en række del-komponenter (eller services), som konfigureres via Spring-frameworket. Komponenterne indkapsler følgende funktionalitet:
- Crl: Spærreliste kontrol af OCES certifikater
- Acl: Check for adgang til udstedelse ID-kort (benyttes ikke pt)
- Cpr: CPR opslag ud fra OCES-medarbejdercertifikat eller borgercertifikat
- Authorization: Verifikation af autorisation id ud fra CPR Fuldmagt og den fællesoffentlige fuldmagtsløsning.
En væsentlig komponent for STS er SOSI Seal biblioteket, der indtager en central rolle i forbindelse med udstedelse af ID-kortet. Seal anvendes som et tredjeparts bibliotek af STS.
Figur 1: Komponenter anvendt af STS (ikke udtømmende liste)
Oversigt over snitflader og adgang
Følgende er en oversigt over STS snitflader og kravene til adgang til disse:
- NewSecurityTokenService -- Udstedelse af STS-signeret id-kort. Erstatter samtidig NameId til et kanonisk format (nødvendigt hvis id-kortet skal veksles til OIOSaml). SOSI Seal biblioteket benyttes af STS til serialisering/deserialisering af web service kaldet samt signering af udstedte ID-kort.
- SecurityTokenService -- Legacy udgave af ovennævnte service (uden erstatning af NameId). Benyt NewSecurityTokenService hvis muligt.
- Sosi2OIOSaml -- Ombytter STS-signeret id-kort fra SOSI ID-kort til OIOSAML assertion (NemLogin token) rettet mod et specifikt audience, f.eks. sundhed.dk. Bemærk at dette id-kort skal være udstedt af NewSecurityTokenService.
- OIOSaml2Sosi -- Ombytter OIOSaml (nem-login) token til signeret id-kort. Token skal være signeret af troværdig tredjepart (nemlogin).
- Bst2Idws -- Ombytter OIOSaml bootstrap token til signeret identitytoken rettet mod et givet audience, f.eks. FMK. Token skal være signeret af troværdig tredjepart (nem-login).
- JWT2Idws -- Ombytter JSON Web token til signeret identity-token rettet mod et givet audience, f.eks. FMK. Token skal være signeret af troværdig tredjepart (pt. en OID connector).
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Figur 2: STS-afhængigheder og eksterne snitflader
STS består af en række del-komponenter (eller services), som konfigureres via Spring-frameworket. Komponenterne indkapsler følgende funktionalitet:
- Crl: Spærreliste kontrol af OCES certifikater
- Acl: Check for adgang til udstedelse ID-kort (benyttes ikke pt)
- Cpr: CPR opslag ud fra OCES-medarbejdercertifikat eller borgercertifikat
- Authorization: Verifikation af autorisation id ud fra CPR Fuldmagt og den fællesoffentlige fuldmagtsløsning.
En væsentlig komponent for STS er SOSI Seal biblioteket, der indtager en central rolle i forbindelse med udstedelse af ID-kortet. Seal anvendes som et tredjeparts bibliotek af STS.
Figur 1: Komponenter anvendt af STS (ikke udtømmende liste)
Adgang til NSP-komponenters services er begrænset med autentificering. Denne autentifikation er baseret på OCES-certifikater, hvormed anvendere er i stand til at identificere sig. Det betyder dog ikke at alle services skal validere alle anvenderes certifikater og tilhørende information. Dette vil være et stort ansvar at fordele på så mange komponenter. Derfor er STS en fælles komponent, som kan udstede adgangsgivende billetter, som kun kræver simpel verifikation i NSP-komponenterne.
Dette betyder at en anvender udelukkende skal identificere sig overfor STS med sit OCES-certifikat og får herefter et id-kort, der er underskrevet med (STS) føderationens certifikat. Dette id-kort agerer som nøglen, der identificerer anvenderen, og kan give adgang til de andre komponenter på NSP. Komponenternes ansvar er derfor kun at kende til STS'ens ene certifikat og verificere dette i id-kortet. STS verificerer og beriger desuden id-kortet med en række af attributter. F.eks. verificeres slutbrugerens personnummer og dennes autorisation.
STS kræver ingen whitelisting og ingen specifikke WSDL'er eksisterer for STS'ens services.
Oversigt over snitflader og adgang
STS afhænger af en række eksterne komponenter i forbindelse med udstedelse af og omveksling af billetter. Afhængigheder i parantes anvendes kun i visse scenarier:
| Afhængighed | Beskrivelse | SecurityTokenService | OIOSaml2Sosi | Sosi2OIOSaml | Bs2Idws | BST2SOSI |
|---|---|---|---|---|---|---|
| CRA | Spærrelister tilgængelige på NSP platformen | X | X | X | X | X |
| Krydscertifikater | Hentes via HTTP fra internettet | X | X | X | X | X |
| STS database | Konfiguration og lokal cache af CPR | X | X | X | X | X |
| STS keystore | Indeholder certifikat og nøgler for føderationen, samt trustede 3. parter der kan foretages billetomveksling fra | X | X | X | X | X |
| Autorisationer | Indlæses fra autorisationsregister | X | X | X | ||
| Nationale roller (SEB) | X | X | X | |||
| RID2CPR | Verifikation af medarbejderes CPR nr. Hentes fra internet fra central traffic manager | (X) | (X) | (X) | ||
| UUID2CPR | Verifikation af medarbejderes CPR nr. Hentes fra internet fra central traffic manager | (X) | ||||
| PID2CPR | Verifikation af borgeres CPR nr. Hentes fra internet fra central traffic manager | X | ||||
| Fuldmagtsservice | Verifikation om fuldmagt til at agere på vegne af anden borger | (X) |
| HTML |
|---|
<iframe src="https://archi.nspop.dk/NSP/570928ca/views/24e0d66c.html" name="test" height="950" width="800">You need a Frames Capable browser to view this content.</iframe> |
ArchiMate-diagram 2. Klik på kasserne for at læse mere.
Komponentinteraktion id-kort udstedelse
Komponenterne anvendes f.eks. af STS ved udstedelsen af ID-kort. Sekvensdiagrammet i Figur 3 viser et typisk forløb med anvendelse af komponenterne, som STS gennemløber i forbindelse med udstedelse af MOCES signeret ID-kort, hvor resultatet er en succesfuld udstedelse af et STS signeret ID-kort.
Figur 3: STS-udstedelse af MOCES signeret ID-kort
Andre scenarier gennemløber en delmængde af de komponentinteraktioner der er illustreret i figuren. Således består udstedelsen
af skridtene:
- Deserialisering web service request og verifikation af signatur
- Check af ID-kort, f.eks. version og autentifikationsniveau
- Spærrelistecheck af signerende og STS-certifikat
- Check af certifikat til CPR-tilknytning
- Check af autorisation knyttet til CPR
- Signering af ID-kort med STS-certifikat
- Serialisering af web service response
Skridt 5 og 6 foretages kun, såfremt ID-kortet er signeret med et MOCES-certifikat. Alle verifikationsskridtene kan afbryde forløbet, hvilket resulterer i, at et fejlsvar med passende information returneres til kalderen.
Diagrammerne nedenfor viser nærmere detaljer angpende henholdsvis validering af signatur, samt medarbejder validering
Figur 4: Validering af XML signatur
Figur 5: Validering af medarbejder information
Komponent interaktion omveksling fra OIOSaml assertion til id-kort
Snitflader
| Begreb | Forklaring |
|---|---|
| Anvendersystem | Det IT-system som anvender en STS snitflade |
| Bruger | Den bruger som via et klient IT-system anvender STS |
| Trust | Hvem stoler vi på som signerende part på en indgående billet. |
| Modtager | Hvilke systemer kan anvende den billet der udstedes af STS. |
/sts/services/SecurityTokenService
/sts/services/NewSecurityTokenService
Input: Selvsigneret id-kort
Output: STS signeret id-kort
Alle som har netværksmæssig adgang.
Dele af SOAP besked skal være signeret med system-certifikat
Input: OIO-Saml assertion (NemLogin)
Output: STS signeret id-kort
OIOSaml assertion skal være signeret af trusted part (i test-new-nemLogin-idp.keystore).
I praksis NemLog-In
Alle som har netværksmæssig adgang
Dele af SOAP besked kan være signeret med system-certifikat (verificeres ikke pga DCC/Gateway)
Input: STS signeret id-kort
Output: OIO-Saml assertion
Modtager-system skal være konfigureret (i tabellen iboConfig).
Input: OIO-Saml bootstrap token
Output: STS signeret id-kort
Bootstrap token skal være signeret af trusted part.
Lokal IdP, SEB eller NemLog-in
| Snitflade | Snitflade | Anvendersystem | Bruger | Tokens | Trust | Modtager |
|---|---|---|---|---|---|---|
/sts/services/SecurityTokenService /sts/services/NewSecurityTokenService | WS-Trust 1.2 (DGWS) | Alle som har netværksmæssig adgang | System eller medarbejder | Input: Selvsigneret id-kort Output: STS signeret id-kort | Indgående id-kort skal være signeret af "brugeren selv". |
| Alle DGWS-services |
| /sts/services/ |
| OIOSaml2Sosi | WS-Trust 1.4 (OIO-IDWS 1.0) |
Alle som har netværksmæssig adgang. Dele af SOAP besked skal være signeret med |
system-certifikat | Alle medarbejdere | Input: OIO-Saml |
assertion (NemLogin) Output: |
STS signeret id-kort | OIOSaml assertion skal være signeret af trusted part (i test-new-nemLogin-idp.keystore). I praksis NemLog-In |
| Alle DGWS-services |
| /sts/services/ |
| Sosi2OIOSaml | WS-Trust 1.4 (OIO-IDWS 1.0) |
Alle som har netværksmæssig adgang Dele af SOAP besked |
kan være signeret med |
system-certifikat (verificeres ikke pga DCC/Gateway) | Alle medarbejdere | Input: |
STS signeret id-kort Output: |
OIO-Saml assertion | Id-kort skal være signeret af |
| STS (udstedt af /NewSecurityTokenService) | Modtager-system skal være konfigureret (i tabellen |
iboConfig). |
JWT suport skal være aktiveret (i tabellen audienceConfiguration)
| /sts/services/ |
| BST2SOSI | WS-Trust 1.4 (OIO-IDWS 1.0) |
Offentlig nøgle for anvender-system skal være WL (i tabellen audienceConfiguration).
Dele af SOAP besked skal være signeret med denne nøgle.
Input: JWTsigneretafOpenId connector
Output: OIO-Saml assertion
| Alle som har netværksmæssig adgang | Alle medarbejdere | Input: OIO-Saml bootstrap token Output: STS signeret id-kort | Bootstrap token skal være signeret af trusted part |
. Lokal IdP, SEB eller NemLog-in | Alle DGWS-services | |
| /sts/services/Bst2Idws | WS-Trust 1.4 (OIO-IDWS 1.0) | Offentlig nøgle for anvender-system skal være WL |
Issuer skal være konfigureret i services.xml
Modtager-system skal være konfigureret(i tabellen audienceConfiguration). |
JWT suport skal være aktiveret (i tabellen audienceConfiguration)
Afhængigheder
STS’en afhænger af en række eksterne komponenter i forbindelse med udstedelse af og omveksling af billetter. Afhængigheder i parantes anvendes kun i visse scenarier:
...
Dele af SOAP besked skal være signeret med denne nøgle. | Alleborgere | Input: OIO-Saml bootstrap token Output: IDWS (1.0) token. | Bootstrap token skal være signeret af trusted part. I praksis NemLog-In eller SEB | Modtager-system skal være konfigureret (i tabellen audienceConfiguration). | ||
| /sts/services/JWTIdws | WS-Trust 1.4 (OIO-IDWS 1.0) | Offentlig nøgle for anvender-system skal være WL (i tabellen audienceConfiguration). Dele af SOAP besked skal være signeret med denne nøgle. | Alleborgere | Input: JWTsigneretafOpenId connector Output: IDWS (1.0) token. | JWT skal være signeret af trusted part (i test-jwt-idp-trust.jks). kid skal pege på det rigtige alias i denne. Issuer skal være konfigureret i services.xml | Modtager-system skal være konfigureret (i tabellen audienceConfiguration). JWT suport skal være aktiveret (i tabellen audienceConfiguration) |
| /sts/services/JWT2OIOSaml | WS-Trust 1.4 (OIO-IDWS 1.0) | Offentlig nøgle for anvender-system skal være WL (i tabellen audienceConfiguration). Dele af SOAP besked skal være signeret med denne nøgle. | Alleborgere | Input: JWTsigneretafOpenId connector Output: OIO-Saml assertion | JWT skal være signeret af trusted part (i test-jwt-idp-trust.jks). kid skal pege på det rigtige alias i denne. Issuer skal være konfigureret i services.xml | Modtager-system skal være konfigureret (i tabellen audienceConfiguration). JWT suport skal være aktiveret (i tabellen audienceConfiguration) |
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Figur 2: STS-afhængigheder og eksterne snitflader
- NewSecurityTokenService -- Udstedelse af STS-signeret id-kort. Erstatter samtidig NameId til et kanonisk format (nødvendigt hvis id-kortet skal veksles til OIOSaml). SOSI Seal biblioteket benyttes af STS til serialisering/deserialisering af web service kaldet samt signering af udstedte ID-kort.
- SecurityTokenService -- Legacy udgave af ovennævnte service (uden erstatning af NameId). Benyt NewSecurityTokenService hvis muligt.
- Sosi2OIOSaml -- Ombytter STS-signeret id-kort fra SOSI ID-kort til OIOSAML assertion (NemLogin token) rettet mod et specifikt audience, f.eks. sundhed.dk. Bemærk at dette id-kort skal være udstedt af NewSecurityTokenService.
- OIOSaml2Sosi -- Ombytter OIOSaml (nem-login) token til signeret id-kort. Token skal være signeret af troværdig tredjepart (nemlogin).
- Bst2Idws -- Ombytter OIOSaml bootstrap token til signeret identitytoken rettet mod et givet audience, f.eks. FMK. Token skal være signeret af troværdig tredjepart (nem-login).
- JWT2Idws -- Ombytter JSON Web token til signeret identity-token rettet mod et givet audience, f.eks. FMK. Token skal være signeret af troværdig tredjepart (pt. en OID connector).
...
Komponentinteraktion id-kort udstedelse
Komponenterne anvendes f.eks. af STS ved udstedelsen af ID-kort. Sekvensdiagrammet i Figur 3 viser et typisk forløb med anvendelse af komponenterne, som STS gennemløber i forbindelse med udstedelse af MOCES signeret ID-kort, hvor resultatet er en succesfuld udstedelse af et STS signeret ID-kort.
Figur 3: STS-udstedelse af MOCES signeret ID-kort
Andre scenarier gennemløber en delmængde af de komponentinteraktioner der er illustreret i figuren. Således består udstedelsen
af skridtene:
- Deserialisering web service request og verifikation af signatur
- Check af ID-kort, f.eks. version og autentifikationsniveau
- Spærrelistecheck af signerende og STS-certifikat
- Check af certifikat til CPR-tilknytning
- Check af autorisation knyttet til CPR
- Signering af ID-kort med STS-certifikat
- Serialisering af web service response
Skridt 5 og 6 foretages kun, såfremt ID-kortet er signeret med et MOCES-certifikat. Alle verifikationsskridtene kan afbryde forløbet, hvilket resulterer i, at et fejlsvar med passende information returneres til kalderen.
Diagrammerne nedenfor viser nærmere detaljer angpende henholdsvis validering af signatur, samt medarbejder validering
Figur 4: Validering af XML signatur
Figur 5: Validering af medarbejder information
Komponent interaktion omveksling fra OIOSaml assertion til id-kort
...
Komponentsnitflader
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...