Artikel
Val av Identity Provider
Som oberoende konsulter har vi haft förmånen att hjälpa kunder med både val och implementation av en mängd olika lösningar. Vi vill med denna artikel dela med oss av vad vi ser som nyckelfaktorer för att välja rätt IdP, vilket är en central del av din arkitektur och IAM-lösning.
IdP, AS, STS etc, kärt barn har många namn och även om det finns skillnader så väljer vi att i den här artikeln använda IdP som begrepp för den tjänst som du autentiserar dig mot och får dina tokens från.
Baserat på våra erfarenheter behöver man för ett lyckat val reda ut följande frågeställningar:
Vilka tjänster/resurser finns i ditt system?
Hur används tjänsterna?
Vem använder tjänsterna?
Hur finmaskig behörighetskontroll krävs?
Vilka autentiseringsmetoder krävs?
Hur administreras användare?
Hur administreras behörigheter?
Vilken nivå av säkerhet krävs i auktorisationsflöden?
Vilka ramverk finns för de som bygger klienter och tjänster?
Hur behöver användargränssnittet anpassas?
Vilka krav ställs på sessioner?
Vilka krav ställs på drift och monitorering?
Hur förvaltas och utvecklas lösningen?
Vilken licensmodell gäller?
Svaren på dessa frågor beror väldigt mycket på ditt kontext. De grundläggande frågorna är dock de samma. Syftet med denna artikeln är att hjälpa dig att identifiera frågeställningarna. Vår erfarenhet är att denna lista ger bra förutsättningar för en lyckad implementation.
Modellering av identitet
Modellering av identitet och hur du hittar rätt balans mellan central identitet och lokala rättigheter har vi beskrivit i Försvar på djupet – del 1 och 2.
Genom modellering av identitet besvarar vi de fyra första frågeställningarna:
Vilka tjänster/resurser finns i ditt system?
Hur används tjänsterna?
Vem använder tjänsterna?
Hur finmaskig behöver behörighetskontrollen vara?
Detta ger oss "kartan" över vårat system, modellen för vår identitet och genom den vilken information vi behöver från autentiseringstillfället för att ge förutsättningar för en tillräcklig finmaskighet i vår behörighetskontroll hos respektive tjänst.
Tobias Ahnoff
Vi vill understryka vikten av att faktiskt göra denna analys. Du kan inte säkra det du inte förstår. För stora system kan det vara svårt att hålla systemkartan uppdaterad , vi hittar ofta svagheter genom denna inledande analys.
Autentisering och administration av användare
Du behöver tidigt identifiera kraven för autentisering, så du vet att du kan möta dem. Vissa verksamheter styrs av lagar, EU-direktiv eller olika branschstandarder. Till exempel kan det krävas multi-faktor autentisering (MFA). Autentisering är också en viktig del av användarupplevelsen och kan var helt avgörande för t ex en e-handel. Vår erfarenhet är att det tidigt krävs att man förstår dessa krav då det är stor skillnad mellan olika IdP produkter.
Ett vanligt mönster är att din IdP inte utför själva autentiseringen av användare utan nyttjar andra IdP-tjänster för detta, så som "social-logins", Azure AD eller olika typer av E-legitimation genom t ex BankID. Kanske kommer din IdP att utgöra en del av en federerad lösning mellan två eller flera organisationer. Ofta sker dessa integrationer via standardiserade protokoll som OIDC eller SAML, men t ex E-legitimation är det få IdP-produkter som stödjer "out-of-the-box" och du kan behöva hitta en lösning för det.
När du har många klienter är det viktigt att din IdP erbjuder ett bra gränssnitt eller API för att hantera dem. I större skala kan detta t ex hanteras via tilläggsspecifikationer för dynamisk klientregistrering, se t ex https://tools.ietf.org/html/rfc7591
Det är också viktigt att identifiera om man behöver stödja lokala användare, som du i så fall måste administrera på egen hand utan en integration mot en tjänst som ger dig detta (t ex Active Directory eller motsvarande). I så fall behöver du reda ut vilket stöd den IdP-lösning du väljer ger dig för autentisering och administration av dem.
Vilket API behöver din organisation för att t ex skapa och uppdatera konton?
Behövs en kompletterande applikation för administration av konton?
Hur hanteras och lagras lösenord?
Stöds någon form av MFA?
Hur autentisering och lösenord skall hanteras finns väl dokumenterat på OWASP genom ASVS avsnitt V2 [3] och Cheat Sheets [4], [5], [6], [7]. Kom ihåg att dessa krav för med sig implementationskostnader, kanske är det både billigare och bättre att integrera mot t ex en AD-lösning än att bygga själv?
Kasper Karlsson
I penetrationstester ser vi ofta säkerhetsbrister i flöden kring lösenordshantering. Genom att titta närmare på hur lokala lösenord sätts, lagras och återställs får man ofta en ganska god känsla för applikationens allmänna hygiennivå.
Genom att reda ut det här besvarar vi frågorna:
Vilka autentiseringsmetoder krävs?
Hur administreras användare?
[3] https://owasp.org/www-project-application-security-verification-standard/
[4[ https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
[5] https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
[6] https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html
[7] https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html
Administration av behörigheter
Administration av behörigheter ligger nära administration av användare. Men för en förvaltningsbar systemdesign är det viktigt att hålla isär autentisering och behörighetskontroll (auktorisation). Hur du hittar rätt balans beskrivs i Försvar på Djupet, del 1 och 2.
I den här artikeln vill lyfta fram vikten av att inte bygga in domänspecifika rättigheter i din IdP-lösning. En bra tumregel är att du skall kunna byta IdP, protokoll och token-format utan att detta påverkar behörighetskontrollen i respektive tjänst.
Hur behörigheter administreras är viktigt. Brister här kan leda till allvarliga sårbarheter och det gäller det att hitta en lösning som passar din organisation. Det kan t ex variera från att varje tjänst eller deldomän är helt självständig och implementerar detta på egen hand, till att alla tjänster använder någon form av gemensam tjänst för att slå upp behörigheter. Viss information kanske är så central att du väljer att ta med detta från autentiseringstillfället, t ex någon enstaka AD-grupp. För en del verksamheter kanske behörighetsmodellen inte är mer komplex än så och man behöver ingen ytterligare administration.
Tänk på att i ett större system med en komplex behörighetsmodell så krävs det i regel en (eller flera) verksamhetsspecifika applikationer för att administrera behörigheter för alla tjänster. I regel behöver denna applikation ge en tydlig audit-log över hur behörigheter har förändrats över tid, samt ett bra gränssnitt som visar vilken förändring som är på väg att genomföras. Vilket kan vara lättare sagt än gjort, underskatta inte kostnaden för att implementera detta på ett säkert sätt.
Tobias Ahnoff
Underskatta inte kostnaden för att implementera detta på ett säkert sätt. Här blir det väldigt tydligt med vikten av att hitta rätt balans, som möter de krav verksamheten har för administration, drift och förvaltning.
Martin Altenstedt
Ytterligare en viktig aspekt är systemprestanda och hur snabbt du kan revokera behörigheter, en balans mellan många uppslag och cachning, men också vilket gränssnitt du erbjuder för administratörer som spänner över alla tjänster.
Vi har genom detta besvarat frågan: Hur administreras behörigheter?
Auktorisationsflöden och ramverk för klienter och tjänster
Hur en användare kan delegera auktorisation till en klient och vilka flöden som behövs för olika typer av klienter beskrivs i Försvar på djupet - del 3. Det är viktigt att notera att det finns olika protokoll och du behöver använda protokoll som möter dina krav, t ex genom lagar, bransch-standarder, samt stödjer dina integrationer.
Ett exempel på detta är att det finns många IdP-produkter som stödjer OAuth 2 [8] och OIDC [9], men betydligt färre som möter krav inom bank och finans som ges genom t ex FAPI [10]. Kanske är detta skall-krav för dig och då är det viktigt med en IdP som ger dig rätt stöd.
Tobias Ahnoff
Även om du inte är inom bank och finans så är FAPI en utmärkt referens för vad som behövs för att höja nivån av säkerhet från det som ges av OAuth2/OIDC.
Ett annat exempel på krav som är viktiga att fånga upp tidigt är då du behöver stödja flera protokoll på grund av integrationer, t ex i en övergångsperiod mellan SAML och OIDC.
Martin Altenstedt
Vi som varit med några år har sett övergången från WS-* och SAML till OAuth 2 och OIDC, samt alla tillägg till genom t ex OAuth 2.1 och FAPI. Och även om det ser stabilt ut idag, med brett stöd, så börjar man nu prata om "OAuth 3" [11]. Här blir det tydligt hur viktigt det är att inte ha beroenden till protokoll i sina tjänster för att undvika inlåsning. Nya krav kan göra att du blir tvungen att byta protokoll och kanske även IdP.
Styrkan i dessa flöden ligger i autentisering av användare och klient, samt att användaren alltid autentiserar sig mot IdP, ej mot klienten. D v s klienten får aldrig användarens hemlighet. Detta är mycket viktigt vid så kallade "third-party" klienter, men svagheten ligger i den komplexitet som redirects för med sig.
Om du istället har en "first-party" klient så kanske inte OAuth 2 och OIDC är rätt lösning?
Dock är det viktigt att förstå att specialiserade lösningar för inloggning, med lokal inloggning i klienten, göra det svårt att hantera stöd för olika typer av autentisering på ett standardiserat sätt, t ex stark autentisering genom MFA. Även Single Sign On (SSO) är svårt att hantera för den här typen av lösningar.
Notera att OAuth 2 med flödet Resource Owner Password Credentials (ROPC) kan var lockande. Då det gör att standarprotokoll och lösningar med IdP används, vilket t ex ger stöd för SSO. Men ROPC är ej del av OAuth 2.1 och de "best current practices" som finns idag, just på grund av problematiken med lokal autentisering i klienten och att stark användarautentisering ej stöds.
Oavsett lösning är det alltid viktig med bra ramverk för det protokoll som skall användas, så att det är lätt att göra säkra implementationer för de som bygger klienter och tjänster. Detta bör vara konfiguration, ej egen implementation och kod.
Martin Altenstedt
T ex OAuth 2, OIDC och JWT-tokens är lätt att hantera på de flesta plattformar idag, men SAML och WS-Fed kan vara svårare. Så även om det skulle var så att det finns features där som man behöver kanske det totalt sätt inte är rätt val och man kan behöva kompromissa för en bra lösning.
Vi har genom detta besvarat frågorna:
Vilken nivå av säkerhet krävs i auktorisationsflöden?
Vilka ramverk finns för de som bygger klienter och tjänster?
[9] https://openid.net/connect/
[10] https://openid.net/wg/fapi/
[11] https://oauth.net/3/
Sessioner och användargränssnitt
Nästan alltid är det ett krav för din IdP att stödja webb Single Sign On (SSO). De flesta produkter gör det genom någon form av IdP session cookie. Men för att du skall kontrollera åtkomst och när användaren behöver återautentisera sig fullt ut krävs mer än så. För att det skall fungera bra behövs i regel även stöd från din IdP för "Single logout" och "Sliding-sessions". Men stödet för hur SSO-sessioner hanteras varierar mellan produkter och ligger till viss del utanför standarder så som OIDC.
För OIDC är det idag brett stöd för Core-specifikationen medans stödet för tilläggs specifikationer för t ex sessioner och "back-channel-logout" varierar. Stödjer din IdP detta?
De lokala sessionerna mot varje klient äger såklart respektive klient och säkras oberoende av om SSO används eller ej. Men det krävs ett samspel för att ge en bra helhet och användarupplevelse.
Hur sessioner och tokens samspelar beskrivs i vår artikel Klienter och sessioner.
Det är viktigt att undersöka vilka parametrar för tokens och SSO-sessioner som du har möjlighet att påverka och om de t ex gäller för alla eller per klient, så du kan hantera sessioner enligt din kravbild.
Martin Altenstedt
Även här är det viktigt med bra bibliotek för dina klienter så att tokens och sessioner hanteras konsekvent.
Tobias Ahnoff
En sak som är värd att notera är att man (oftast) default får SSO mellan alla klienter (där man loggar in) som litar på samma IdP. Vill du inte det behövs sannolikt extra konfiguration som är unik för din IdP och kan var ett krav som är svårt att möta.
Förutom att sessioner hanteras säkert och ger den åtkomstkontroll vi förväntar oss, så är det också viktigt med användarupplevelsen. Det gränssnitt som visas i samband med login kan vara det som användaren ser först och det är viktigt att det är tydligt så att användaren känner sig trygg.
I valet av IdP är det därför viktigt att du kan:
Anpassa sidor hos din IdP för login och logout. Kan man hantera anpassade consent och val vid logout?
Styra över vilken host din IdP finns på (undantaget "social logins"). Tänk på att användaren redirectas dit, är det lämpligt att lämna klientens topp-domän?
För OIDC finns t ex parametrarna ui_locales och login_hint för att styra språk och förpopulera användarnamn vid autentisering, stödjer din IdP detta?
Innan vi går vidare till nästa område så finns det ytterligare två krav med koppling till sessioner man ofta behöver hantera:
Logga ut någon annan och låsa konto
Agera åt någon, med samma rättigheter (s k Impersonation)
Martin Altenstedt
Den typen av krav är viktigt att få med från början då det kan vara svårt att lösa med en standard-produkts grundfunktioner.
Vi har genom detta besvarat frågorna:
Hur behöver användargränssnittet anpassas?
Vilka krav ställs på sessioner?
[12] https://tools.ietf.org/html/rfc8693
Drift, förvaltning och utveckling
Din IdP är en mycket kritisk tjänst och avgörande för hur stabilt och säkert ditt system blir under drift. Speciellt för ett system med höga säkerhetskrav då det för med sig reference tokens och korta livslängder. Ett par minuters nertid kanske gör hela ditt system otillgängligt, inte bara en given tjänst.
Martin Altenstedt
Vår erfarenhet är att detta ofta är en avgörande punkt i val av produkt, egen drift eller ej, klarar din organisation 24/7 drift? Säkerhet är också tillgänglighet!
Kopplat till det är också licensmodeller t ex per användare eller token-request etc. Det vi vill lyfta fram är att det är viktigt att få med sig hela sin kravbild från början, då vissa produkter kanske inte kan utökas för att möta dina krav eller att det kostar betydligt mer än grundfunktionaliteten.
En IdP behöver precis som övriga tjänster och klienter bidra med den loggning som krävs för spårbarhet och intrångsdetektering. Kan du upptäcka intrång och agera genom att t ex låsa ett konto tillräckligt snabbt?
Kasper Karlsson
När vi utför ett penetrationstest bör din intrångsdetektering ge utslag - annars finns risk att även angripare flyger under radarn.
För den dagliga driften är det viktigt att din IdP stödjer byte av nyckelmaterial för signering av tokens och client credentials för autentisering av klienter.
Rotering av nycklar för signering av tokens är något som din IdP-lösning och ramverk för tjänster och klienter behöver hantera. Men det krävs såklart planering av din organisation så att nycklar roteras i rätt tid.
Att rotera client credentials är en viktig säkerhetsaspekt och något som ofta missas. Vilket API har din IdP för att gör detta återkommande? En grundregel är att varje klient behöver kunna konfigureras med minst två aktiva credentials (av samma sort) så att man kan rotera utan nertid. Även hur du distribuerar client credentials är mycket viktigt, vilket stöd finns för det?
Blickar man framåt är det också viktigt att den valda lösningen hålls uppdaterad och stödjer de protokoll som behövs för ditt system. Det är såklart svårt att veta i förväg, men om du bygger ditt system utan djupa beroenden till protokoll och undviker domänspecifika behörighetsbeslut i din IdP är du väl förberedd.
Vi har genom detta besvarat frågorna:
Vilka krav ställs på drift och monitorering?
Hur förvaltas och utvecklas lösningen?
Vilken licensmodell gäller?
Summering
Det är viktigt att göra denna analys rätt från början. Frågorna är enkla att ställa, men verksamheter är ofta komplexa och svaren kan vara svåra att överföra till en konkret implementation. En felaktig kravbild kan leda till en alldeles för dyr och komplex lösning, eller en för enkel. Det är här tydligt hur mycket säkerhet och arkitektur hänger ihop, säkerhet byggs i flera lager och är inte bara något som du ställer framför dina applikationer. Vi på Omegapoint hjälper dig gärna!
Relaterat innehåll