Page History
...
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 Medarbejderomvekslinger.
Læsevejledning
Dokumentet henvender sig primært til udviklere, der skal i gang med at anvende de konkrete medarbejdervekslingssnitflader medarbejderomvekslingssnitflader 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.
...
Som beskrevet i STS - Guide til anvendere, så findes der i STS følgende services indenfor anvendelsesområdet medarbejderomvekslinger: **CHG: Igen: Drop 'Niveau' kolonnen og angiv evt. her hvorvidt servicen kræver whitelisting - se kommentar i den overordnede guide **
| Medarbejderomveksling | ||
|---|---|---|
| /sts/services/Sosi2OIOSaml | Niveau 4 | Omveksler SOSI Idkort til OIO Saml sikkerhedsbillet rettet mod et specifikt audience, f.eks. sundhed.dk. Bemærk, at det SOSI Idkort, der veksles, skal være udstedt af /sts/services/NewSecurityTokenService |
| /sts/services/OIOSaml2Sosi | Niveau 5 | Omveksler OIO Saml sikkerhedsbillet til SOSI Idkort. Bemærk, at den OIO Saml sikkerhedsbillet, der veksles, skal være signeret af troværdig tredjepart (NemLogin) |
| /sts/services/BST2SOSI | Niveau 4 | Omveksler OIO Saml bootstrap token til SOSI Idkort. Bemærk, at bootstrap token skal være signeret af troværdig tredjepart: Lokal IdP, SEB eller NemLog-in |
Fælles for alle 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 **CHG: Nej, SOSI2OIOSAML requests skal ikke være signerede **. 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.
BST tokens **CHG: Samme kommentar som til borgeromvekslinger: Typen af BST er ikke relevant for anvenderne - drop afsnittet? Betegnselseren OIOH2BST, OIOH3BST og OIO3BST bør ikke forekomme i denne guide, dem kan anvenderne ikke bruge til noget**
BST2SOSI servicen tager imod 3 typer af BST tokens. For hver token udsteder (issuer), konfigureres token typen i tabellen sts_audconf.trustedIdpConfiguration.
Nedenfor ses en oversigt over de 3 tokens og deres attributter.
Attribut | OIOH2BST | OIOH3BST | OIO3BST |
|---|---|---|---|
Issuer (IdP/STS der har udstedt tokenet) | Ja | Ja | Ja |
LoA (Sikringsniveau/AssuranceLevel angivet som NSIS- eller NIST-niveau) | Ja (NIST) | Ja (NSIS) | Ja (NSIS) |
Professional UUID Persistent (Global Employee UUID) | Ja* | Ja | Ja |
RID | Ja* | Nej | Nej |
CPR | Ja | Nej | Ja |
CVR (Organisations CVR-nummer) | Ja | Ja | Ja |
OrgName (Organisations navn) | Ja | Ja | Ja |
Audience (skal indeholde værdien ’SOSI-STS’) | Ja | Ja | Ja |
Nationale roller** | Ja | Ja | Nej |
* OIOH2BST kan indeholde enten en RID eller en global UUID, men ikke begge samtidigt
...
Gyldige requests vil resultere i udstedelse af en OIO SAML sikkerhedsbillet signeret af STS og rettet **CHG: Og krypteret til ** mod den angivne webapplikation. Oplysningerne i denne sikkerhedsbillet er baseret på oplysningerne i SOSI Idkortet, samt suppleret med information **CHG: Hvilke informationer? Er de relevante for anvenderne? ** fra STSens konfiguration for det givne audience.
...
Der er følgende krav til requests til denne omvesklingsservice: **CHG: 'angivet i forespørgslen' er for ukonkret. Fx For OIOSAML2SOSI: Uddyb at der dels selve OIOSAML assertionen (i praksis udstedt af NemLog-in, som er eneste udsteder der trustes), samt en anden, ikke-signeret assertion med kontekst information ... Og at BST2SOSI requests indeholder selve BST (måske i krypteret form) og WS-Trust claims. Jeg vil holde de to snitflader adskildte her ...**
- Medarbejderens CPR-nummer skal enten være angivet i forespørgslen eller kunne bestemmes ud fra certifikatet. **CHG: Det er ikke noget brugercertifikat involveret. Men CPR nummeret fremgår af OIOSAML tokenet **
- Hvis CPR nummeret er medsendt i requestet, så vil STS validere dette enten udfra RID i certifikatet vha OCES RID-CPR valideringsservicen eller udfra medarbejder uuid vha UUID2CPR servicen.
- Hvis CPR nummeret er medsendt i requestet, så vil STS validere dette enten udfra RID i certifikatet vha OCES RID-CPR valideringsservicen eller udfra medarbejder uuid vha UUID2CPR servicen.
- Autorisationsnummer og uddannelseskode skal enten være angivet i forespørgslen eller kunne bestemmes entydigt (ud fra CPR-nummer og autorisationsregister/SEB-register/indlejret role liste).
- 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.
...
Claims i forhold til autorisationsnummer og uddannelseskode håndteres vha algoritmen vist nedenfor: **CHG: Billedet er ret blurry - har I det ikke i bedre kvalitet / som vektorgrafik?**
Snitfladebeskrivelser **CHG: Eller 'Endpoints'? 
**
Afhængig af miljø udstilles tjenesten på:
...