Introduktion

...

Formål med dokumentet

Formålet med dette dokument er at give en detaljeret beskrivelse af de konkrete services, der udbydes af STS i forbindelse med anvendelsesområdet Medarbejdromvekslinger.

...

Læsevejledning

Dokumentet henvender sig primært til udviklere, der skal i gang med at anvende de konkrete medarbejdervekslingssnitflader udbudt af STS.

Dokumentet bygger i høj grad på den overordnede STS - Guide til anvendere, som giver et overblik over STS og levere i denne sammenhæng et mere dybdegående teknisk beskrivelse af de services i STS, der ligger i anvendelsesområdet medarbejderomvekslinger.

...

Overblik over services og anvendelse

Som beskrevet i STS - Guide til anvendere, så findes der i STS følgende services indenfor anvendelsesområdet medarbejderomvekslinger:

Fælles for begge snitflader er, at STS validerer signaturen på indkommende forespørgsler. Det tjekkes, at forespørgslen er signeret med et gyldigt (ikke udløbet, ikke spærret) certifikat. Derudover tjekkes det, at sikkerhedsbilletter, der er en del af forespørgslen ligeledes er signeret med et gyldigt (ikke udløbet, ikke spærret)

...

certifikat.

Valideringer i forbindelse med veksling fra SOSI Idkort til OIO SAML

Udover at indeholde et gyldigt SOSI Idkort på niveau 3 eller 4 (dvs. baseret på et MOCES-, VOCES- eller FOCES-certifikat) som input til omvekslingen, vil omvekslingsrequests af denne type indeholde:

• Audience: Dvs. navnet på den webaplikation, som det udstedte token skal gælde for.

Det angivne audience skal være konfigureret i STS'en.

Gyldige requests vil resultere i udstedelse af en OIO SAML sikkerhedsbillet signeret af STS og rettet mod den angivne webapplikation. Oplysningerne i denne sikkerhedsbillet er baseret på oplysningerne i SOSI Idkortet, samt suppleret med information fra STSens konfiguration for det givne audience.

En del af denne audience-konfiguration er:

• Den modtagende webapplikations offentlige nøgle: Den udstedte OIO SAML billet krypteres med denne, så det kun kan dekrypteres og anvendes af modtagerapplikationen.
• Angivelse af, om det vekslede SOSI Idkort skal være en del af den udstedte sikkerhedsbillet: Ved at indlejre SOSI Idkortet giver det mulighed for, at modtagerapplikationen kan foretage kald til NSPs services på vegne af den kaldende bruger.

Billetomvekslingen kan således anvendes af alle med adgang til NSP. Men kan kun veksle til en assertion som giver adgang til et system kendt og konfigureret i STS.

Valideringer i forbindelse med veksling fra OIO SAML til SOSI Idkort

Der er følgende krav til requests til denne omvesklingsservice:

• Medarbejderens CPR-nummer skal enten være angivet i forespørgslen eller kunne bestemmes ud fra certifikatet. Hvis CPR nummeret er medsendt i requestet, så vil STS validere dette udfra RID i certifikatet vha OCES RID-CPR valideringsservice.
  
• Autorisationsnummer og uddannelseskode skal enten være angivet i forespørgslen eller kunne bestemmes entydigt (ud fra CPR-nummer og autorisationsregister).
• It-system-navn skal være angivet i forespørgslen da dette ikke indgår i et OIO SAML (NemLogin) token.
• Herudover kan man vælge at medsende brugerens fornavn/efternavn i forespørgslen, idet fornavnet ikke kan bestemmes ud fra en OIO SAML sikkerhedsbillet.

Såfremt omvekslingen går godt, vil slutresultatet være et STS-signeret id-kort med oplysninger sammensat fra NemLogin token, supplerende informationer og opslag, som herefter kan benyttes som adgangsbillet til NSP-platformens services.

Claims i forhold til autorisationsnummer og uddannelseskode håndteres på følgende måde:

• Hvis både autorisationsnummer og uddannelseskode er medsendt, verificeres disse via autorisationsregisteret og indsættes i det returnerede id-kort.
• Hvis enten autorisationsnummer eller uddannelseskode er medsendt, verificeres at dette matcher præcis én autorisation i autorisationsregisteret, og denne indsættes i det returnerede id-kort.
• Hvis hverken autorisationsnummer eller uddannelseskode er medsendt, verificeres at brugeren har præcis én autorisation i autorisationsregisteret, og denne indsættes i det returnerede id-kort.

Det er den samme algoritme, som beskrevet i STS - Guide til anvendere: DGWS.TODO

Snitfladebeskrivelser

Afhængig af miljø udstilles tjenesten på:

...

Eksempler på requests

I det følgende gives eksempler på de to typer af requests:

...