Introduktion

Formål med dokumentet

Nærværende dokument henvender sig til nuværende og kommende brugere af STS (Secure Token Service).

Formålet med dokumentet er at give en forståelse af STS som produkt:

• Hvad er STS?
• Hvilke opgaver løser STS?
• Hvordan kommer man som anvender i gang med at bruge STS?

Derudover giver dokumentet et overblik over de af STS understøttede brugsscenarier med udgangspunkt i konkrete eksempler og med links til mere uddybende dokumentation af disse.

Læsevejledning og forudsætninger

Dokumentet henvender sig primært til IT arkitekter, udviklere og forretningskonsulenter med fokus på sikkerhedsinfrastrukturer og applikationssikkerhed i forhold til National Service Platform (NSP).

Det forudsættes at læseren har en forståelse for grundlæggende koncepter og begreber indenfor applikationssikkerhed herunder certifikater (OCES), sikkerhedsprotokoler f.eks. Den Gode Webservice (DGWS), SAML og OIO IDWS og kendskab til sikkerhedsbilletter f.eks. Java Webtokens (JWT), SOSI Idkort og SAML billetter.

Dokumentet vil løbende linke til ekstern dokumentation, hvor dette er relevant.

Hvad er STS?

STS er i dette dokument synonymt med en konkret service. Men STS kan også opfattes som et koncept: I denne sammenhæng står STS for Secure Token Server.

Dette er et kendt begreb indenfor IT sikkerhedsarkitekturer og beskriver en service, hvis formål er

• Udstedelse
• Validering og
• Fornyelse/omveksling af sikkerhedsbilletter.

Ideen med en Secure Token Server er, at der kan opnåes en afkobling mellem serviceanvender og serviceudbyder som illustreret i figuren nedenfor.

Som figuren illustrer, så behøver en serviceudbyder og serviceanvenderen ikke at etablere et kendskab hinanden, inden serviceanvenderen kan gøre brug af serviceudbyderen. Det, at en serviceanvender i kaldøjeblikket er i besiddelse af en sikkerhedsbillet udstedt og signeret af en Secure Token Server, som serviceudbyderen stoler på (trust) er nok til, at serviceudbyderen kan være sikker på, at det er ok at svare på et servicekald. Serviceudbyderen stoler således på serviceanvenderen, fordi serviceudbyderen stoler på Secure Token Server (se pil nr. 4 i tegningen ovenfor).

Serviceanvenderen skal identificerer 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å.

Det er muligt, at serviceanvenderen kan have behov for, at sikkerhedsbilletten indeholder særlige oplysninger, som serviceanvenderen ønsker, at serviceudbyderen skal vide f.eks. for at få adgang til specielle services/data hos serviceudbyderen. Serviceanvenderen kan bede om, at disse oplysninger inkluderes ved at medsende ekstra påstande (claims) i sin forespørgsel til Secure Token Server (pil nr. 1 i tegningen ovenfor).

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

Secure Token Server sammensætter sikkerhedsbilletten og returnerer denne til kalderen (pil nr. 3 i tegningen ovenfor).

Sikkerhedsbilletten kan indeholde en række tekniske oplysninger, der tilsammen definerer gyldigheden af sikkerhedsbilletten. Dette kunne f.eks. være:

• Signatur: En sikkerhedsbillet skal være signeret af den udstedende Secure Token Server. Signaturen kan valideres hos serviceudbyderen ved at sammenholde den med Secure Token Servers offentlige nøgle (trust).
• Udstedelses- og/eller udløbstidspunkt: Sikkerhedsbilletter vil være gyldige i fast defineret tidsperiode. Hvis en serviceanvender ønsker at fortsætte med at betjene sig af serviceudbyderen efter en sikkerhedsbillets udløb, må der udstedes en ny sikkerhedsbillet.
• Sikkerhedsniveau: Det kan give mening at inkludere en indikation af under hvilke omstændigheder en sikkerhedsbillet er blevet tilvejebragt. Er der f.eks. anvendt brugernavn+password eller en 2-faktor login mekanisme til dette. Digitaliseringsstyrelsens NSIS er et eksempel på en sådan klassifikation.

Derudover kan sikkerhedsbilletten indeholde oplysninger (attributter) om serviceanvenderen. Dette kunne f.eks. være

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

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

Selvom formålene for NSP services er forskellige, så har de en række fællestræk f.eks. i forhold til autentificering. 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).

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

• Den gode webservice (DGWS): Sikkerhedsprotokol, der muliggør adgang for systembrugere og adgang for medarbejdere (både med og uden sundhedsfaglig autorsation)
• IDWS: Sikkerhedsprotokol, der muliggør adgang for borgere (evt. med fuldmagt eller for forælder/værge)

I begge tilfælde skal der i kaldet til den konkrete NSP service forevises en sikkerhedsbillet udstedt af NSPs STS. STS arbejder med følgende typer af sikkerhedsbillletter:

• 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)/sikker browseropstart til løsningerne sundhed.dk eller forløbsplaner.dk)

Anvendelse af STS på NSP

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

På NSP er anvenderes autentifikation overfor STS baseret på digitale certifikater. Disse skal overholde den fælles offentlige standard for certifikater kaldet OCES: Offentlige Certifikater til Elektronisk Service. OCES certifikater indeles i fire hovedgrupper, hvoraf de tre anvendes på NSP:

• Medarbejdercertifikat (MOCES): Udstedes til en medarbejder af en virksomhed og anvendes til autentifikation af den person, der udfører en handling ifm. sin ansættelse i virksomheden.
• Virksomhedscertifikat (VOCES): Udstedes til virksomheder og anvendes til autentifikation af selve virksomheden.
• Funktionscertifikat (FOCES): Udstedes til virksomheder og bruges til autentifikation af en applikation, en enhed, en proces eller en service.

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

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 de tre overordnede anvendelsesområder, som er understøttet af STS:

• DGWS
• Medarbejderomveksling
• Borgeromveksling

De enkelte beskrivelser vil have links til mere detaljeret dokumentation.

Overblik over STS

I diagrammet nedenfor vises et overblik over STS.

De af STS udstillede services ses til venstre i tegningen. De enkelte services falder inden for de 3 overordnede områder for STS:

• DGWS (blå): Udstedelse af SOSI Idkort på baggrund af MOCES/VOCES/FOCES
• Medarbejderomveksling (grøn): Veksling af medarbejderbilletter til/fra OIO SAML billetter henholdsvis SOSI Idkort
• Borgeromveksling (gul): Veksling af borgerbilletter til OIO IDWS eller OIO SAML billetter

De viste services i figuren udenfor er uddybet i tabellen nedenfor.

Anvendere af STS skal sættes op og tilføjes til STS konfiguration, inden de kan begynde at anvende udstedelses- og omvekslingsservices. 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.

Som nævnt i de forgående afsnit, så identificerer anvendere sig overfor STS ved hjælp af OCES certifikater. Alle OCES-certifikater udstedes af Nets DanID der varetager denne opgave for Digitaliseringsstyrelsen. OCES certifikater kan tilbagekaldes (revokeres), hvis f.eks. den private nøgle bliver kompromiteret. Tilbagekaldte certifikater publiceres på revokeringslister (CRL = Certificate Revocation Lists). Revokeringslisterne hentes løbende og opbevares i en database (CRL database på tegningen). Oplysningerne vedrørende revokering tjekkes i forbindelse med kald af STS udstedelses- eller omvekslingsservices. Således kan revokerede/spærrede certifikater ikke anvendes til at få udstedt/vekslet sikkerhedsbilletter.

STS indeholder synkroniseret data fra følgende registre:

• Autorisationsregisteret: Angiver sammenhæng mellem CPR numre på sundhedspersoner samt disses autorisationsid(er). Muliggør berigelse af sikkerhedsbilletter med autorisationsid for sundhedspersoner.
• Nationale roller: STS synkroniserer med faste intervaller de i SEB administrerede roller. Denne synkronisering muliggør berigelse af sikkerhedsbilletter med nationale roller for medarbejdere (med/uden lægefaglig autorisation)

STS har også integration til de tre services PID-CPR, RID-CPR og UUID2CPR udbudt af Nets. Denne integration muliggør verifikation af et påstået (claim) CPR nummers sammenhæng med PID, RID eller UUID. Disse egenskaber er f.eks tilstede i MOCES certifikater og OIO Saml sikkerhedsbilletter udstedt af NemLogin.

Digitaliseringsstyrelsens fuldmagtsregister giver borgere i Danmark mulighed for at tildele fuldmagt til venner og pårørende til at opnå dataadgang. Borgere kan vedligeholde deres fuldmagtstildelinger via portalen http://borger.dk. I forbindelse med borgerbilletter har STS via fuldmagtsregisteret mulighed for at tjekke claims om fuldmagt, som angives i forbindelse med omveksling af borgerbilletter.

Anvendelseområder

De ovenfor nævnte anvendelsesområder uddybes i følgende afsnit. Hvert område beskrives kort med hensyn til overordnet formål. Dernæst skitseres flowet indenfor det pågældende område. Hver beskrivelse afsluttes med link til uddybende dokumentation.

Anvendelse: DGWS

STS indeholder to services til udstedelse af SOSI Idkort. Det overordnede formål er, at udstede SOSI Idkort der gør det muligt for anvendere at tilgå DGWS services på National Service Platform f.eks. MinSpærring, DRS eller andre Forretningsservices.

Overordnet set kan der udstedes følgende SOSI Idkort:

• System Idkort: Udstedes på vegne af en "anvenderservice". Kravene til autentifikation overfor STS ved udstedelse er certifikater af typen VOCES eller FOCES.
• Bruger Idkort: Udstedes på vegne af en medarbejder (enten med eller uden lægefaglig autorisation). Kravene til autentifikation overfor STS ved udstedelse er certifikater af typen MOCES.

Anvendernes interaktion med STS i forbindelse med udstedelse af SOSI Idkort er fælles i begge tilfælde:

Pilene på tegningen viser følgende flow:

1. Anvendersystemet bygger et SOSI Idkort indeholdende informationer om brugeren/systemet og signerer det med det certifikat (VOCES/FOCES/MOCES certifikat udstedt af CA rodcertifikatet i den fællesoffentlige føderation).

2. SOSI Idkortet sendes i udstedelsesforespørgsel til STS, der validerer signaturen. Ydermere tjekkes det om certifikatet er spærret (revokeret) for anvendelse. STS konsulterer sin konfiguration for at tjekke, at det konkrete CVR nummer i certifikatet er whitelistet til at kunne trække SOSI Idkort.

3. Korrektheden af attributterne i anvendersystemets SOSI Idkort verificeres af STS. En del af attributterne i SOSI Idkortet vil kunne valideres op i mod det anvendte certifikat. I tilfældet med Bruger Idkort (signeret med MOCES certifikat) vil en del af attributterne være at betragte som claims. Disse attributter valideres på følgende måde (se i øvrigt overblikket over STS ovenfor):

   1. CPR nummer: RID-CPR servicen hos Nets anvendes til at verificere, om et givent CPR nummer hører sammen med et givent RID i det anvendte MOCES certifikat.

   2. Autorisationsnummer: Til dette formål anvendes STS'ens kopi af autorisationsregisteret til at verificere, at det angivne autorisationsnummer hører sammen med det angivne CPR nummer.

   3. Uddannelseskode: Til dette formål anvendes STS'ens kopi af autorisationsregisteret til at verificere, at den angivne uddannelseskode hører sammen med det angivne CPR nummer.

   4. National rolle: Hvis der er angivet en national rolle, så tjekker STS op i mod sin kopi af stamdata, at den pågældende bruger er i besiddelse af den angivne rolle. Hvis en anvender ikke har angivet en national rolle i claim, men den pågældende medarbejder er i besiddelse af netop én nationale rolle vil denne automatisk inkluderes i det udstedet SOSI Idkort.

4. STS opbygger et nyt SOSI Idkort med de samme informationer som det SOSI Idkort, der udgjorde forspørgslen fra anvenderen. Dette Idkort signeres med STS'ens eget certifikat.
5. STS sender det nye SOSI Idkort retur til anvendersystemet, der gemmer dette i brugerens/systemets session.
6. Anvendersystemet anvender det nye SOSI Idkort i forespørgelser mod NSP-komponenter. Bemærk at et SOSI Idkort kan anvendes til flere forespørgelser mod flere forskellige services, så længe det endnu ikke er udløbet.
7. NSP-komponenten verificerer at SOSI Idkort er signeret af føderationens certifikat. Den offentlige nøgle for STS'ens certifikat er kendt af alle komponenter i føderationen.

Der henvises til STS - Guide til anvendere: DGWS for yderligere detaljer.

Anvendelse: Medarbejderomveksling

STS indeholder tre services til brug for medarbejderomveksling:

• Omveksling fra Bruger SOSI Idkort til OIO SAML billet
• Omveksling fra OIO SAML billet til Bruger SOSI Idkort
• Omveksling fra OIO Saml bootstrap token til Bruger SOSI Idkort (en videreudvikling af SOSI sikkerhedsinfrastrukturen så den understøtter MitID, Nemlog-in3 og OCES3)

Som det blev beskrevet i forgående afsnit er formålet med at anskaffe et Bruger SOSI Idkort at få adgang til en eller flere NSP DGWS Services.

Formålet med at fremskaffe en OIO SAML billet vil typisk være at foretage kald i NemLogin føderationen, som kræver OIO SAML billet. Dette kunne f.eks. være at opnå en "sikker browser opstart" for en sundhedsfaglig bruger til sundhed.dk.

Flowet for SOSI Idkort til OIO SAML er vist i diagrammet nedenfor:

Pilene på tegningen viser følgende flow:

1. Anvendersystemet er i besiddelse af et Bruger SOSI Idkort for en given medarbejder. Dette Idkort sendes i en forespørgsel til STS på omvekslingsendpointet. Som en den af forespørgslen angives et audience (dvs en tiltænkt anvendelse af den udstedte billet).
2. STS validerer det indgående SOSI Idkort dvs at det pågældende kort ikke er udløbet, at det er udstedt af en troværdig udsteder (i praksis STS selv) samt, at ingen af de anvendte certfikater i forespørgslen er at finde på de publicerede certifikatspærrelister (CRL). Derudover tjekkes det ønskede audience op i mod STS'ens egen konfiguration. STS arbejder med at konfigureret sæt af lovlige audiences, og det forespurgte audience skal være blandt disse.
3. Hvis forespørgslen er i orden danner STS en OIO SAML billet og underskriver den med sit eget certifikat.
4. Den udstedte OIO SAML billet sendes tilbage til anvendersystemet
5. Anvendersystemet kan nu anvende den udstedte billet til at aktivere services i NemLogin føderationen. I det viste eksempel giver den udstedte billet adgang for medarbejderen til sundhed.dk ved hjælp af en sikker browser opstart.

De to sidste typer af medarbejderomveksling veksler til et Bruger SOSI Idkort. Flowet er illustreret i diagrammet nedenfor.

Pilene på tegningen viser følgende flow:

1. Anvendersystemet er i besiddelse af en OIO SAML billet eller en OIOSAML-baseret bootstraptoken for en given medarbejder (i praksis udstedt af NemLogin). Denne sendes i en forespørgsel til STS på omvekslingsendpointet. Der kan være brug for at det udstedte SOSI Idkort er beriget med flere oplysninger, end dem, der er til stede i den af NemLogin udstedte OIO SAML billet eller bootstraptoken. Disse specificeres af anvendersystemet i en af dette system defineret SAML billet (i praksis kan denne SAML billet betragtes som en holder for anvendersystemets claims)
2. STS validerer den indgående billet (den grønne i diagrammet) dvs at den udstedte billet ikke er udløbet, at det er udstedt af en troværdig udsteder (i praksis NemLogin) samt at ingen af de anvendte certfikater i forespørgslen er at finde på de publicerede certifikatspærrelister (CRL). De supplerende oplysninger (claims) defineret af den af anvendersystemet udstedte SAML billet (den røde i diagrammet) valideres af STS på følgende måde:
   1. Hvis anvendersystemet har definerer et CPR nummer som et claim valideres dette. Det gøres ud fra RID oplysninger i billetten (vha RID-CPR service) hvis de er til stede, ellers ud fra det medsendte medarbejder uuid (vha UUID2CPR service).
   2. Hvis anvendersystemet ikke har defineret et CPR nummer, slås det op med RID-CPR servicen eller UUID2CPR servicen.
   3. Hvis anvendersystemet har claimet en national rolle, så valideres denne.
      1. Hvis BST tokenet har indlejret en liste af nationale roller, valideres i forhold til denne.
      2. Findes rollen ikke i indlejret liste, valideres i forhold til de registrerede stamdata (roller i SEB-registeret).
   4. Hvis anvendersystemet har claimet et autorisationsnummer for medarbejderen, så valideres dette op i mod autorisationsregisteret.
   5. Hvis anvendersystemet hverken har claimet rolle eller autorisation og medarbejderen identificeret i den indkommende billet har netop én autorisation i autorisationsregisteret, vil denne automatisk indsættes i det udstedte SOSI Idkort.
   6. Hvis anvendersystemet hverken har claimet rolle eller autorisation og medarbejderen har netop én national rolle (i enten indlejret liste eller SEB-registeret) og ingen autorisationer, vil denne rolle automatisk indsættes i det udstedte SOSI Idkort.
   7. Hvis anvendersystemet har claimet en lokal (ikke national) rolle, så kopieres denne til det udstedte SOSI Idkort uden yderligere validering.
3. Hvis forespørgslen er i orden danner STS et SOSI Idkort med oplysninger fra hhv OIO SAML billetten og claims og underskriver dette med sit eget certifikat.
4. Det udstedte SOSI Idkort sendes tilbage til anvendersystemet.
5. Anvendersystemet anvender det nye SOSI Idkort i forespørgelser mod NSP-komponenter. Bemærk at et SOSI Idkort kan anvendes til flere forespørgelser mod flere forskellige services, så længe det endnu ikke er udløbet.
6. NSP-komponenten verificerer at SOSI Idkort er signeret af føderationens certifikat. Den offentlige nøgle for STS'ens certifikat er kendt af alle komponenter i føderationen.

Der henvises til STS - Guide til anvendere: Medarbejderomvekslinger for yderligere detaljer.

Anvendelse: Borgeromveksling

Der er to typer af borgeromvekslinger:

• Omveksling fra JWT til OIO SAML sikkerhedsbillet
• Omveksling fra JWT/bootstrap token til OIO IDWS sikkerhedsbillet

Omveksling til OIO SAML sikkerhedsbillet minder i formål og flow om det, som blev beskrevet under Medarbejderomveksling. Der henvises til (slettes) STS - Borger-billetomveksling for yderligere detaljer. Forskellen i borgeromvekslingen til OIO SAML er at inputbilletten til omvekslingen er et JWT. JWT tokenet skal være udstedt af en identity provider, som STS'en stoler på f.eks. loginbrokeren, der anvendes i forbindelse med MinLæge app'en.

Den anden type af borgeromvekslinger veksler JWT eller bootstrap token til OIO IDWS sikkerhedsbillet. Formålet med denne omveksling er at gøre det muligt for anvendere at tilgå borgerrettede IDWS services på National Service Platform f.eks. MinSpærring, Dokumentdelingsservice (DDS) eller Minlog2.

Anvendernes interaktion med STS i forbindelse med borgeromveksling til OIO IDWS sikkerhedsbillet :

Pilene på tegningen viser følgende flow:

1. Anvendersystemet er i besiddelse af en JWT eller bootstrap token for en borger (i praksis udstedt af NemLogin eller loginbrokeren, der anvendes i forbindelse med MinLæge app'en). Denne OIO billet sendes i en forespørgsel til STS på omvekslingsendpointet.
2. Der kan være brug for at det udstedte IDWS token er beriget med flere oplysninger, end dem, der er til stede i JWT eller bootstrap tokenet. Disse specificeres af anvendersystemet som claims i forespørgslen. Følgende claims er relevante:
   
   1. CPR nummer for borgeren
   2. CPR nummer for anden borger, hvis billetten skal bruges til at tilgå  andre borgeres oplysninger
3. STS validerer det indgående JWT/bootstrap billet dvs at den udstedte billet ikke er udløbet, at det er udstedt af en troværdig udsteder samt at ingen af de anvendte certfikater i forespørgslen er at finde på de publicerede certifikatspærrelister (CRL). De supplerende oplysninger (claims) defineret af den af anvendersystemet valideres af STS på følgende måde:
   1. Hvis anvendersystemet definerer et CPR nummer som et claim valideres dette udfra PID (vha CPR-PID service) eller CPR oplysninger i input billetten.
   2. Hvis anvendersystemet har claimet et andet CPR nummer (dvs identiteten på den borger b, som borgeren i pkt a forsøger at tilgå), så vil STS tilgå fuldmagtsregisteret og finde de fuldmagter, der er givet fra borger b til borger a. Listen af disse vil være inkluderet i IDWS tokenet.
   3. Det er obligatorisk at angive et audience for det IDWS token, som ønskes udstedt. Audience angiver, hvilken service, som man har tiltænkt at bruge tokenet mod. STS validere det ønskede audience op i mod sin konfiguration (liste af lovlige audiences). For veksling af JWT tokens bliver det tjekket at det indgående token er i besiddelse af nødvendige scopes (en mapning fra JWT scopes til audiences er konfigureret for STS).
4. Det udstedte IDWS token sendes tilbage til anvendersystemet.
5. Anvendersystemet anvender det nye IDWS token i forespørgelser mod NSP-komponenter. Bemærk at et IDWS token kan anvendes til flere forespørgelser, så længe det endnu ikke er udløbet. Dog er det begrænset, hvilke services det udstedte token kan anvendes til (audience).
6. NSP-komponenten verificerer at IDWS tokenet er signeret af føderationens certifikat. Den offentlige nøgle for STS'ens certifikat er kendt af alle komponenter i føderationen.

Der henvises til STS - Guide til anvendere: Borgeromvekslinger for yderligere detaljer.

Adgang til STS

Når en anvender skal i gang med at bruge STS på NSP skal følgende være på plads:

• Anvenderen skal være i besiddelse af et OCES certifikat (test- hhv produktionsføderationen).
  • Der kan findes test OCES certifikater til at komme i gang med her.
  • Anvendere kan desuden kontakte NETS med henblik på at få en tjenesteudbyderaftale, hvilket vil gøre det muligt at få udstedt egne OCES certifikater til både test og produktion.
• Anvenderen skal oprettes som anvender til STS. Dette gøres i praksis ved at rette henvendelse til servicedesk på nspop.dk. Henvendelsen skal indeholde oplysninger om:
  • Det certifikat/de certifikater, som anvenderen ønsker at benytte i forbindelse med brugen af STS.
  • Angivelse af hvilke omvekslingsservices, der ønsker benyttet.
  • Ekstra informationer (i forbindelse med de enkelte STS services) inkluderes. Brug tabellen nedenfor.