Anteckningar - Möte med MG 2022-02-18
- Jari Koponen (Unlicensed)
Analytics
Anteckningar för designdialog med MobilityGuard (Per Sondén) i syfte att identifiera lösningsmönster och rätt förutsättningar för standardkomponent för ServiceProvide i webbramverket. Deltagare från Sundsvall var @Jari Koponen (Unlicensed) samt @Andréas Idh (Unlicensed) .
Under mötet landade vi att vi behöver besluta om två delar;
Vilket lösningsmönster som ska användas för de två olika inloggningsscenarion som identifierats.
Hur vi ska hantera extra attribut på en inloggad användare, via federationen eller via applikation som integrerar direkt mot API
Inloggningsscenarion
Vi har identifierat två olika scenarion för inloggning där det finns behov av en federerad lösning;
En medborgare eller företagare ska logga in med e-legitimation
En medarbetare eller annan intern roll loggar in (t ex elev) via AD-konto
En medborgare eller företagare ska logga in med e-legitimation
Medborgare eller företagare loggar alltid in med e-legitimation. Dessa tjänster ska integreras direkt mot IDP i MobilityGuard.
Medarbetar-/elevinloggning
När en medarbetar eller elev loggar in sker det i majoriteten av gångerna från internt nät, antingen via VPN eller direkt på vårt nätverket. I dessa situationer ska Single-Sign-On vara standard som utgångspunkt, annat är avvikelse.
För att uppnå Single-Sign-On behöver ADFS användas, inte MobilityGuard. För att uppnå detta har vi två alternativ:
Alternativ 1:
Låt applikationen avgöra vilken IDP man ska skicka mot baserat på användarens IP-serie. Kräver att man i applikationen måste hantera regelverk som baseras på nätverkssegment.
Alternativ 2:
Skicka alla användare direkt till ADFS oavsett läge, då hanteras majoriteten av inloggningarna som SSO utan någon “studs” mellan IDP:er.
Alternativ 3:
Skicka alla användare direkt till MobilityGuard (OneGate), då kommer majoriteten av inloggningar (som sker från internt nät) behöva ”studsa” via MG som därefter dirigerar användaren vidare till ADFS. Kräver även en del regelkonfiguration i MobilityGuard som ska förvaltas.
Förslag till beslut rörande inloggningsscenarion
För medborgarinloggning ska applikationerna integreras direkt mot IDP i MobilityGuard.
För medarbetar-/elevinloggning ska vi använda lösningsmönstret under alternativ 2. På så vis tar vi hand om den stora majoriteten av inloggningar via korrekt IDP direkt i första försök.
Attribut - Hur populera samt använda profil eller inte?
I federationer har vi valet att sätta upp helt skräddarsydda federationer eller använda attributprofiler som standardiserar t ex namnsättning. Vi står även inför ett val, vad ska vi använda för attribut i federationen, köra light med så lite data som möjligt och populera attribut via applikationen eller populera direkt via federation och föda applikationen via biljetten.
Använda en standardiserad attributprofil eller inte
Det finns ingen anledning för oss att välja en officiell attributprofil då vi hanterar allt internt och kör inte federationer mot andra organisationer över olika domäner. En standardiserad profil är nödvändig vid integrationer över flera domäner men det är inte aktuellt för oss.
Förslag till beslut
Vi gör en light-implementation av federation med så få attribut som möjligt, typ personnummer eller användarnamn samt inloggningsmetod
Vi namnsätter dock attributen utefter Sweden Connect (https://docs.swedenconnect.se/technical-framework/latest/04_-_Attribute_Specification_for_the_Swedish_eID_Framework.html#attributes) för enkelhetens skull
Populering av ytterligare data till en användare sker via applikationen mot koncernens API-infrastruktur
Vi utgår från att kryptera assertions/biljett som standard, detta är inte tvingande men ett bra sätt att öka säkerhet och tänka secure by default så att biljettens innehåll skyddas även lokalt på klienten “at rest” och inte bara “in transit”