Page History

...

Serviceanvenderen skal identificerer ** CHG: autentificere, ikke identificere ** sig overfor Secure Token Server for at få udstedt sin sikkerhedsbillet. Secure Token Server skal således enten kende serviceanvenderen direkte eller præsenteres for en sikkerhedsbillet, der identificerer serviceanvenderen, og som er udstedt af troværdig tredjepart (en anden Secure Token Server eller Identity Provider), som Secure Token Server stoler på.

...

I visse tilfælde kan en Secure Token Server kræve, at en serviceanvender specificerer, hvad sikkerhedsbilletten skal anvendes til (intended audience). Det er op til Secure Token Server at beslutte, om de medstende medsendte claims og/eller intended audience kan opfyldes. Secure Token Server sammensætter sikkerhedsbilletten udfra serviceanvenderens identitet, eventuelle ønsker fra serviceanvender (claims+intended audience) samt prædefinerede konfigurationer. Nogle oplysninger kan Secure Token Server selv være i besiddelse af, men det er også muligt, at Secure Token Server betjener sig af en eller flere eksterne services til at slå ekstra oplysninger op om serviceanvenderen eller at verificere oplysninger eller claims (pil nr 2 i tegningen ovenfor).

...

• Navn
• Officielle id'er (f.eks. cprnummer, autorisationsid)
• Organisatoriske tilhørsfohold
• Roller
• Fuldmagtsoplysninger

** CHG: Tilføj noget om at det er service-udbyderens ansvar at foretage adgangsstyring ift. servicen og at dette kan gøres på baggrund af trust til STS og (validerede) attributter i adgangsbilletten **

STS på National Service Platform (NSP)

Der findes i dag en række forretningsservice på NSP. Disse services dækker forskellige formål - fra datadeling via Dokumentdelingsservice (DDS) til verifikation af behandlingsrelation via Behandlingsrelationsservice (BRS). **CHG: BRS er ikke en forretningsservice - brug et andet eksempel **

Selvom formålene for NSP services er forskellige, så har de en række fællestræk f.eks. i forhold til autentificeringautentifikation. Det betyder dog ikke at alle NSP 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 for gyldighed i de konkrete NSP services.

På NSP hedder servicen Security Token Service (STS). ** CHG: Eller 'SOSI-STS'? For at skelne fra en generel Security Token Service? Jeg må indrømme at jeg har aldrig har hørt begrebet 'Secure Token Server' anvendt, se også ovenstående kommentar **

Der er i skrivende stund to aktuelle sikkerhedsprotokoller i spil på NSP:

...

• SOSI Idkort (medarbejder og systemadgang til DGWS beskyttede services)
• OIO IDWS billet (borgerbilletter til f.eks. adgang til OIO IDWS beskyttede services)
• OIO SAML billet (medarbejderbillet eller borgerbillet feks. til sikker sessionsoverdragelse (SSO) **CHG: SSO står ellers for Single-Sign-On**/sikker browseropstart til løsningerne sundhed.dk eller forløbsplaner.dk)

...

Som beskrevet i afsnittet ovenfor, så skal en potentiel anvender til en NSP service først integrere med STS og identificere **CHG: 'autentificere' ikke 'identificere' ** sig overfor denne med henblik på at få udstedt en til formålet passende sikkerhedsbillet.

...

Som nævnt tidligere, så er de væsentligste opgaver for STS at udstede, validere og forny/omveksle sikkerhedsbilletter. ** CHG: Ikke 'forny' kun omveksle **

I det følgende afsnit præsenteres et overblik over NSP STS:

• Hvilke snitflader udbydes (herunder en inddeling af snitfladerne i overordnede områder)?
• Hvilke andre systemer integrerer STS med, og hvad er formålet med disse integrationer?

Efterfølgende vil vi beskrive beskrives de tre overordnede anvendelsesområder, som er understøttet af STS:

...

De viste services i figuren udenfor er uddybet i tabellen nedenfor. ** CHG: Hvilken klassifikation benyttes til 'Sikkerhedsniveau' her? DGWS og har sin egen klassifikation, OIOSAML anvender NIST. Forvirrer kolonnen ikke mere end den gavner? Skal vi ikke droppe den? **

Anvendere af STS skal sættes op og tilføjes til STS konfiguration, inden de kan begynde at anvende udstedelses- og omvekslingsservices ** CHG: Nej, kun de nyere STS-snitflader kræver klient-whitelisting. Det bør angives på snitflade-niveau hvilke der gør - måsk kunne man jo erstatte 'Sikkerhedsniveau' kolonnen med 'Kræver whitelisting' eller lignende i ovenstående? **. Anvendere identificeres vha CVR nummer, som er inkluderet i OCES certifikater. Når en anvender autentificerer sig overfor STS vha et OCES certifikat, så konsulterer STS sin konfiguration og tjekker, om det pågældende CVR nummer er konfigureret, og om det f.eks. har adgang til det specificerede intended audience. De specifikke valideringer og regler gennemgåes i afsnitene nedenfor vedr DGWS, medarbejderomvekslinger og borgeromvekslinger.

...