Versions Compared

Key

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

...

De enkelte snitflader er beskrevet ved at definere, hvilke anvendersystemer, brugere samt modtager de er tiltænkt.

SnitfladeAnvenderkravSærlige tilfælde
Bruger
Modtager
DGWS

/sts/services/SecurityTokenService

/sts/services/NewSecurityTokenService

Alle som har netværksmæssig adgang

Se afsnit

:TODOSystem eller medarbejder

Konfiguration af DGWSfor beskrivelse og opsætning af nationale roller.

Alle DGWS-services
Medarbejderomveksling
/sts/services/Sosi2OIOSamlAlle som har netværksmæssig adgang

Se afsnit

TODO samme som i anvenderguide med ref.

Alle medarbejdere

Modtager-system skal være konfigureret (i tabellen iboConfig).

/sts/services/OIOSaml2Sosi

Alle som har netværksmæssig adgang

Alle medarbejdere


Alle DGWS-services
/sts/services/BST2SOSI

Offentlig nøgle for anvender-system skal være whitelistet (se afsnit: TODO).

Alle medarbejdere


Alle DGWS-services
Borgeromveksling


/sts/services/Bst2Idws

Offentlig nøgle for anvender-system skal være whitelistet (se afsnit: TODO).

Alle borgere


Modtager-system skal være konfigureret (i tabellen audienceConfiguration).
/sts/services/JWTIdwsOffentlig nøgle for anvender-system skal være whitelistet (se afsnit: TODO).
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 whitelistet (se afsnit: TODO).

Alle borgere


Modtager-system skal være konfigureret (i tabellen audienceConfiguration).

JWT suport skal være aktiveret (i tabellen audienceConfiguration)

Selve konfiguration i forhold til de enkelte snitflader er beskrevet nedenfor.

...

I de følgende afsnit gennemgås konfigurationerne for de enkelte snitflader. De enkelte snitfladers opsætning beskrives og derudover beskrives en opskrift/checkliste i forhold til tilslutning af nye anvendere.

Konfiguration af DGWS
Anchor
KonfigurationDGWS
KonfigurationDGWS

Trustmodellen for DGWS er baseret på, at anvenderen signerer det indgådende idkort ved anvendelse af et certifikat udstedt af CA rodcertifikat i den fællesoffentlige føderation.

Disse rodcertifikater vedligeholdes som en del af SEAL.JAVA biblioteket og skal derfor ikke konfigureres særskilt i STS.

Konfiguration af medarbejderomvekslinger

STS indeholder en række omvekslingssnitflader til brug for brugere af typen medarbejder.

Trustmodellen og opsætningen for de enkelte snitflader er opsummeret i nedenstående tabel og uddybet i de underliggende afsnit:

...

  • Det indkommende idkort skal være signeret af STS selv (udstedt af /NewSecurityTokenService)
  • Der skal være konfigureret et audience, der matcher det, som anvenderen angiver i requestet.

...

  • OIOSaml assertion skal være signeret af trusted part (i test-new-nemLogin-idp.keystore) - i praksis NemLog-In

...

  • Bootstrap token skal være signeret af trusted part (konfigureret i database tabellen sts_audconf.trustedIdpConfiguration). Lokal IdP, SEB eller NemLog-in

Opsætning af Sosi2OIOSaml

Den generelle konfiguration for denne service ligger i services.xml på bean iboRequestHandler og består af følgende:

...

Disse opsætninger er globale for alle anvendere.

Derudover vil der i forespørgsler til denne omvekslingssnitflade indgå et audience, der identificerer det tiltænkte modtagersystem.

De tilladte audience konfigureres i STS databasen i tabellen sts_audconf.iboConfig; disse er:

...

Tilføjelse af nyt audience

Der kan tilføjes nye audience ved indsættelse af en ny række i tabellen iboConfig.

Code Block
titleKonfiguration af nyt audience
collapsetrue
USE sts_audconf;

INSERT INTO `iboConfig` 
 (audience,
  publicKey,
  recipientURL,
  includeBST,
  deliveryNotOnOrAfterOffset,
  notBeforeOffset,
  notOnOrAfterOffset,
  idCardMaxAgeMins) 
VALUES
 ('/ststest3',           'MIIGiDCCBLygAwIBAgIUGesSd7YL6KygrTfmyrVc1/w+wJYwQQYJKoZIhvcNAQEKMDSgDzANBglghkgBZQMEAgEFAKEcMBoGCSqGSIb3DQEBCDANBglghkgBZQMEAgEFAKIDAgEgMGsxLTArBgNVBAMMJERlbiBEYW5za2UgU3RhdCBPQ0VTIHVkc3RlZGVuZGUtQ0EgMTETMBEGA1UECwwKVGVzdCAtIGN0aTEYMBYGA1UECgwPRGVuIERhbnNrZSBTdGF0MQswCQYDVQQGEwJESzAeFw0yMTA0MjgxMTM4NTZaFw0yNDA0MjcxMTM4NTVaMIGeMRUwEwYDVQQDDAxWT0NFU19neWxkaWcxNzA1BgNVBAUTLlVJOkRLLU86RzpjNzBiMDIwNy0xNjJlLTRkM2QtYTdmMS1hMTlhOGUwN2Q5OWIxJjAkBgNVBAoMHVRlc3RvcmdhbmlzYXRpb24gbnIuIDk0MzU0OTY5MRcwFQYDVQRhDA5OVFJESy05NDM1NDk2OTELMAkGA1UEBhMCREswggGiMA0GCSqGSIb3DQEBAQUAA4IBjwAwggGKAoIBgQDMMqgvofQWw4oSUQgGydEZ/hljSZJGdbcaCJHhOawOeVF7I+ISedVayJfGptLk1iW5d92OWbINZzMW6sK6J+kcZeW+xzdwkSV42AJu7kfYw0tgkPwX+5pZbAAEYxgNbUfSEBeBTGWMn5RDIsKkryElrJ5pgmKVxvRURnG3MAieYxges8sYZyKIT3IFsAvn+cymIQ9ObvcpjOib7FMyjoxanwoDm5oRC+AxaC4nRls5gbljrDtu5CuqkOTWajnyFyvMGbDJYagT6IwLRAGFRuGGFdzK9JOZi8X5Zk8e98Fg2O2/DzvIv15bmocpCsSu8gp2fjryYBjdK2eEO2E7uyohd2xBMFwaTop18PVQz1wXA9i3o3VGbcga2+/aIjjgBNnstDzujthgDHu+ib/WlwVAkYU5jVrQQJF3GsVxEQ0oWcNYMQvkF+K7U4YJiiWzXHr2wzC/36xQmZR6i3U626f86J0jHZGm6K4Xo6+5jXBblIhy/XYFhDXqHUooJSxmRxUCAwEAAaOCAYYwggGCMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUfyif2XGZQuJ159c1di5NCCVtdl4wewYIKwYBBQUHAQEEbzBtMEMGCCsGAQUFBzAChjdodHRwOi8vY2ExLmN0aS1nb3YuZGsvb2Nlcy9pc3N1aW5nLzEvY2FjZXJ0L2lzc3VpbmcuY2VyMCYGCCsGAQUFBzABhhpodHRwOi8vY2ExLmN0aS1nb3YuZGsvb2NzcDAhBgNVHSAEGjAYMAgGBgQAj3oBATAMBgoqgVCBKQEBAQMHMDsGCCsGAQUFBwEDBC8wLTArBggrBgEFBQcLAjAfBgcEAIvsSQECMBSGEmh0dHBzOi8vdWlkLmdvdi5kazBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vY2ExLmN0aS1nb3YuZGsvb2Nlcy9pc3N1aW5nLzEvY3JsL2lzc3VpbmcuY3JsMB0GA1UdDgQWBBTMXLy9NQtbqHed6JtCTmjx4/aUZTAOBgNVHQ8BAf8EBAMCBeAwQQYJKoZIhvcNAQEKMDSgDzANBglghkgBZQMEAgEFAKEcMBoGCSqGSIb3DQEBCDANBglghkgBZQMEAgEFAKIDAgEgA4IBgQA9MCrGkd1WfucACqjxSCnpoBqYRHTXrKYjSIarHnjaUMEXMZOixgIi6rk9jdiAX2L+6aY/lee++LejbfR2Immry+w50EpgIGI7jsJ/7ggSN5ySpu6lZpZcZ4KfB2Lx1CYH8AVWgQXDtOrvIGKQxSWY0qwey4M5weBhUGPDrEpu/7k3mMqIIZF1x5CtlrWJZ+bVm9Ohh+f8Yf7scWb14iciA0H85PRAXOvWoN13od2a35mqZqBMaW+4ExvmXailbEmuS1Smr1mcKNVP4ABeW/Oh621VEwChB/OnRpsp5+TjDxenoFQ9vPJm/M/zAke1G3U7Yje0qyi7ke8JxTtMqH0hP8O43WGlloL1NfvXXzigZTGrmVxcPB7HSHPzTINXfF/sqXmBfaHuUuIJqScwDNqwKoJQQLKeE8hhLFYmRdZ+HvgeIzv6aAbfp0h5vpwwpfNjhENuYGSjkI8nzoFmcmQgjXFt1o2xqlVSCU4rZLtqpMKDCnWFPFvblhmkHx7vcVE=',
  '/ststest/login', 
  true, 
  0, 
  0, 
  3600000, 
  null);

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

Den generelle konfiguration for denne service ligger i services.xml på bean nboConfiguration:

...

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 trusted IdP

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.

Tilføjelse af ny anvender

BST2SOSI

Den generelle konfiguration for denne service ligger i services.xml på bean BST2SOSIRequestHandler:

...

Omvekslingen kræver også konfiguration for hver issuer i databasen i tabellen 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. **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??? UPDATE: Er blevet klogere efter dialog med Mads Haargaard: encryptionKey.xxx er private key, men det bør være en indgang med tilhørende public key også - det er jo den der skal udleveres til BST-udstederen (smile) **

...

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)

...

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

FeltBeskrivelse
sourceKan benyttes til at identificere hvor de konkrete roller ligger. Pt. er eneste benyttede værdi 'NationalFederation'
externalNameDet navn hvorunder rollen optræder i den eksterne kilde, f.eks. 'nspLaegesekretaer'
codeDen kode der indgår i id-kortet, f.eks. 40001
valueDen 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
languagesql
use sts_audconf;
insert into roleDefinitions (source, externalName, code, value) values ('NationalFederation', 'nspPlejeAssR3', '41003', 'PlejeAssR3');

Anchor
TrustNationaleRoller
TrustNationaleRoller
Opsætning: 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.

FeltBeskrivelse
cvrEt 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 dvs DGWS) og
  • 'NBO' (svarende til OIOSaml2Sosi)

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

Konfiguration af medarbejderomvekslinger

STS indeholder en række omvekslingssnitflader til brug for brugere af typen medarbejder.

Trustmodellen og opsætningen for de enkelte snitflader er opsummeret i nedenstående tabel og uddybet i de underliggende afsnit:

SnitfladeTrust og opsætning
Medarbejderomveksling
/sts/services/Sosi2OIOSaml
  • Det indkommende idkort skal være signeret af STS selv (udstedt af /NewSecurityTokenService)
  • Der skal være konfigureret et audience, der matcher det, som anvenderen angiver i requestet.
/sts/services/OIOSaml2Sosi
  • OIOSaml assertion skal være signeret af trusted part (i test-new-nemLogin-idp.keystore) - i praksis NemLog-In
/sts/services/BST2SOSI
  • Bootstrap token skal være signeret af trusted part (konfigureret i database tabellen sts_audconf.trustedIdpConfiguration). Lokal IdP, SEB eller NemLog-in

Opsætning af Sosi2OIOSaml

Den generelle konfiguration for denne service ligger i services.xml på bean iboRequestHandler og består af følgende:

PropertyBeskrivelse
validateEnvelopeSignatureOm envelope signaturen på requests skal valideres
checkTargetCertificateOm gyldigheden af certifikat svarende til publicKey (i nedenstående tabel) skal tjekkes før den benyttes
emptyAttributeValueVærdi, der skal bruges til at erstatte tomme attributter på den genererede OIO Saml Assertion

Disse opsætninger er globale for alle anvendere.

Derudover vil der i forespørgsler til denne omvekslingssnitflade indgå et audience, der identificerer det tiltænkte modtagersystem.

De tilladte audience konfigureres i STS databasen i tabellen sts_audconf.iboConfig; disse er:

FeltBeskrivelsePåkrævet
audienceIdentifikation af modtagersystemet som en URI, der skal være på normalform.Ja
publicKeyDen 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
recipientURLDen URL hvor modtagersystemet kan nåes på.Ja
includeBSTOm idkort/bootstrap token skal inkluderes i den svarede assertion. (ja/nej)Ja
deliveryNotOnOrAfterOffsetOffset i tid fra omvekslingstidspunkt, der bruges til opsætning af gyldighed af udstede assertion.Ja
notBeforeOffsetOffset i tid fra omvekslingstidspunkt, der bruges til opsætning af gyldighed af udstede assertion.Ja
notOnOrAfterOffsetOffset i tid fra omvekslingstidspunkt, der bruges til opsætning af gyldighed af udstede assertion.Ja
idCardMaxAgeMinsMaksimal alder på id-kortetNej (default er 1440 min)

Tilføjelse af nyt audience

Der kan tilføjes nye audience ved indsættelse af en ny række i tabellen iboConfig.

Code Block
titleKonfiguration af nyt audience
collapsetrue
USE sts_audconf;

INSERT INTO `iboConfig` 
 (audience,
  publicKey,
  recipientURL,
  includeBST,
  deliveryNotOnOrAfterOffset,
  notBeforeOffset,
  notOnOrAfterOffset,
  idCardMaxAgeMins) 
VALUES
 ('/ststest3',           'MIIGiDCCBLygAwIBAgIUGesSd7YL6KygrTfmyrVc1/w+wJYwQQYJKoZIhvcNAQEKMDSgDzANBglghkgBZQMEAgEFAKEcMBoGCSqGSIb3DQEBCDANBglghkgBZQMEAgEFAKIDAgEgMGsxLTArBgNVBAMMJERlbiBEYW5za2UgU3RhdCBPQ0VTIHVkc3RlZGVuZGUtQ0EgMTETMBEGA1UECwwKVGVzdCAtIGN0aTEYMBYGA1UECgwPRGVuIERhbnNrZSBTdGF0MQswCQYDVQQGEwJESzAeFw0yMTA0MjgxMTM4NTZaFw0yNDA0MjcxMTM4NTVaMIGeMRUwEwYDVQQDDAxWT0NFU19neWxkaWcxNzA1BgNVBAUTLlVJOkRLLU86RzpjNzBiMDIwNy0xNjJlLTRkM2QtYTdmMS1hMTlhOGUwN2Q5OWIxJjAkBgNVBAoMHVRlc3RvcmdhbmlzYXRpb24gbnIuIDk0MzU0OTY5MRcwFQYDVQRhDA5OVFJESy05NDM1NDk2OTELMAkGA1UEBhMCREswggGiMA0GCSqGSIb3DQEBAQUAA4IBjwAwggGKAoIBgQDMMqgvofQWw4oSUQgGydEZ/hljSZJGdbcaCJHhOawOeVF7I+ISedVayJfGptLk1iW5d92OWbINZzMW6sK6J+kcZeW+xzdwkSV42AJu7kfYw0tgkPwX+5pZbAAEYxgNbUfSEBeBTGWMn5RDIsKkryElrJ5pgmKVxvRURnG3MAieYxges8sYZyKIT3IFsAvn+cymIQ9ObvcpjOib7FMyjoxanwoDm5oRC+AxaC4nRls5gbljrDtu5CuqkOTWajnyFyvMGbDJYagT6IwLRAGFRuGGFdzK9JOZi8X5Zk8e98Fg2O2/DzvIv15bmocpCsSu8gp2fjryYBjdK2eEO2E7uyohd2xBMFwaTop18PVQz1wXA9i3o3VGbcga2+/aIjjgBNnstDzujthgDHu+ib/WlwVAkYU5jVrQQJF3GsVxEQ0oWcNYMQvkF+K7U4YJiiWzXHr2wzC/36xQmZR6i3U626f86J0jHZGm6K4Xo6+5jXBblIhy/XYFhDXqHUooJSxmRxUCAwEAAaOCAYYwggGCMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUfyif2XGZQuJ159c1di5NCCVtdl4wewYIKwYBBQUHAQEEbzBtMEMGCCsGAQUFBzAChjdodHRwOi8vY2ExLmN0aS1nb3YuZGsvb2Nlcy9pc3N1aW5nLzEvY2FjZXJ0L2lzc3VpbmcuY2VyMCYGCCsGAQUFBzABhhpodHRwOi8vY2ExLmN0aS1nb3YuZGsvb2NzcDAhBgNVHSAEGjAYMAgGBgQAj3oBATAMBgoqgVCBKQEBAQMHMDsGCCsGAQUFBwEDBC8wLTArBggrBgEFBQcLAjAfBgcEAIvsSQECMBSGEmh0dHBzOi8vdWlkLmdvdi5kazBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vY2ExLmN0aS1nb3YuZGsvb2Nlcy9pc3N1aW5nLzEvY3JsL2lzc3VpbmcuY3JsMB0GA1UdDgQWBBTMXLy9NQtbqHed6JtCTmjx4/aUZTAOBgNVHQ8BAf8EBAMCBeAwQQYJKoZIhvcNAQEKMDSgDzANBglghkgBZQMEAgEFAKEcMBoGCSqGSIb3DQEBCDANBglghkgBZQMEAgEFAKIDAgEgA4IBgQA9MCrGkd1WfucACqjxSCnpoBqYRHTXrKYjSIarHnjaUMEXMZOixgIi6rk9jdiAX2L+6aY/lee++LejbfR2Immry+w50EpgIGI7jsJ/7ggSN5ySpu6lZpZcZ4KfB2Lx1CYH8AVWgQXDtOrvIGKQxSWY0qwey4M5weBhUGPDrEpu/7k3mMqIIZF1x5CtlrWJZ+bVm9Ohh+f8Yf7scWb14iciA0H85PRAXOvWoN13od2a35mqZqBMaW+4ExvmXailbEmuS1Smr1mcKNVP4ABeW/Oh621VEwChB/OnRpsp5+TjDxenoFQ9vPJm/M/zAke1G3U7Yje0qyi7ke8JxTtMqH0hP8O43WGlloL1NfvXXzigZTGrmVxcPB7HSHPzTINXfF/sqXmBfaHuUuIJqScwDNqwKoJQQLKeE8hhLFYmRdZ+HvgeIzv6aAbfp0h5vpwwpfNjhENuYGSjkI8nzoFmcmQgjXFt1o2xqlVSCU4rZLtqpMKDCnWFPFvblhmkHx7vcVE=',
  '/ststest/login', 
  true, 
  0, 
  0, 
  3600000, 
  null);

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

Den generelle konfiguration for denne service ligger i services.xml på bean nboConfiguration:

PropertyBeskrivelse
fuzzyTimeAntal millisekunder tilbage i tid createdDate skal sættes på resulterende idkort
idCardDurationAntal millisekunder det resulterende idkort er gyldigt
allowedDriftInSecondsAntal sekunder tidsbegrænsninger i indgående token må afvige med. (NotBefore, NotOnOrAfter attributterne)
trustedVaultKeystore med trusted eksterne idp'er
cprTrustCertificatesSubjectSerialNumber 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 trusted IdP

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.

Tilføjelse af ny anvender

BST2SOSI

Den generelle konfiguration for denne service ligger i services.xml på bean BST2SOSIRequestHandler:

PropertyBeskrivelse
allowedDriftInSecondsAntal sekunder tidsbegrænsninger i indgående token må afvige med. (NotBefore, NotOnOrAfter attributterne)
allowedAudienceGyldigt audience i indgående bootstraptoken
fuzzyTimeAntal millisekunder tilbage i tid createdDate skal sættes på resulterende idkort
idCardDurationAntal millisekunder det resulterende idkort er gyldigt
whitelistValidationOm 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:

FeltBeskrivelse
issuerIdentifikation på udstederen af bootstraptokens
attributeAttribut navn
attribute_valueAttribut værdi
commentValgfri kommentar - specielt brugbart til whitelist indgange uden identifikation af organisationen

Gyldige attributter i tabellen er:

attributeBeskrivelse
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. **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??? UPDATE: Er blevet klogere efter dialog med Mads Haargaard: encryptionKey.xxx er private key, men det bør være en indgang med tilhørende public key også - det er jo den der skal udleveres til BST-udstederen (smile) **

tokenProfileAnvendt tokenprofil. OIOH3BST (lokal IdP udstedt), OIOH2BST (SEB udstedt) eller OIO3BST (NemLog-in3 STS udstedt).
validateHOKAngivelse 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.xxxTrusted public key som kan verificere signatur på bootstrap token (en issuer kan have flere nøgler med forskellige xxx navne).

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

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

...

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
languagesql
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.

...

Konfiguration af borgeromvekslinger

...