/
Autentiseringstjänsten - lösningsförslag & estimat

Autentiseringstjänsten - lösningsförslag & estimat

Lösningsförslag paket 1 - Autentiseringstjänsten

Lösningsförslaget avser paket 1 - Digital id-kontroll vid personligt besök Reservkort LoA3.

Lösningsförslag

Förändringarna för Autentiseringstjänsten är begränsade till den endpoint varifrån SITHS eID-klienterna (Windows, macOS, Android, iOS) hämtar statusen på sina certifikat. Som del av den endpointen sker evaluering av certifikatets tillitsnivå. Som del av de pågående engagemangen finns behov för att Autentiseringstjänsten ska kunna signalera nya tillitsnivåer till klienterna som inte finns idag, exempelvis “LoA 3 Non-resident”.

Som del av initiativet för “Sweden Connect IdP:n” har ramverktet för tillitsnivåer uppdaterats. Stödet för de nya tillitsnivåerna finns på plats i kodbiblioteket “Common”.

För att Autentiseringstjänsten ska få förmågan att kunna signalera de nya tillitsnivåer behöver Common uppdateras för Autentiseringstjänsten till version >= 5.5.0. I samband med det kommer även beroendet till tjänsten “LoA Admin” byggas bort då tjänsten avses att tas ur drift i ett senare skede. Sedan följer ett arbete för att konfigurerar upp tillitsnivåramverket för Autentiseringstjänstens specifika behov. När rätt konfiguration finns på plats behöver Autentiseringstjänsten justera sina endpoints som använder sig av tillitsnivåramverket. Även en ny endpoint behöver komma på plats för att kunna ge en rikare signalering av tillitsnivåer än det som befintliga endpointen v2 har som förmåga idag.

  • Befintlig endpoint: /api/certificate-status/v1/status: Ingen justering, saknar idag signalering av tillitsnivåer.

  • Befintlig endpoint: /api/certificate-status/v2/status: Kräver justering, signalering idag sker endast via ett numeriskt värde. Nya tillitsnivåer som exempelvis “LoA 3 Non-resident” signaleras som “3”.

  • Ny endpoint: /api/certificate-status/v3/status: Kräver nyutveckling. Föreslås fungera på samma sätt som v2 förutom att signaleringen av tillitsnivå föreslås bli rik, dvs. att Autentiseringstjänsten levererar visningsnamnet på tillitsnivån. För “LoA 3 Non-resident” skulle denna endpoint alltså signalera just “LoA 3 Non-resident”.

Aktiviteter & estimat

Estimatet utgår ifrån det lösningsförslag för paket 1 (Digital id-kontroll vid personligt besök Reservkort LoA3) som gäller per 2024-12-12.

Estimatet ligger enbart till grund för ett budgetunderlag. Det är inte avsett att användas för en tidplan eller underlag för ett åtagande till fast pris.

Summa allt som allt: 400h fördelat på aktiviteter enligt nedan.

  1. Utveckling (Estimat: 100h)

    1. Inkludering av nytt tillitsnivåramverk

    2. Konfigurering av tillitsnivåramverket

    3. Avveckling av integration mot LoA Admin

    4. Justering av befintlig endpoint /api/certificate-status/v2/status

    5. Utveckling av ny endpoint /api/certificate-status/v3/status

  2. Uppdatera Autentiseringstjänstens dokumentation (Estimat: 40h)

    1. Swagger dokumentation 

    2. SAD 

    3. Övrig dokumentation 

  3. Utvecklartestning (Estimat: 50h)

    1. Testning av nya endpointen /api/certificate-status/v3/status

    2. Testning av befintlig endpoint /api/certificate-status/v2/status

  4. Systemtestning (Estimat: 80h)

    1. Skriva systemtester

    2. Skriva utforskande tester (olika testvariationer, felaktiga inmatningar, m.m.) 

    3. Dokumentation (dokumentera testfall, systemtestrapporter, m.m.)

  5. Buggrättning under system- och acceptanstest (Estimat: 40h)

  6. Rättningsrelease (Estimat: 50h)

    1. Utveckling, regressions- och systemtester för en-två rättningsreleaser (paket 1)

  7. Konfigurering av tillitsnivåer i drift (Estimat: 40h)

Lösningsförslag paket 2 - Autentiseringstjänsten

Lösningsförslaget avser paket 2 - Distansutgivning (beställning och aktivering) av mobilt SITHS eID LoA3 med hjälp av svenskt pass eller nationellt ID-kort.

De föreslagna namnen på endpoints i lösningsförslaget är på inget sätt bestämt utom bara ett förslag på hur de skulle kunna kallas. De exakta namnen kan bestämmas i ett senare skede!

Lösningsförslag

Förändringarna för Autentiseringstjänsten är begränsade till registreringsflödet. Det nya flödet kommer se snarlikt ut den befintliga lösningen som finns idag.

Autentiseringstjänsten behöver kunna ta emot ett nytt objekt från mobilklienten under det första steget av registreringsflödet (dagens /connect-anrop). Detta realiseras enklast genom en ny endpoint, förslagsvis med ett namn som /connect-remote eller dylikt. Informationen som Autentiseringstjänsten tar emot från mobilklienten skickas direkt vidare till SITHS eID Portalen för verifiering utan att behandlas av Autentiseringstjänsten i förväg. Den endpointen finns inte hos SITHS eID Portalen idag. För det här dokumentet antar vi att den endpointen kan heta något i stil med /validate-remote-connection.

SITHS eID Portalen kommer därefter ge ett svar till Autentiseringstjänsten som kan leda till två separata fall:

  1. Om verifieringen lyckas kommer SITHS eID Portalen skicka ett svar som indikerar detta till Autentiseringstjänsten. Därefter kommer Autentiseringstjänsten generera en utmaning (challenge) som Autentiseringstjänsten persisterar i databasen tillsammans med idProofingCode som togs emot av mobilklienten för att i andra steget av registreringsflödet hålla koll på vilken registrering det handlar om. Förslagvis persisteras uppgifterna under en ny ConnectionType för att hålla koll på vilket registreringsflöde som ska användas i kommunikationen mot SITHS eID Portalen vid certifikatsregistreringen. Idag finns det ConnectionType ACTIVATE och REGISTER, förslagsvis kallas den nya typen för REGISTER_REMOTE. Dessa uppgifter kommer sparas i endast 5 minuter (i enighet med dagens flöden) och innebär att användaren måste ha registrerat sitt certifikat inom det tidsspannet. Nu kommer Autentiseringstjänsten gå över till att göra samma saker som det existerande connect-flödet gör och bygga det PublicKeyCredentialCreationOptions-objektet som ska skickas till mobilklienterna.

  2. Om verifieringen misslyckas kommer SITHS eID Portalen skicka en felkod som sedan kommer konverteras till ett ApiError-objekt hos Autentiseringstjänsten. Konverteringen görs för att matcha det befintliga mönstret över hur mobilklienterna kommunicerar med Autentiseringstjänsten. ApiError-objektet returneras sedan som svar till mobilklienten. Registreringsflödet avslutas här.

Efter steg 1 ovan väntar Autentiseringstjänsten på att mobilklienten ska bygga det PublicKeyCredentialCreate-objektet. Mobilklienten kommer kunna skicka det till samma /register-endpoint hos Autentiseringstjänsten som finns idag då det inte finns någon skillnad mellan det befintliga och det nya flödet i just det här steget. När Autentiseringstjänsten tar emot objektet påbörjas andra steget av registeringsflödet. Här kommer Autentiseringstjänsten ta ett beslut vilken endpoint hos SITHS eID Portalen som ska anropas baserat på vilken ConnectionType den väntande registreringen har. Handlar det om dagens REGISTER kommer Autentiseringstjänsten ropa på befintliga endpointen /register-certificate. Skulle det dock handla om nya REGISTER_REMOTE typen kommer Autentiseringstjänsten ropa på en ny endpoint som kan ta emot det nya registreringsobjektet som i det nya flödet innehåller bland annat idProofingCode. Endpointen finns inte hos SITHS eID Portalen idag. För det här dokumentet antar vi att den endpointen kan heta något i stil med /register-remote-certificate.

SITHS eID Portalen kommer därefter ge svar till Autentiseringstjänsten som kan leda till två separata fall:

  1. Om registreringen lyckas kommer Autentiseringstjänsten ta emot ett lyckat svar innehållandes användarens publika certifikat. Här kommer Autentiseringsflöden kunna göra exakt samma saker som görs i de befintliga flöden och persistera certifikatet samt att returnera det till mobilklienten. Registreringsflödet avslutas här.

  2. Om registreringen misslyckas kommer Autentiseringstjänsten hantera det på samma sätt som det redan görs i de befintliga flöden. Autentiseringstjänsten kommer generera ett ApiError-objekt som sedan skickas till mobilklienten. Registreringsflödet avslutas här.

Flödesdiagram

Figur 1: Lyckad registrering (/validate-remote-connection och /register-remote-certificate lyckas)

connect-success(2).png

Figur 2: Misslyckad registrering (/validate-remote-connection lyckas och /register-remote-certificate misslyckas)

connect-partial-success(2).png

Figur 3: Misslyckad registrering (/validate-remote-connection misslyckas)

connect-failure(2).png

Akvititeter & estimat

Estimatet utgår ifrån det lösningsförslag för paket 2 (Distansutgivning (beställning och aktivering) av mobilt SITHS eID LoA3 med hjälp av svenskt pass eller nationellt ID-kort) som gäller per 2024-12-02.

Estimatet ligger enbart till grund för ett budgetunderlag. Det är inte avsett att användas för en tidplan eller underlag för ett åtagande till fast pris.

Summa allt som allt: 1250h fördelat på aktiviteter enligt nedan.

  1. Synkronisering med andra parter (ex. ITU, CGI Mobility) kring integrationer (Estimat: 40h)

    1. Synka exakta namn på endpoints som Autentiseringstjänsten ska integrera mot ITU

    2. Synka exakt hur request/response ska se ut mot ITU 

    3. Synkronisering med CGI Mobility kring ny connect-endpoint 

    4. Utvecklingsstöd åt CGI Mobility kring integration mot Autentiseringstjänsten 

  2. Utveckling (Estimat: 160h)

    1. Utveckling av ny endpoint /connect-remote 

    2. Utveckling av integration mot nya endpoints mot SITHS eID Portal 

    3. Ny felhantering i Autentiseringstjänsten för svaren från SITHS eID Portal 

  3. Uppdatera Autentiseringstjänstens dokumentation (Estimat: 80h)

    1. Swagger dokumentation 

    2. ApiError-dokumentation 

    3. SAD 

    4. Övrig dokumentation 

  4. Utvecklartestning (Estimat: 80h)

    1. Testning av nya endpointen /connect-remote 

    2. Testning av integrationen mot SITHS eID Portal 

  5. Systemtestning (Estimat: 250h)

    1. Utforska möjligheten att skapa en order hos SITHS eID Portalen för e2e-testning (manuell och automatisk testning) 

    2. Skapande av mocktjänst 

    3. Skriva systemtester

    4. Skriva utforskande tester (olika testvariationer, felaktiga inmatningar, m.m.) 

    5. Dokumentation (dokumentera testfall, systemtestrapporter, m.m.) 

  6. Buggrättning under system- och acceptanstest (Estimat: 80h)

  7. Bistå ITU och vid behov aktivt delta i icke-funktionella acceptanstester (med ITU som ansvarig) (Estimat: 160h)

  8. Rättningsrelease (Estimat: 200h)

    1. Utveckling, regressions- och systemtester för en-två rättningsreleaser (paket 2)

  9. Bistå ITU vid regressionstest av övriga paket (Estimat: 200h)

Avgränsningar

Ändringar inom detta paket för angränsande områden (ex. mobilklient, SITHS eID Portal) kan påverka detta lösningsförslag och estimat, avgränsas därmed i detta estimat.

Tillkommande eller ändrad funktionalitet inom ramen för andra paket kan komma att påverka detta lösningsförslag och estimat, avgränsas därmed i detta estimat.