Page History
...
| Snitflade | Anvendersystem | Bruger | Trust | Modtager |
|---|---|---|---|---|
/sts/services/SecurityTokenService /sts/services/NewSecurityTokenService | Alle som har netværksmæssig adgang | System eller medarbejder | Indgående id-kort skal være signeret af "brugeren selv". | Alle DGWS-services |
| /sts/services/OIOSaml2Sosi | Alle som har netværksmæssig adgang. Hele SOAP besked skal være signeret med et vilkårligt OCES2-certifikat. | Alle medarbejdere | 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 | Alle som har netværksmæssig adgang | Alle medarbejdere | Id-kort skal være signeret af STS (udstedt af /NewSecurityTokenService) | Modtager-system skal være konfigureret (i tabellen iboConfig). |
| /sts/services/Bst2Idws | 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. | Alle borgere | Bootstrap token skal være signeret af trusted part (i test-new-nemLogin-idp.keystore). I praksis NemLog-In | Modtager-system skal være konfigureret (i tabellen audienceConfiguration). |
| /sts/services/JWTIdws | 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. | Alle borgere | 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) |
Java keystores.
Der benyttes et antal java keystores i løsningen. Disse er typisk placerede i folderen /pack/sts Disse beskrives nedenfor.
| /sts/services/JWT2OIOSaml | 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. | Alle borgere | 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) |
Java keystores.
Der benyttes et antal java keystores i løsningen. Disse er typisk placerede i folderen /pack/sts Disse beskrives nedenfor.
| Navn | Kort beskrivelse | Kommentarer |
|---|---|---|
| teststs-1.keystore | STS keystore | Fil baseret keystore der indeholder STS eget certifikat. Benyttes kun i test-miljøer uden LUNA integration |
| testtdc.keystore | Truststore for Digst services. | Truststore i forhold til PID/CVR-RID services. Benyttes i NSP-miljøer ikke fra wildfly, men er opsat i Traffic-manager i stedet. I lokale testmiljøer benyttes den i stedet fra wildfly |
| nsp-test-rid.jks | Keystore i forhold til backend services. | Benyttes til at identificere os (STS) i forhold til backend services som PID, CVR-RID og fuldmagt. Benyttes dels fra Traffic-manager (PID, CVR-RID), dels fra NSP (er opsat via global system-property af hensyn til fuldmagt). |
| test-new-nemLogin-idp.keystore | Truststore til NBO og borger | |
| Navn | Kort beskrivelse | Kommentarer |
| teststs-1.keystore | STS keystore | Fil baseret keystore der indeholder STS eget certifikat. Benyttes kun i test-miljøer uden LUNA integration |
| testtdc.keystore | Truststore for Digst services. | Truststore i forhold til PID/CVR-RID services. Benyttes i NSP-miljøer ikke fra wildfly, men er opsat i Traffic-manager i stedet. I lokale testmiljøer benyttes den i stedet fra wildfly |
| nsp-test-rid.jks | Keystore i forhold til backend services. | Benyttes til at identificere os (STS) i forhold til backend services som PID, CVR-RID og fuldmagt. Benyttes dels fra Traffic-manager (PID, CVR-RID), dels fra NSP (er opsat via global system-property af hensyn til fuldmagt). |
| test-new-nemLogin-idp.keystore | Truststore til NBO og borger billetomveksling | Indeholder de idp'er (primært nemlogin) vi stoler på som udstedere af de billetter vi omveksler. |
| test-jwt-idp-trust.jks | Truststore til JWT billetomveksling | Indeholder de idp'er (primært nemlogin) vi stoler på som udstedere af de billetter vi omveksler. |
| test-jwt-idp-trust.jks | Truststore til JWT billetomveksling | Indeholder de idp'er (primært nemlogin) vi stoler på som udstedere af de billetter vi omveksler. STS-2.STS-2.5.3 |
Konfiguration medarbejder services
...
Omveksling fra Bootstrap token til identitytoken (også tidligere kaldet webapotek løsning) benyttes til at veksle et Bootstraptoken udstedet af NemLog-in på vegne af en borger, til et identitytoken, der kan benyttes til login i FMK-online (og senere formentlig også MinLog2 og Fælles stamkort).
Tilsvarende findes en omveksling fra JSON web token til identity tokens ligeledes målrettet mod borgere.
til et identitytoken, der kan benyttes til login i FMK-online (og senere formentlig også MinLog2 og Fælles stamkort).
Tilsvarende findes en omveksling fra JSON web token til identity tokens ligeledes målrettet mod borgere.
Denne kræver ligeledes konfiguration i databasen, i tabellen sts_audconf.audienceConfiguration. Bemærk at tabellen tidligere har været brugt til andet formål.
Konfigurationen består af et antal indgange på "map-format", audience, attribute, attribute_value. For et givet audience (f.eks. https://fmk) kan der være følgende indgange
| atributeName | Beskrivelse |
|---|---|
| lifetime | Angiver gyldighed af det udstedte token, f.eks. 3600 (s). Tilstedeværelsen af denne "aktiverer" det givne audience |
| certificate.xxx | Angiver ssn for et certifikat der har mulighed for at benytte servicen. Dette certifikat benyttes af anvender til at signere hele beskeden (beskeden har så bl.a. en Assertion, typisk signeret af NemLog-in). Der kan (og vil) være flere certifikater pr. audience, hvilket blot betyder at flere anvendere kan tilgå det. Disse skal blot have forskellige xxx navne. Suffikset er ligegyldigt og tjener alene til støtte for den som kigger på konfigurationen. |
| jwtScope | Aktiverer JWT (Json web token) support for dette audience. Omveksling kan kun foretages hvis det indgående JWT indeholder det pågældende jwtScope. |
Konfiguration i database er altid den gældende — det er ikke nødvendigt at genstarte før ændringer træder i kraft.
Nedenfor beskrives typiske procedurer
Dynamisk konfiguration. Billetomveksling fra JWT til OIOSaml (JWT2OIOSaml)
Omveksling fra JSON web token til OIOSAML token er målrettet borgere. Det kræver en konfiguration i databasen i tabellen sts_audconf.audienceConfigurationDenne kræver ligeledes konfiguration i databasen, i tabellen sts_audconf.audienceConfiguration. Bemærk at tabellen tidligere har været brugt til andet formål.
Konfigurationen består af et antal indgange på "map-format", audience, attribute, attribute_value. For et givet audience (f.eks. httpshttp://fmkforloebsplaner.dk) kan der være følgende indgange
| atributeName | Beskrivelse |
|---|---|
| lifetime | Angiver gyldighed af det udstedte token, f.eks. 3600 (s). Tilstedeværelsen af denne "aktiverer" det givne audience |
| certificate.xxx | Angiver ssn for et certifikat der har mulighed for at benytte servicen. Dette certifikat benyttes af anvender til at signere hele beskeden (beskeden har så bl.a. en Assertion, typisk signeret af NemLog-in). Der kan (og vil) være flere |
| certifikater pr. audience, hvilket blot betyder at flere anvendere kan tilgå det. Disse skal blot have forskellige xxx navne. Suffikset er ligegyldigt og tjener alene til støtte for den som kigger på konfigurationen. | |
| jwtScope | Aktiverer JWT (Json web token) support for dette audience. Omveksling kan kun foretages hvis det indgående JWT indeholder det pågældende jwtScope. |
| publicKey | den offentlige nøgle som anvendes til kryptering af den omvekslede token. Bemærk at indholdet er tilgivende overfor line-breaks og whitespaces, så der kan formateres valgfrit. |
| recipientURL | den URL hvor modtagersystemet kan nåes på. |
| includeBST | om token skal inkluderes i den svarede assertion. (ja/nej) |
Konfiguration i database er altid den gældende — det er ikke nødvendigt at genstarte før ændringer træder i kraft.Nedenfor beskrives typiske procedurer
Konfiguration af trusted, ekstern idp (borger-billetomveksling)
...