Edit profile

Page History

Versions Compared

Old Version 4

changes.mady.by.user Unknown User (tim.hallgren@capgeminisogeti.dk)

Saved on 29-01-2019

compared with

New Version 5

changes.mady.by.user Unknown User (ksr)

Saved on 12-03-2019

Key

This line was added.
This line was removed.
Formatting was changed.

...

Table of Contents

outline	true

Dokumenthistorik

Version	Dato	Ansvarlig	Beskrivelse
1	6.7.2018	KSR	Opdateret på baggrund af Fuldmagtsprojektet
2	6.7.2018	KSR	Opdateret med information om JWT support

Introduktion

Dette dokument indeholder en vejledning til driften af SOSI-STS

...

Følgende er en oversigt over STS snitflader og kravene til adgang til disse.

Begreber

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.

Disse begreber benyttes i snitfladerne nedenfor.

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.

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 medarbejder services

...

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.

...

Følgende felter er relevante

Felt	Beskrivelse
source	Kan benyttes til at identificere hvor de konkrete roller ligger. Pt. er eneste benyttede værdi 'NationalFederation'
externalName	Det navn hvorunder rollen optræder i den eksterne kilde, f.eks. 'nspLaegesekretaer'
code	Den kode der indgår i id-kortet, f.eks. 40001
value	Den tekst-værdi der indgår i id-kortet, f.eks. Laegesekretaer

Konfiguration i database er altid den gældende — det er ikke nødvendigt at genstarte før ændringer træder i kraft - der kan dog være op til 10 minutters forsinkelse.

Eksempel-SQL:

Code Block

language	sql

use sts_audconf;
insert into roleDefinitions (source, externalName, code, value) values ('NationalFederation', 'nspPlejeAssR3', '41003', 'PlejeAssR3');

Dynamisk konfiguration. Opsætning af 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.

Felt	Beskrivelse
cvr	Et cvr nummer der tillades adgang uden validering af nationale roller.
endpoint	Det endpoint hvortil funktionaliteten kan benyttes. Mulige værdier er 'STS' (svarende til SecurityTokenService) og 'NBO' (svarende til OIOSaml2Sosi)

Af sikkerhedsmæssige årsager anbefales funktionaliteten pt kun benyttes for 'STS'.

...

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.