INDHOLD
Beskrivelse
På NSP hedder servicen Security Token Service (STS): en fælles komponent, som kan udstede adgangsgivende billetter på baggrund af OCES-certifikater. En sådan komponent betegnes generelt som en "Identitetsservice" eller IdP (IdentityProvider).På den nationale service platform (NSP) anvendes id-kort som single sign-on mekanisme til at autentificere anvendere op mod platformens services. I andre sammenhænge som f.eks. på sundhed.dk eller borger.dk anvendes den fælles offentlig brugerstyring (Nem-Login). STS'en tilbyder billetomveksling for at lette integration mellem disse, så anvendere nemt kan kalde services på tværs af NSP og andre systemer.
Anvenderes tilgang til STS vil ofte være med hjælp fra Seal.Java [A2] eller Seal.NET [A3], som er biblioteker der bl.a. hjælper til med at understøtte brugen af DGWS [A4] og håndtere sikkerhedsaspekterne.
Benytter RID-CPR servicen (fra Nets) til verifikation af CPR, samt den Digitale Fuldmagt.
Support ansvarlig: Kvalitets IT
NSP: Sikkerhedsservices (STS) - Leverancebeskrivelse
Forretningsanvendelse
Relaterede registre og services
- B02 Autorisations registret
- B05 Bemyndigelse (BEM)
- B29 Sundhedsvæsenets Elektroniske Brugerstyring (SEB) - UNDER UDVIKLING
- E02 cra (Certificate Revocation Authority)
- E06 SOSI-GW
Applikationsbeskrivelse
STS (Security Token Service) sikkerheds services på NSP omfatter Identitet og Billetomveksling mellem SOSI-tickets og Nem-login.
STS - Identitetsservice: Adgang til NSP-komponenters services er begrænset med autentificering. Denne autentifikation er baseret på OCES-certifikater, hvormed anvendere er i stand til at identificere sig. Der findes en fælles komponent, som kan udstede adgangsgivende billetter på baggrund af OCES-certifikater. En sådan komponent betegnes generelt som en "Identitetsservice" eller IdP (IdentityProvider). På NSP hedder servicen Security Token Service (STS).
STS - Billetomveksling: På den nationale service platform (NSP) anvendes id-kort som single sign-on mekanisme til at autentificere anvendere op mod platformens services. I andre sammenhænge som f.eks. på sundhed.dk eller borger.dk anvendes den fælles offentlig brugerstyring (Nem-Login). STS'en tilbyder billetomveksling for at lette integration mellem disse, så anvendere nemt kan kalde services på tværs af NSP og andre systemer.
Adgang til NSP-komponenters services er begrænset med autentificering. Denne autentifikation er baseret på OCES-certifikater, hvormed anvendere er i stand til at identificere sig. Det betyder dog ikke at alle services skal validere alle anvenderes certifikater og tilhørende information. Dette vil være et stort ansvar at fordele på så mange komponenter. Derfor er der en fælles komponent, som kan udstede adgangsgivende billetter, som kun kræver simpel verifikation. En sådan komponent betegnes generelt som en "Identitetsservice" eller IdP (IdentityProvider). På NSP hedder servicen Security Token Service (STS).
Introduktionen af STS betyder at en anvender udelukkende skal identificere sig overfor STS med sit OCES-certifikat og får herefter et id-kort, der er underskrevet med (STS) føderationens certifikat. Dette id-kort agerer som nøglen, der identificerer anvenderen, og kan give adgang til de andre komponenter på NSP. Komponenternes ansvar er derfor kun at kende til STS'ens ene certifikat og verificere dette i id-kortet. STS verificerer og beriger desuden id-kortet med en række af attributter. F.eks. verificeres slutbrugerens personnummer og dennes autorisation.
Ingen specifikke WSDL'er eksisterer for STS'ens services
STS kræver ingen whitelisting
STS består af en række del-komponenter (eller services), som konfigureres via Spring frameworket. For nærmere detaljer omkring konfigurationen henvises til installationsvejledningen. Komponenterne indkapsler følgende funktionalitet:
Crl: Spærreliste kontrol af OCES certifikater
Acl: Check for adgang til udstedelse ID-kort (benyttes ikke pt)
Cpr: CPR opslag ud fra OCES-medarbejdercertifikat eller borgercertifikat
Authorization: Verifikation af autorisation id ud fra CPR Fuldmagt og den fællesoffentlige fuldmagtsløsning.
En væsentlig komponent for STS er SOSI Seal biblioteket, der indtager en central rolle i forbindelse med udstedelse af ID-kortet. Seal anvendes som et tredjeparts bibliotek af STS.
Snitflader:
-----------
NewSecurityTokenService -- Udstedelse af STS-signeret id-kort. Erstatter samtidig NameId til et kanonisk format (nødvendigt hvis id-kortet skal veksles til OIOSaml). SOSI Seal biblioteket benyttes af STS til serialisering/deserialisering af web service kaldet samt signering af udstedte ID-kort.
SecurityTokenService -- Legacy udgave af ovennævnte service (uden erstatning af NameId). Benyt NewSecurityTokenService hvis muligt
Sosi2OIOSaml -- Ombytter STS-signeret id-kort fra SOSI ID-kort til OIOSAML assertion (NemLogin token) rettet mod et specifikt audience, f.eks. sundhed.dk. Bemærk at dette id-kort skal være udstedt af NewSecurityTokenService.
OIOSaml2Sosi -- Ombytter OIOSaml (nem-login) token til signeret id-kort. Token skal være signeret af troværdig tredjepart (nemlogin)
Bst2Idws -- Ombytter OIOSaml bootstrap token til signeret identitytoken rettet mod et givet audience, f.eks. FMK. Token skal være signeret af troværdig tredjepart(nem-login)
JWT2Idws -- Ombytter JSON Web token til signeret identity-token rettet mod et givet audience, f.eks. FMK. Token skal være signeret af troværdig tredjepart (pt. en OID connector)
Datastruktur, Intern register: STS
Register properties:
STS-anvendelse af database begrænser sig primært til læsning af konfigurationsdata og persistering af cachede værdier
Entitetsbeskrivelser
audienceConfiguration
DB: sts_audconf
Indeholder konfiguration af borger-billetomveksling med angivelse af audiences, og adgang til disse.
indeholder konfiguration vedrørende billetomveksling fra bootstrap token til IDWS token
Objektet indeholder informationen:
--------------------------------------
audience
attribute
attribute_value
authorizationDefinitions
Indeholder autorisations definitioner.
DB: sts_audconf
Objektet indeholder informationen:
--------------------------------------
role
cprcache
indeholder relationer mellem certifikat og CPR-nummer. Anvendes hvis deploymiljøet er godkendt til opbevaring af relationen i klartekst (Nødvendig hvis ikke CPR web servicen altid skal kaldes med manglende CPR i ID-kort).
cprcache fungerer som en simpel cache for CPR-opslag, og repopuleres automatisk, hvorfor rækkerne kan slettes efter behov.
STS indeholder indeholder endelig en cache at mapningen fra SubjectSerialNumber til cpr nummer for medarbejdere og borgere. Dvs. SubjectSerialNumber kan enten være et PID eller et cvr-rid. Tabellen ligger lokalt på de enkelte NSP-noder uden replikering. Data opdateres automatisk af STS og data vil altid kunne slettes unden funktionel effekt (vil dog have negativ, midlertidig effekt på performance).
DB: sts
iboConfig
Indeholder konfiguration af (Medarbejder) billet omveksling fra id-kort til OIOSaml token (sikker browseropstart)
indeholder audience specifik konfiguration for SOSI ID-kort til OIOSAML omveksling
DB: sts_audconf
Objektet indeholder informationen:
--------------------------------------
audience
publicKey
recipientURL
includeBST
deliveryNotOnOrAfterOffset
notBeforeOffset
notOnOrAfterOffset
idCardMaxAgeMins
NSP Keystore (Luna box)
Indeholder certifikat og nøgler for føderationen, samt trustede 3. parter der kan foretages billetomveksling fra.
Placeret i dedikeret LUNA boks for maximim sikkerhed
roleDefinitions
Indeholder opsætning af gyldige nationale roller, og hvorledes disse repræsenteres i id-kort og i SEB (Sundhedsvæsenets Elektroniske Brugerstyring)
DB: sts_audconf
Objektet indeholder informationen:
--------------------------------------
source -- Hvem har udstedt rollen, ex: 'NationalFederation'
externalName -- rollenavn, ex: 'nspSundAssistR1'
code -- rolle kode, ex: '41001'
value -- rolle navn, ex: 'SundAssistR1'
trustedCvr
Indeholder en liste af cvr numre, der kan angive nationale roller uden at få disse valideret
DB: sts_audconf
Objektet indeholder informationen:
--------------------------------------
cvr
endpoint
Tabelbeskrivelser
Tabel: audienceConfiguration
DB: sts_audconf
CREATE TABLE audienceConfiguration (
audience VARCHAR(255) NOT NULL,
attribute VARCHAR(50) NOT NULL,
attribute_value VARCHAR(4095));
CREATE UNIQUE INDEX audienceConfiguration_uniq ON audienceConfiguration (audience, attribute);
Tabel: authorizationDefinitions
-- new table to hold authorizationDefinitions
USE sts_audconf;
CREATE TABLE authorizationDefinitions (
role VARCHAR(4) NOT NULL)
ENGINE=InnoDB DEFAULT CHARSET=utf8;
Tabel: cprcache
CREATE TABLE cprcache (
ssn VARCHAR(64) NOT NULL,
cpr VARCHAR(16) NOT NULL,
createdDate datetime);
CREATE UNIQUE INDEX cprcache_ssn ON cprcache (ssn);
Tabel: iboConfig
DB: sts_audconf
CREATE TABLE iboConfig (
audience VARCHAR(255) NOT NULL,
publicKey TEXT NOT NULL,
recipientURL VARCHAR(255) NOT NULL,
includeBST BOOL NOT NULL,
deliveryNotOnOrAfterOffset BIGINT NOT NULL,
notBeforeOffset BIGINT NOT NULL,
notOnOrAfterOffset BIGINT NOT NULL,
idCardMaxAgeMins BIGINT,
KEY audience (audience)
)
Tabel: roleDefinitions
-- new table to hold roleDefinitions for national roles
USE sts_audconf;
DROP TABLE IF EXISTS roleDefinitions;
CREATE TABLE roleDefinitions (
source VARCHAR(255) NOT NULL,
externalName VARCHAR(255) NOT NULL,
code VARCHAR(255) NOT NULL,
value VARCHAR(255)) ENGINE=InnoDB DEFAULT CHARSET=utf8;
GRANT ALL ON sts_audconf.roleDefinitions TO 'sts'@'%';
Tabel: trustedCvr
-- new table to hold trustedCvr for national roles
USE sts_audconf;
CREATE TABLE trustedCvr (
cvr VARCHAR(8) NOT NULL,
endpoint VARCHAR(64) NOT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8;
create unique index trustedCvr_uniq on trustedCvr (cvr, endpoint);