Page History
...
| Snitflade | Anvendersystem | Bruger | Trust | Modtager | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| DGWS | ||||||||||
/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 | ||||||
| Medarbejderomveksling | ||||||||||
| /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/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/ | Sosi2OIOSamlBST2SOSI | Alle som har netværksmæssig adgang | Alle medarbejdere | Id-kortBootstrap token skal være signeret af | STS (udstedt af /NewSecurityTokenService)Modtager-system skal være konfigureret (i tabellen iboConfig). | /sts/services/BST2SOSI | Alle som har netværksmæssig adgang | Alle medarbejdere | Bootstrap token skal være signeret af trusted part (konfigureret i database tabellen ststrusted part (konfigureret i database tabellen sts_audconf.trustedIdpConfiguration). Lokal IdP, SEB eller NemLog-in | 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 | Bootstrap token skal være signeret af trusted part (konfigureret i database tabellen sts_audconf.trustedIdpCitizenConfiguration). I praksis NemLog-In eller SEB | 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) | ||||||
| /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 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 |
Konfiguration
...
af medarbejderomvekslinger
Udover
...
Ud over statisk konfiguration, som er beskrevet i installationsvejledning, så findes der desuden følgende områder som kan konfigureres dynamisk
Dynamisk konfiguration. Billetomveksling fra ID-kort til OIOSaml assertion.
.
Sosi2OIOSaml
For hvert audience, skal følgende konfigureres i databasen i Omveksling fra ID-kort til OIOSaml assertions kræver konfiguration gemt i databasen i tabellen sts_audconf.iboConfig; disse er:
| Felt | Beskrivelse | Påkrævet |
|---|---|---|
| audience | identifikation af modtagersystemet som en URI, der skal være på normalform jvf. tidligere afsnit | Ja |
| 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. | Ja |
| recipientURL | den URL hvor modtagersystemet kan nåes på. | Ja |
| includeBST | om ID-kort/bootstrap token skal inkluderes i den svarede assertion. (ja/nej) | Ja |
| deliveryNotOnOrAfterOffset | offset i tid fra omvekslingstidspunkt, der bruges til opsætning af gyldighed af udstede assertion. | Ja |
| notBeforeOffset | offset i tid fra omvekslingstidspunkt, der bruges til opsætning af gyldighed af udstede assertion. | Ja |
| notOnOrAfterOffset | offset i tid fra omvekslingstidspunkt, der bruges til opsætning af gyldighed af udstede assertion. | Ja |
| idCardMaxAgeMins | maksimal alder på id-kortet | Nej (default er 1440 min) |
Konfiguration i database er altid den gældende — det er ikke nødvendigt at genstarte før ændringer træder i kraft.
...
Tilføjelse af ny anvender
Ovenstående tabel skal kun opdateres hvis servicen skal benyttes for et audience, der ikke allerede er konfigureret. I så fald, tilføjes en ny række i tabellen for det nye audience.
OIOSaml2Sosi
Denne konfiguration er i spil ved "NBO" billetomveksling, dvs fra en NemLog-In billet udstedt til en medarbejder, til et medarbejder id-kort
...
Fra sts 2.5.3 indgår monitorering af certifikaterne i monitorerings URL'en /sts/checkstatus.
Tilføjelse af
...
ny anvender
Trust til ny, ekstern idp
...
:
- 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
(evt) For visse idp'er (nemlogin) stoler vi på det cpr-nummer de medsender i stedet for at validere dette. Dette er opsat i filen /pack/wildfly8/standalone/configuration/services.xml (neenstående nedenstående viser aktuel indstilling for produktion):
Code Block <property name="cprTrustCertificates"> <list> <value>CVR:34051178-UID:77371184</value> <!-- nemlogin prod --> </list> </property>- Æ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.
...
BST2SOSI
Omveksling fra BST token til SOSI id-kort kræver konfiguration gemt i databasen i tabellen sts_audconf.trustedIdpConfiguration:
...
| atribute | Beskrivelse |
|---|---|
| encryptionKey.xxx | Eventuel anvendt krypteringsnøgle til token (en issuer kan have flere krypteringsnøgler med forskellige xxx navne). Suffikset er ligegyldigt og tjener alene til støtte for den som kigger på konfigurationen. |
| tokenProfile | Anvendt tokenprofil (OIOH3BST. 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 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. |
| signingKey.xxx | Angiver Nøgle til trusted certifikater certifikat til signering af BST tokenet (en issuer kan have flere trusted certifikater med forskellige xxx navne). |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<property name="whitelistValidation" value="false" /> |
...
Tilføjelse af ny anvender
Er der tale om en ny issuer, skal der tilføjes rækker til ovenfor nævnte tabel for hver attribut.
Nationale roller
Ved udstedelse af id-kort, enten på baggrund af selv-signeret id-kort eller ved omveksling af NemLog-in token, er det muligt at anvende nationale roller. De gyldige roller opsættes i tabellen sts_audconf.roleDefinitions.
...
| Code Block | ||
|---|---|---|
| ||
use sts_audconf;
insert into roleDefinitions (source, externalName, code, value) values ('NationalFederation', 'nspPlejeAssR3', '41003', 'PlejeAssR3'); |
...
Trust af nationale roller
...
Nationale roller som beskrevet ovenfor valideres som udgangspunkt mod de roller der fremfindes i SEB. Det er dog muligt at tillade enkelte udvalgte cvr-numre (f.eks. regioner) at angive roller i id-kortet uden at få disse valideret via SEB. Dette styres via tabellen sts_audconf.trustedCvr.
...
Af sikkerhedsmæssige årsager anbefales funktionaliteten pt kun benyttes for 'STS'.
Borger billetomveksling
Dynamisk konfiguration. Billetomveksling fra Bootstraptoken eller JWT til identitytoken (Bst2Idws / JWT2Idws)
Konfiguration af borgeromvekslinger
Bst2Idws
Omveksling fra Bootstrap 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.
Denne kræver ligeledes konfiguration i databasen, i tabellen Database tabellen sts_audconf.audienceConfiguration. Bemærk at tabellen tidligere har været brugt til andet formål.trustedIdpCitizenConfiguration benyttes til konfiguration for input bootstraptokens. Tabellen er på samme form som sts_audconf.trustedIdpConfiguration (se BST2SOSI):
Gyldige attributter i tabellen er:Konfigurationen består af et antal indgange på "map-format", audience, attribute, attribute_value, comment. For et givet audience (f.eks. https://fmk) kan der være følgende indgange
| atribute | Beskrivelse |
|---|
Konfiguration i database er altid den gældende — det er ikke nødvendigt at genstarte før ændringer træder i kraft.
Herudover benyttes tabellen sts_audconf.trustedIdpCitizenConfiguration til konfiguration for input bootstraptokens ifm BST2IDWS. Tabellen er på samme form som sts_audconf.trustedIdpConfiguration:
Gyldige attributter i tabellen er:
...
Eventuel anvendt krypteringsnøgle til token (en issuer kan have flere krypteringsnøgler med forskellige xxx navne). Suffikset er ligegyldigt og tjener alene til støtte for den som kigger på konfigurationen.
...
| encryptionKey.xxx | Eventuel anvendt krypteringsnøgle til token (en issuer kan have flere krypteringsnøgler med forskellige xxx navne). Suffikset er ligegyldigt og tjener alene til støtte for den som kigger på konfigurationen. |
| 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. |
Herudover benyttes tabellen sts_audconf.audienceConfiguration til konfiguration pr. audience.
Konfigurationen består af et antal indgange på "map-format", audience, attribute, attribute_value, comment. For et givet audience (f.eks. https://fmk) kan der være følgende indgange
| atribute | 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. |
Tilføjelse af ny anvender
Er den angivne issuer endnu ikke konfigureret, skal trustedIdpCitizenConfiguration tabellen opdateres med attributter for denne.
Er det angivne audience endnu ikke konfigureret, skal audienceConfiguration tabellen opdateres med attributter for denne.
JWT2Idws
Tilsvarende Bst2Idws findes en omveksling fra JSON web token til identity tokens ligeledes målrettet mod borgere.
Denne kræver ligeledes konfiguration i database tabellen sts_audconf.audienceConfiguration. Dog med en ekstra attribut:
| atribute | Beskrivelse |
|---|---|
| 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. |
Tilføjelse af ny anvender
Er det angivne audience endnu ikke konfigureret, skal audienceConfiguration tabellen opdateres med attributter for denne
...
.
Dynamisk konfiguration. Billetomveksling fra JWT til OIOSaml (JWT2OIOSaml)
...
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.
Tilføjelse af trust til ny, ekstern idp.
- Modtag offentlig nøgle fra den eksterne part.
- Modtag information om hvilket kid der angives i det indgående JWT (key identifier der benyttes af den eksterne part).
- Modtag information om hvilken issuer der optræder i det indgående JWT (typisk en URL der angiver hvor den kan kontaktes - STS'en har dog ikke brug for at kunne slå den url op)
- Verificer at nøglen tilhører det rigtige miljø (test vs produktion) - og er et gyldigt FOCES certifikat
- Indsæt nøglen under et alias svarende til det angivne kid i /pack/sts/test-jwt-idp-trust.jks
Indsæt den relevante issuer i "listen" under jwt2IdwsRequestHandler i services.xml:
Code Block <property name="issuerStrategies"> <util:map> <entry key="http://sts-tester" value-ref="keyCloak"/> <entry key="http://den-nye-issuer" value-ref="keyCloak"/> </util:map> </property>- Ændringen kræver genstart af STS (eller wildfly)
...