Page History
...
- 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
- Ændringen kræver genstart af STS (eller wildfly)
...
Konfiguration af medarbejderomvekslinger
Udover statisk konfiguration, som er beskrevet i installationsvejledning, så findes der desuden følgende områder som kan konfigureres dynamisk.
Sosi2OIOSaml
For hvert audience, skal følgende konfigureres i databasen i tabellen sts_audconf.iboConfig; disse er:
...
Omveksling fra BST token til SOSI id-kort kræver konfiguration gemt for hver issuer i databasen i tabellen sts_audconf.trustedIdpConfiguration:
...
| 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 certifikatcertifikat (typisk FOCES) der har mulighed for at benytte servicen. I praksis beder vi om det offentlige certifikat og henter oplysningen ud herfra. 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.
Der findes pt. i produktion kun et audience (https://fmk). Herudover yderligere et antal audiences i test, til interne eller eksterne testformål.
Dette audience kommer i spil, idet anvendere af borger-billetomvekslingen angiver, hvilket audience de ønsker billetten udstedt til.
Bemærk: Kombinationen af audience og attribut skal være unik, ellers vil "duplikater" blive ignoreret.
Tilføjelse af ny anvender
Er den angivne issuer endnu ikke konfigureret, skal trustedIdpCitizenConfiguration tabellen opdateres med attributter for denne.
Er Er det angivne audience endnu ikke konfigureret, skal audienceConfiguration tabellen opdateres med attributter for denne.
JWT2Idws
Trust til eksterne idp'er er sat op i test-jwt-idp-trust.jks. Se afsnittet om Java keystores.
Derudover ligger kendte issuers i en property på jwt2IdwsRequestHandler i services.xml:
...
Fx:
| Code Block |
|---|
INSERT INTO audienceConfiguration (audience, attribute, attribute_value) VALUES
('http://audience/clear', 'lifetime', '300');
INSERT INTO audienceConfiguration (audience, attribute, attribute_value, comment) VALUES
('http://audience/clear', 'certificate.test1', 'CVR:30808460-FID:94731315', 'kommentar'); |
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:
...
Trust til eksterne idp'er er sat op i test-jwt-idp-trust.jks. Se afsnittet om Java keystores.
Derudover ligger kendte issuers i en property på jwt2IdwsRequestHandler i services.xml:
| Code Block |
|---|
<property name="issuerStrategies">
<util:map>
<entry key="http://sts-tester" value-ref="keyCloak"/>
</util:map>
</property> |
Ligesom for Bst2Idws kræves konfiguration i database tabellen sts_audconf.audienceConfiguration. Dog med en ekstra attribut.
| atribute |
|---|
Tilføjelse af ny anvender
Er den angivne issuer endnu ikke konfigureret, skal test-jwt-idp-trust.jks opdateres, som beskrevet i afsnittet om Java keystores. Derudover skal property issuerStrategies opdateres i services.xml med den nye issuer (nævnt ovenfor).
Er det angivne audience endnu ikke konfigureret, skal audienceConfiguration tabellen opdateres med attributter for denne.
JWT2OIOSaml
Ligesom for JWT2Idws, er trust til eksterne idp'er sat op i test-jwt-idp-trust.jks, og kendte issuers ligger i property issuerStrategies på sboRequestHandler i services.xml.
Audience konfiguration ligger i databasen i tabellen sts_audconf.audienceConfiguration ligesom Bst2Idws og JWT2Idws. Dog med lidt flere attributter:
| 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 certifikat (typisk FOCES) der har mulighed for at benytte servicen. I praksis beder vi om det offentlige certifikat og henter oplysningen ud herfra. 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) |
Tilføjelse af ny anvender
Værdien aftales ved oprettelse. |
Tilføjelse af ny anvender
Er den angivne issuer endnu ikke konfigureret,Er den angivne issuer endnu ikke konfigureret, skal test-jwt-idp-trust.jks opdateres, som beskrevet i afsnittet om Java keystores. Derudover skal property issuerStrategies opdateres i services.xml med den nye issuer (nævnt ovenfor).
Er det angivne audience endnu ikke konfigureret, skal audienceConfiguration tabellen opdateres med attributter for denne.
Konfiguration af audiences til borger-billetomveksling
JWT2OIOSaml
Ligesom for JWT2Idws, er trust til eksterne idp'er sat op i test-jwt-idp-trust.jks, og kendte issuers ligger i property issuerStrategies på sboRequestHandler i services.xml.
Audience konfiguration ligger i databasen i tabellen Disse findes i tabellen sts_audconf.audienceConfiguration ligesom Bst2Idws og JWT2Idws.
Et nyt audience tilføjes ved at angive hvor længe et udstedt token til dette audience er gyldigt:
| Code Block |
|---|
INSERT INTO audienceConfiguration (audience, attribute, attribute_value) VALUES
('http://audience/clear', 'lifetime', '300'); |
Der findes pt. i produktion kun et audience (https://fmk). Herudover yderligere et antal audiences i test, til interne eller eksterne testformål.
Dette audience kommer i spil, idet anvendere af borger-billetomvekslingen angiver, hvilket audience de ønsker billetten udstedt til.
Rettelsen slår igennem så snart database-rettelsen er replikeret fra backoffice til det relevante NSP-miljø
Tildeling af adgang til borger-billetomveksling for anvender system
Adgang tildeles pr audience - i enten test eller produktion.
Vi har brug for at kende SubjectSerialNumber for det certifikat (typisk FOCES) de benytter. Dette skal være et gyldigt OCES2-certifikat (test eller prod) - og BØR være et FOCES certifikat. I praksis beder vi om det offentlige certifikat og henter oplysningen ud herfra.
Herudover skal vi vide hvilket audience, samt i hvilket miljø der ønskes adgang. Adgangen godkendes af operatøren.
| Code Block |
|---|
INSERT INTO audienceConfiguration (audience, attribute, attribute_value, comment) VALUES
('http://audience/clear', 'certificate.test1', 'CVR:30808460-FID:94731315', 'kommentar'); |
Navnet (i eksemplet 'certificate.test1' er ligegyldigt - det skal blot starte med 'certificate.' - resten tjener alene til at lette overskueligheden - man kan evt. indflette udløbsdatoen for nemheds skyld).
Bemærk: Kombinationen af audience og attribut skal være unik, ellers vil "duplikater" blive ignoreret.
Rettelsen slår igennem så snart database-rettelsen er replikeret fra backoffice til det relevante NSP-miljø
Certifikat fornyelser hos anvender system
Såfremt der er tale om en simpel fornyelse hos anvender systemet, hvor CVR-FID ikke ændres, skal der ikke foretages noget.
Såfremt der er tale om helt nye nøgler, indsættes den nye ved siden af den gamle. Efterfølgende kan den gamle fjernes hvis/når den ikke længere benyttes.
Konfiguration af audience til JWT billetomveksling STS-2.5.3
Dette findes ligeledes i tabellen sts_audconf.audienceconfiguration.
Det nye audience oprettes som i afsnittet ovenfor, hvis det ikke allerede findes.
Herefter tilføjes JWT-support til dette audience:
| Code Block |
|---|
INSERT INTO audienceConfiguration (audience, attribute, attribute_value) VALUES
('http://audience/clear', 'jwtScope', 'clear'); |
Attribute_value aftales ved oprettelse, idet denne skal indgå som 'scope' i det modtagne JWT token.
Tildeling af anvender systems adgang til JWT billet omveksling
Dog med lidt flere attributter:
| 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 (typisk FOCES) der har mulighed for at benytte servicen. I praksis beder vi om det offentlige certifikat og henter oplysningen ud herfra. 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. Værdien aftales ved oprettelse. |
| 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) |
Tilføjelse af ny anvender
Er den angivne issuer endnu ikke konfigureret, skal test-jwt-idp-trust.jks opdateres, som beskrevet i afsnittet om Java keystores. Derudover skal property issuerStrategies opdateres i services.xml med den nye issuer (nævnt ovenfor).
Er det angivne audience endnu ikke konfigureret, skal audienceConfiguration tabellen opdateres med attributter for denne.
Certifikat fornyelser hos anvender system
Såfremt der er tale om en simpel fornyelse hos anvender systemet, hvor CVR-FID ikke ændres, skal der ikke foretages noget.
Såfremt der er tale om helt nye nøgler, indsættes den nye ved siden af den gamle. Efterfølgende kan den gamle fjernes hvis/når den ikke længere benyttesDette fungerer helt på samme måde som ved adgang til borger-billetomveksling. Det er dog nødvendigt at anvende et audience som er "JWT-enabled", dvs. hvor jwtScope er sat.
SLA logning
Følgende tabel viser STS’ens sla logpunkter samt tilhørende navn. De enkelte logpunkter beskrives i detaljer i det følgende.
...