STS2 integrerer med den fællesoffentlige fuldmagtsløsning.
Dette er en service der aktuelt vedligeholdes af NNIT på vegne af digitaliseringsstyrelsen
Se Arkitektur og løsningsbeskrivelse her: Fuldmagt - Arkitektur og løsningsbeskrivelse
Nedenstående beskriver nogle af de ikke så alment kendte trin.
Initiel bootstrap: Oprettelse af webservice
Dette foretages i nemlogin brugeradminsitrationen https://administration.nemlog-in.dk
1) Registrere et IT system i Nemlog-in systemet jvf. afsnit 6.4 mnanualen
Kan kun foretages af SDS som offentlig myndighed
Et godt navn kunne f.eks. være "Sundhedsdatastyrelsen SecurityTokenService”.
Undervejs vil man blive spurgt om valg af NemLog-in kopmponenter - mit forventning er at der her bør vælges webtjeneste (uden session tjek)
2) Udpege Arosii som IT leverandør for ovennævnte system, jvf. afsnit 6.8 i manualen
3) Endvidere er Netic senere blevet udpeget som IT leverandør. Egentlig bør Arosii ikke have adgang.
4) Udpegelse af tekniske administratorer. Dettet foretages af en underskriftsbemyndiget for IT leverandøren (muligvis kan SDS også gøre det9
Den/de tekniske administratorer skal bruge egen produktions-medarbejdersignatur til at komme ind (tildelt af arbejdsgiver).
5) Teknisk tilslutning af system
Sker ved oprettelse af metadata samt diverse certifikater. Eksisterende meta data samt certifikater fremgår af GUI'en.
Fuldmagter
Fuldmagter oprettes af en borger på borger.dk (man kan selv gå ind på borger.dk og se muligheder).
Administrativt sker en mapning (udført af Nemlogin supporten), der "oversætter" de tildelte rettigheder til permissions - det er disse permisions vi modtager som svar fra servicen.
Seneste opdatering af disse mapninger er sket i SDS-3543 - Getting issue details... STATUS .
I test findes en snitflade i nemlogin administrationen (som vi har adgang til) der kan opsætte test brugere og rettigheder. Det kræver efterfølgende "overførsel til integrationstest" for at få disse rettigheder til at slå igennem.
Administrative opgaver
- Certifikat fornyelser. Simple fornyelser af klient certifikatet kræver tilsyneladende ikke registrering af nyt certifikat hos fuldmagtsservicen. Ved udskiftning er det nødvendigt.
- Ændring af permissions. Typisk hvis nye systemer kommer på, eller der sker andre ændringer. Der skal typisk ske "overførsel til integrationstest" for at få ændringer til at slå igennem i test. Jeg har ikke prøvet at rette i produktion efter initiel deployment, så her er jeg usikker.
Typiske udfordringer
Ved overførsel til integrationstest, knækker vores adgang til fuldmagtsservicen normalt (vi får en art "permission denied"). Dette kan repareres ved at skrive til nemlogin@digst.dk. Vores system er her identificeret som https://saml.sts.nspop.dk
De svarer ind imellem lidt langsomt.
Det er uklart om noget tilsvarende gælder i prod - det har vi heldigvis ikke haft behov for at efterprøve.
Teori: Fuldmagtsservicen er tænkt til at blive kaldt fra et "Web SSO" - mens vi er en simpel webservice. Det formodes at være grunden til der er knas - vi er aktuelt eneste anvender system som ikke er Web SSO.
Et par gange har vi endvidere oplevet fejlbeskeden
code=CallToDanIDFailed message=Exception from DANID component when trying to get verify the certificate.DIGST
Det er en intern fejl i fuldmagtsservicen, som vi ikke kan gøre andet end at rapportere. Det er mit indtryk at den fejl typisk rammer alle anvendere.
Verifikation:
STS kodebasen har en ProcurationWebServiceIT der kan benyttes til at checke direkte kald til fuldmagt i test.