Page History
...
| Snitflade | Anvendersystem | Bruger | Modtager |
|---|---|---|---|
| DGWS | |||
/sts/services/SecurityTokenService /sts/services/NewSecurityTokenService | Alle som har netværksmæssig adgang | System eller medarbejder | Alle DGWS-services |
| Medarbejderomveksling | |||
| /sts/services/Sosi2OIOSaml | Alle som har netværksmæssig adgang | Alle medarbejdere | Modtager-system skal være konfigureret (i tabellen iboConfig). |
| /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 | Alle DGWS-services |
| /sts/services/BST2SOSI | Alle som har netværksmæssig adgang **CHG: anvender-system skal whitelistes** | Alle medarbejdere | Alle DGWS-services |
| Borgeromveksling | |||
| /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 | 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 | Modtager-system skal være konfigureret (i tabellen audienceConfiguration). JWT suport skal være aktiveret (i tabellen audienceConfiguration) |
| /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 | Modtager-system skal være konfigureret (i tabellen audienceConfiguration). JWT suport skal være aktiveret (i tabellen audienceConfiguration) |
...
Der benyttes et antal java keystores i løsningen. Disse er typisk placerede i folderen /pack/sts Disse beskrives nedenfor.
Navn **CHG: Noget nisvisende navngivning ('TDC', 'RID' og 'new-nemLogin') - bør det ikke rettes ved lejlighed  ? ** | 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. STS-2.5.3 |
...
Fra sts 2.5.3 indgår monitorering af certifikaterne i monitorerings URL'en /sts/checkstatus.
Tilføjelse af trust til ny, ekstern idp: **CHG: Til hvilke snitflader hører den trust? OIOSAML2SOSI, BST2IDWS og/eller BST2SOSI? **
- Modtag offentlig nøgle fra den eksterne part.
- Verificer at nøglen tilhører det rigtige miljø (test vs produktion) - og er et gyldigt FOCES certifikat
- Indsæt nøglen under et vilkårligt alias i test-new-nemLogin-idp.keystore
- Ændringen kræver genstart af STS (eller wildfly).
...
- Tilføj det nye certifikat ifølge proceduren for oprettelse af ny idp - så både gammelt og nyt certifikat eksisterer samtidig.
- Når det gamle certifikat ikke bruges mere kan dette efterfølgende fjernes ved førstkommende lejlighed.
Konfiguration
...
af test-jwt-idp-trust.jks **CHG: Til hvilke snitflader hører den trust? JWT2IDWS og/eller JWT2OIOSAML? **
Konfigurationen findes i et java keystore (pt. placeret som /pack/sts/test-jwt-idp-trust.jks ). Dette indeholder de certifikater vi stoler på.
...
Der er strikse krav til hvilke alias'er disse certifikater befinder sig under. **CHG: Hvillke? Uddyb eller referer til beskrivelse **
Der er i første omgang opsat trust af et par certifikater til interne testformål. Det enkelte certifikat valideres i forbindelse med at det forsøges anvendt.
...
| Snitflade | Trust og konfiguration |
|---|---|
| DGWS | |
/sts/services/SecurityTokenService /sts/services/NewSecurityTokenService |
|
...
| Felt | Beskrivelse | Påkrævet |
|---|---|---|
| cvr | CVR nummre for af anvender. | Ja |
| endpoint | Den service, der whitelistes. | Ja |
Opsætning af nyt anvendersystem
| , der whitelistes. | Ja |
Opsætning af nyt anvendersystem **CHG: Er det her ikke det samme som beskrevet i afsnit 6.5.1?? Benyttes sts_audconf.trustedCvr tabellen til whitelisting af anvendere eller til at konfigurere trust ift. nationale roller?**
Før at et nyt anvendersystem kan bruge DGWS snitfladerne skal det tilhørende CVR nummer whitelistes i STS.
...
Gyldige attributter i tabellen er:
| atributeattribute | Beskrivelse |
|---|---|
| encryptionKey.xxx | Eventuel anvendt krypteringsnøgle til token (en issuer kan have flere krypteringsnøgler med forskellige xxx navne). Suffikset Suffikset er ligegyldigt og tjener alene til støtte for den som kigger på konfigurationen.på konfigurationen. **CHG: Kryptering er her baseret på OCES certifikater og dermed asymetrisk. STS'en skal kunne konfigureres med et nøglepar, hvoraf public key udleveres til anvenderen (som bruger det til kryptering) og STS beholder private key (og benytter det til at dekryptere). Hvad bliver encryptionKey.xxx sat til her??? ** |
| tokenProfile | Anvendt tokenprofil. OIOH3BST (lokal IdP udstedt), OIOH2BST (SEB udstedt) eller OIO3BST (NemLog-in3 STS udstedt). |
| validateHOK | Angivelse af om holder-of-key (HoK) validering af requests skal udføres (true, false) |
| certificate.xxx | Angiver SubjectSerialNumber (ssn) for et certifikat der har mulighed for at benytte servicen. Dette certifikat benyttes af anvender til at signere hele beskeden. Sættes issuer til "*" vil certifikatet være gyldigt for alle issuers. Der kan være flere certifikater pr. issuer, 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. Bemærk: Benyttes kun hvis whitelist-checks er slået til (property whitelistValidation) |
| signingKey.xxx | Nøgle til trusted certifikat til signering af BST tokenet **CHG: Uklar tekst: 'Nøglen' her er public key og der jo ikke 'til signering' af BST tokenet. **(en issuer kan have flere trusted certifikater med forskellige forskellige xxx navne). |
Tilføjelse af ny anvender
...
Omveksling fra Bootstrap token til identitytoken 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 **CHG: Nej, men FMK har en IDWS borgersnitflade ** og til borgersnitflader (IDWS snitflader) udbudt af f.eks. MinLog2, MinSpærring og Dokumentdelingsservicen.
...
| atribute | Beskrivelse |
|---|---|
| encryptionKey.xxx | Eventuel anvendt krypteringsnøgle til token (en issuer kan have flere krypteringsnøgler med forskellige xxx navne). Suffikset Suffikset er ligegyldigt og tjener alene til støtte for den som kigger på konfigurationen. **CHG: Se kommentar i ovenstående vedrørende kryptering ** |
| tokenProfile | Anvendt tokenprofil. OIO2BST_CITIZEN (SEB udstedt), OIO3BST_CITIZEN (NemLog-in3 STS udstedt) eller OIO2BST_LEGACY (NemLog-in2 udstedt). |
| signingKey.xxx | Angiver trusted certifikater til signering af BST tokenet (en issuer kan have flere trusted certifikater med forskellige xxx navne). |
| audience | Angiver gyldigt audience for dette token. |
...
Der findes pt. i produktion kun et audience (https://fmk). Herudover ) **CHG: Der er vel flere nu? **. Herudover yderligere et antal audiences i test, til interne eller eksterne testformål.
...
Såfremt der er tale om en simpel fornyelse hos anvender systemet, hvor CVR-FID **CHG: Er det ikke SubjectSerialNumber der anvendes til whitelsting? Som er CVR-FID for nuværende FOCES2 - men i OCES3 er det på formen UI:DK-<identity type acronym>:<persistence level acronym>:<uuid>, se https://www.ca1.gov.dk/media/qalf3dnl/80-nl3-certificate-profiles-v1-0-5.pdf ** ikke ændres, skal der ikke foretages noget.
...