Page History
...
Konfiguration af medarbejderomvekslinger
Sosi2OIOSaml
Den generelle konfiguration for denne service ligger i services.xml på bean iboRequestHandler:
| Property | Beskrivelse |
|---|---|
| validateEnvelopeSignature | Om envelope signaturen på requests skal valideres |
| checkTargetCertificate | Om gyldigheden af certifikat svarende til publicKey (i nedenstående tabel) skal tjekkes før den benyttes |
| emptyAttributeValue | Den værdi der skal bruges til at erstatte tomme attributter på den genererede OIO Saml Assertion |
For hvert audience, skal følgende konfigureres i databasen i tabellen sts_audconf.iboConfig; disse er:
...
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
Trust til eksterne idp'er er sat op i test-new-nemLogin-idp.keystore. Se afsnittet om Java keystores.
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 på bean nboConfiguration. Nedenstående viser aktuel indstilling for produktion:
| Code Block |
|---|
<property name="cprTrustCertificates">
<list>
<value>CVR:34051178-UID:77371184</value> <!-- nemlogin prod -->
</list>
</property> |
Tilføjelse af ny anvender
Den generelle konfiguration for denne service ligger i services.xml på bean nboConfiguration:
| Property | Beskrivelse |
|---|---|
| fuzzyTime | Antal millisekunder tilbage i tid createdDate skal sættes på resulterende idkort |
| idCardDuration | Antal millisekunder det resulterende idkort er gyldigt |
| allowedDriftInSeconds | Antal sekunder tidsbegrænsninger i indgående token må afvige med. (NotBefore, NotOnOrAfter attributterne) |
| trustedVault | Sti til keystore med trusted eksterne idp'er |
| cprTrustCertificates | SubjectSerialNumber på eksterne idp'er hvor medsendte cpr-nummer ikke skal valideres |
Trust til eksterne idp'er er sat op i test-new-nemLogin-idp.keystore (trustedVault i konfigurationen). Se afsnittet om Java keystores.
Tilføjelse af ny anvender
Hvis der skal tilføjes trust til en ny idp, skal Hvis der skal tilføjes trust til en ny idp, skal det opdateres i test-new-nemLogin-idp.keystore, som beskrevet i afsnittet om Java keystores.
Evt. kan property cprTrustCertificates opdateres (nævnt ovenfor).
BST2SOSI
Omveksling fra BST token til SOSI id-kort kræver konfiguration for hver issuer i databasen i tabellen sts_audconf.trustedIdpConfiguration:
...
Den generelle konfiguration for denne service ligger i services.xml på bean BST2SOSIRequestHandler:
| Property | Beskrivelse |
|---|---|
| allowedDriftInSeconds | Antal sekunder tidsbegrænsninger i indgående token må afvige med. (NotBefore, NotOnOrAfter attributterne) |
| allowedAudience | Gyldigt audience i indgående bootstraptoken |
| fuzzyTime | Antal millisekunder tilbage i tid createdDate skal sættes på resulterende idkort |
| idCardDuration | Antal millisekunder det resulterende idkort er gyldigt |
| whitelistValidation | Om whitelist-checks af anvender certifikater skal være slået til eller fra |
Omvekslingen kræver også konfiguration for hver issuer i databasen i tabellen sts_audconf.trustedIdpConfiguration:
| Felt | Beskrivelse |
|---|---|
| issuer | Identifikation på udstederen af bootstraptokens |
| attribute | Attribut navn |
| attribute_value | Attribut værdi |
| comment | Valgfri kommentar - specielt brugbart til whitelist indgange uden identifikation af organisationen |
Gyldige attributter i tabellen er:
| atribute | Beskrivelse |
|---|---|
| encryptionKey |
Gyldige attributter i tabellen er:
| 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 (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 (en issuer kan have flere trusted certifikater med forskellige xxx navne). |
Slå whitelist-checks fra (ikke dynamisk)
I services.xml findes en bean med id "BST2SOSIRequestHandler". Her kan specificeres om whitlist-checks skal være slået til eller fra, vha property "whitelistValidation":
| 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.
Er issuer allerede i tabellen, skal der oprettes:
- Evt. en ny encryptionKey.xxx attribut med krypteringsnøglen (hvis den ikke allerede er til stede).
- En ny certificate.xxx attribut med ssn for anvendercertifikatet
- En ny signingKey.xxx attribut med nøglen til certifikatet der bruges til signering af bootstraptokenet (hvis det ikke allerede er til stede).
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.
Nationale roller vil optræde i id-kortet som en rolle på formen urn:dk:healthcare:national-federation-role:code:40001:value:Laegesekretaer
Følgende felter er relevante
...
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.
Er issuer allerede i tabellen, skal der oprettes:
- Evt. en ny encryptionKey.xxx attribut med krypteringsnøglen (hvis den ikke allerede er til stede).
- En ny certificate.xxx attribut med ssn for anvendercertifikatet
- En ny signingKey.xxx attribut med nøglen til certifikatet der bruges til signering af bootstraptokenet (hvis det ikke allerede er til stede).
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.
Nationale roller vil optræde i id-kortet som en rolle på formen urn:dk:healthcare:national-federation-role:code:40001:value:Laegesekretaer
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 | ||
|---|---|---|
| ||
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.
| 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'.
Konfiguration af borgeromvekslinger
Bst2Idws
Omveksling fra Bootstrap token til identitytoken (også tidligere kaldet webapotek løsning)
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 | ||
|---|---|---|
| ||
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'.
Konfiguration af borgeromvekslinger
Bst2Idws
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).
Den generelle konfiguration for denne service ligger i services.xml på bean nboConfiguration, ligesom for OIOSaml2Sosi omvekslingen. Til denne omveksling benyttes dog kun de to properties fuzzyTime og allowedDriftInSeconds.
Database tabellen sts_audconf.trustedIdpCitizenConfiguration benyttes til konfiguration for issuers af de indgående bootstraptokens. Tabellen er på samme form som sts_Database tabellen sts_audconf.trustedIdpCitizenConfiguration benyttes til konfiguration for input bootstraptokens. Tabellen er på samme form som sts_audconf.trustedIdpConfiguration (se BST2SOSI):.
Gyldige attributter i tabellen er:
| 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. 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. |
...
Tilsvarende Bst2Idws findes en omveksling fra JSON web token til identity tokens ligeledes målrettet mod borgere.
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:
...
Den generelle konfiguration for denne service ligger i services.xml på bean jwt2IdwsRequestHandler:
| Property | Beskrivelse |
|---|---|
| fuzzyTime | Antal millisekunder tilbage i tid notBefore skal sættes på resulterende token |
| allowedDriftInSeconds | Antal sekunder tidsbegrænsninger i indgående token må afvige med |
| trustStoreFile | Sti til keystore med trusted eksterne idp'er |
| trustStorePassword | Password til keystore |
| issuerStrategies | Liste af gyldige issuers. Fx <entry key="http://sts-tester" |
...
| value-ref |
...
| ="keyCloak"/> |
Trust til eksterne idp'er er sat op i test-jwt-idp-trust.jks (property trustStoreFile). Se afsnittet om Java keystores.
Ligesom for Bst2Idws kræves konfiguration i database tabellen sts_audconf.audienceConfiguration. Dog med en ekstra attribut.
| atribute | Beskrivelse |
|---|---|
| lifetime | Angiver gyldighed af det udstedte token, f.eks. 3600 (s). Tilstedeværelsen af denne "aktiverer" det givne audience |
| certificate.xxx | Angiver SubjectSerialNumber (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. |
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.
Er det angivne audience endnu ikke konfigureret, skal audienceConfiguration tabellen opdateres med attributter for denne.
Er audience allerede i audienceConfiguration tabellen, skal der oprettes en ny certificate.xxx attribut med ssn for anvendercertifikatet. Anvender skal kende det eksisterende jwtScope.
JWT2OIOSaml
Den generelle konfiguration for denne service ligger i services.xml på bean sboRequestHandler:
| Property | Beskrivelse |
|---|---|
| checkTargetCertificate | Om gyldigheden af certifikat svarende til publicKey (i nedenstående tabel) skal tjekkes før den benyttes |
| fuzzyTime | Antal millisekunder tilbage i tid notBefore skal sættes på resulterende token |
| allowedDriftInSeconds | Antal sekunder tidsbegrænsninger i indgående token må afvige med |
| trustStoreFile | Sti til keystore med trusted eksterne idp'er |
| trustStorePassword | Password til keystore |
| issuerStrategies | Liste af gyldige issuers. Fx <entry key="http://sts-tester" value-ref="keyCloak"/> |
Ligesom for Bst2Idws kræves konfiguration i database tabellen sts_audconf.audienceConfiguration. Dog med en ekstra attribut.
...
Angiver SubjectSerialNumber (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.
...
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.
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.
Er audience allerede i audienceConfiguration tabellen, skal der oprettes en ny certificate.xxx attribut med ssn for anvendercertifikatet. Anvender skal kende det eksisterende jwtScope.
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(property trustStoreFile). Se afsnittet om Java keystores.
Audience konfiguration ligger i databasen i tabellen sts_audconf.audienceConfiguration ligesom Bst2Idws og JWT2Idws. Dog med lidt flere attributter:
...
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.
...