Krav formuleras ofta i termer av (ömsesidig) autentisering, integritet och konfidentialitet, vilket överlåter valet av säkerhetsmekanism till implementatörer och deployers. Det primära användningsfallet för SAML kallas Web Browser Single Sign-On (SSO). En användare använder en användaragent (vanligtvis en webbläsare) begär en webbresurs som skyddas av en SAML-tjänsteleverantör. Tjänsteleverantören, som vill veta identiteten för den begärande användaren, utfärdar en autentiseringsbegäran till en SAML-identitetsleverantör genom användaragenten.
Allmän SAML-säkerhet
Följande avsnitt analyserar säkerhetsriskerna med att använda och implementera SAML och beskriver motåtgärder som miniOrange SAML SSO-plugin/modul använder för att minska riskerna.
- SAML-påståenden:
På nivån för själva SAML-påståendet finns det lite att säga om säkerhetsproblem – de flesta farhågor uppstår under kommunikation i begäran/svarsprotokollet, eller under försöket att använda SAML med hjälp av en av bindningarna. Konsumenten förväntas naturligtvis alltid respektera giltighetsintervallet för påståendet och alla element som finns i påståendet. En fråga på påståendenivån tål dock analys: ett påstående, när det väl har utfärdats, är utom emittentens kontroll. Detta faktum har ett antal konsekvenser. Till exempel har emittenten ingen kontroll över hur länge påståendet kommer att finnas kvar i konsumentens system; Emittenten har inte heller kontroll över de parter som konsumenten/tjänsteleverantören kommer att dela påståendeinformationen med. Dessa farhågor är utöver farhågor om en illvillig angripare som kan se innehållet i påståenden som passerar över tråden okrypterat (eller otillräckligt krypterat). Även om ansträngningar har gjorts för att ta itu med många av dessa problem inom SAML-specifikationen, kommer ingenting i specifikationen att radera kravet på noggrant övervägande av vad som ska läggas i ett påstående. Emittenter bör alltid överväga de möjliga konsekvenserna om informationen i påståendet lagras på en avlägsen webbplats, där den direkt kan missbrukas, eller exponeras för potentiella hackare, eller eventuellt lagras för mer kreativt bedrägligt bruk. Emittenter bör också överväga möjligheten att informationen i påståendet kan delas med andra parter, eller till och med offentliggöras, antingen avsiktligt eller oavsiktligt.
1.1. SAML-protokoll:
Följande avsnitt beskriver säkerhetsöverväganden för själva SAML-förfrågan-svarsprotokollet, bortsett från eventuella hot som uppstår vid användning av en viss protokollbindning.
1.1.1. Förnekande av tjänsten:
SAML-protokollet är känsligt för en DOS-attack (denial of service). Att hantera en SAML-förfrågan är potentiellt en mycket dyr operation, inklusive att analysera förfrågningsmeddelandet (vanligtvis involverar konstruktion av ett DOM-träd), uppslagning av databas/påståendelager (potentiellt på en oindexerad nyckel), konstruktion av ett svarsmeddelande och potentiellt ett eller flera digitala signaturer. Således är ansträngningen som krävs av en angripare som genererar förfrågningar mycket lägre än den ansträngning som krävs för att hantera dessa förfrågningar.
1.1.2. Kräver undertecknade förfrågningar
miniOrange SAML SSO-plugin/modul signs request, begränsar också ordningen för asymmetrin mellan arbetet som utförs av SAML-plugin-programmet och respondern. Det ytterligare arbete som krävs av den som svarar för att verifiera signaturen är en relativt liten procentandel av det totala arbete som krävs av den som svarar, medan processen att beräkna den digitala signaturen representerar en relativt stor mängd arbete för den som begär det. Att minska denna asymmetri minskar risken förknippad med en DOS-attack. Observera dock att en angripare teoretiskt sett kan fånga ett signerat meddelande och sedan spela upp det kontinuerligt och komma runt detta krav. Denna situation kan undvikas genom att kräva användning av XML Signature-elementet som innehåller en tidsstämpel; tidsstämpeln kan sedan användas för att avgöra om signaturen är nyligen. Så ju snävare fönster för giltig signatur är efter svarsfrågan, desto högre säkerhet har du mot återuppspelning av denial of service-attacker.
2. SAML-bindningssäkerhet:
Säkerhetsövervägandena vid utformningen av SAML-förfrågningssvarsprotokollet beror i stor utsträckning på den specifika protokollbindningen (enligt definitionen i SAML-bindningsspecifikationen [SAMLBind]) som används. Bindningarna som sanktioneras av OASIS Security Services tekniska kommitté är SOAP-bindning, Reverse SOAP Binding (PAOS), HTTP Redirect-bindning, HTTP Redirect/POST-bindning och HTTP-artefaktbindning och SAML URI-bindningar. miniOrange SAML SSO-plugins stöder Http-Redirect och Http-POST-bindningar.
2.1. HTTP-omdirigeringsbindning
2.1.2. Denial of Service
Hot: Skadliga omdirigeringar till mål för identitetsleverantörer eller tjänsteleverantörer.
Beskrivning: En falsk enhet kan utfärda en omdirigering till en användaragent så att användaragenten kommer åt en resurs som stör Single Sign-On. En angripare kan till exempel omdirigera användaragenten till en utloggningsresurs hos en tjänsteleverantör vilket gör att huvudmannen loggas ut från alla befintliga autentiseringssessioner.
Motåtgärder: Tillgång till resurser som ger biverkningar specificeras med en övergående kvalificering som måste motsvara den aktuella autentiseringssessionen. Alternativt kan en bekräftelsedialogruta läggas in som förlitar sig på en transient kvalificerare med liknande semantik.
2.2. HTTP POST-bindning
2.2.1. Stulen påstående
Hot: Om en avlyssnare kan kopiera den verkliga användarens SAML-svar och inkluderade påståenden, kan avlyssnaren konstruera en lämplig POST-kropp och kunna utge sig för användaren på destinationsplatsen.
Motåtgärder: Vi upprätthåller konfidentialitet när ett svar kommuniceras mellan SAML SSO-plugin och användarens webbläsare. Detta ger skydd mot att en avlyssnare får en riktig användares SAML-svar och påståenden. Om en avlyssnare motverkar de åtgärder som används för att säkerställa konfidentialitet, finns ytterligare motåtgärder tillgängliga:
● Identitetsleverantörens och tjänsteleverantörens webbplatser BÖR göra några rimliga ansträngningar för att säkerställa att klockinställningarna på båda platserna skiljer sig med högst några minuter. Många former av tidssynkroniseringstjänster är tillgängliga, både över Internet och från egna källor.
● När en icke-SSO SAML-profil använder POST-bindningen måste den säkerställa att mottagaren kan utföra subjektbekräftelse i tid. För detta ändamål MÅSTE en SAML-autentiseringspåstående för huvudmannen inkluderas i det POSTade formulärsvaret.
● Värden för NotBefore- och NotOnOrAfter-attributen för SSO-påståenden BÖR ha den kortaste möjliga giltighetsperioden förenlig med framgångsrik kommunikation av påståendet från identitetsleverantören till tjänsteleverantörens webbplats. Detta är vanligtvis i storleksordningen några minuter. Detta säkerställer att ett stulet påstående endast kan användas framgångsrikt inom en kort tidsram.
● MiniOrange SAML SSO-plugin kontrollerar giltighetstiden för alla påståenden som erhållits från identitetsleverantörens webbplats och avvisar utgångna påståenden. Vi väljer att implementera ett striktare giltighetstest för SSO-påståenden, som att kräva att påståendets IssueInstant- eller AuthnInstant-attributvärde ska ligga inom några minuter från den tidpunkt då påståendet tas emot på tjänsteleverantörens webbplats.
● Om ett mottaget autentiseringsmeddelande innehåller en element med användarens IP-adress, KAN tjänsteleverantörens webbplats kontrollera webbläsarens IP-adress mot IP-adressen som finns i autentiseringsmeddelandet.
2.2.2. Förfalskat påstående
Hot: En illvillig användare, eller webbläsaranvändaren, kan förfalska eller ändra ett SAML-påstående.
Motåtgärder: Webbläsaren/POST-profilen kräver att SAML-svaret med SAML-påståenden signeras, vilket ger både meddelandeintegritet och autentisering. MiniOrange SAML SSO-plugin verifierar signaturen och autentiserar utfärdaren.
2.2.3. Webbläsartillståndsexponering
Hot: Webbläsaren/POST-profilen innebär uppladdning av påståenden från webbläsaren till en tjänsteleverantörs webbplats. Denna information är tillgänglig som en del av webbläsarens tillstånd och lagras vanligtvis i beständig lagring på användarsystemet på ett helt osäkrat sätt. Hotet här är att påståendet kan "återanvändas" vid någon senare tidpunkt.
Motåtgärder: Påståenden som kommuniceras med denna profil måste alltid ha kort livslängd och bör ha en SAML påstående element. Tjänsteleverantörers webbplatser förväntas säkerställa att påståendena inte återanvänds.
2.2.4. Spela
Hot: Replay-attacker innebär att formuläret skickas in igen för att få tillgång till en skyddad resurs på bedrägligt sätt.
Motåtgärder: MiniOrange SAML SSO-plugin kräver att de påståenden som överförs har engångsegenskapen, vilket förhindrar att replay-attacker lyckas.
2.2.5. Ändring eller exponering av statlig information
Hot: Relätillståndsmanipulation eller tillverkning. Vissa av meddelandena kan innehålla en element, som rekommenderas att vara integritetsskyddat av producenten och eventuellt sekretessskyddat. Om dessa metoder inte följs kan en motståndare utlösa oönskade biverkningar. Dessutom, genom att inte sekretessskydda värdet av detta element, kan en legitim systemenhet oavsiktligt exponera information för identitetsleverantören eller en passiv angripare.
Motåtgärd: Följ rekommenderad praxis för att skydda RelayState-data med konfidentialitet och integritet. Obs: Eftersom värdet av detta element både produceras och konsumeras av samma systemenhet, kan symmetriska kryptografiska primitiver användas.
3. SAML-profilsäkerhet
SAML-profilspecifikationen [SAMLProf] definierar profiler för SAML, som är uppsättningar regler som beskriver hur man bäddar in SAML-påståenden i och extraherar dem från ett ramverk eller protokoll.
3.1. Webbläsares profiler för enkel inloggning (SSO).
Observera att användarautentisering på källplatsen uttryckligen är utanför omfattningen, liksom problem relaterade till denna källwebbplatsautentisering. Nyckeltanken är att källsystemets enhet måste kunna försäkra sig om att den autentiserade klientsystemenheten som den interagerar med är densamma som den i nästa interaktionssteg. Ett sätt att åstadkomma detta är att dessa inledande steg utförs med TLS som ett sessionslager under protokollet som används för denna initiala interaktion (troligen HTTP).
3.1.1. SSO-profil
3.1.1.1. Meddelandeändring
Hot: Möjligheten att ändra meddelandena i strömmen finns för denna uppsättning profiler. Några potentiella oönskade resultat är följande:
● Ändring av den ursprungliga begäran kan resultera i avslag hos SAML-utgivaren, eller
skapande av en artefakt riktad mot en annan resurs än den begärda
● Ändring av artefakten kan resultera i denial of service hos SAML-konsumenten.
● Ändring av själva påståendena under transporten kan resultera i alla typer
av dåliga resultat (om de är osignerade) eller denial of service (om de är signerade och
konsumenten avvisar dem).
Motåtgärder: För att undvika meddelandemodifiering behöver trafiken transporteras med hjälp av ett system som garanterar meddelandeintegritet från slutpunkt till slutpunkt. För webbläsarbaserade profiler är den rekommenderade metoden för att tillhandahålla meddelandeintegritet under överföring användningen av HTTP över TLS/SSL med en chiffersvit som tillhandahåller dataintegritetskontroll.
3.1.2. Enkel utloggningsprofil
Hot: Passiv angripare kan samla in en rektors namnidentifierare. Under de första stegen kan en passiv angripare samla in information när den utfärdas i omdirigeringen. Att exponera dessa data utgör ett integritetshot.
Motåtgärder: Alla utbyten bör utföras över en säker transport som SSL eller TLS.
Hot: En osignerad kan injiceras av en falsk systemenhet som därmed nekar uppdragsgivaren service. Om man antar att NameID kan härledas eller härledas så är det tänkbart att användaragenten kan styras att leverera en tillverkad meddelande.
Motåtgärder: miniOrange SAML SSO plugin/modul signerar meddelande. Identitetsleverantören kan också verifiera en huvudmans identitet i avsaknad av en undertecknad begäran.
3.2. Namn Identifier Management Profiler
Hot: Tillåt systemenheter att korrelera information eller på annat olämpligt sätt avslöja identitetsinformation, vilket skadar integriteten.
Motåtgärder: IDP måste se till att använda olika namnidentifierare med olika tjänsteleverantörer för samma huvudman. IDP:n bör kryptera namnidentifieraren som den returnerar till tjänsteleverantören, så att efterföljande interaktioner kan använda en ogenomskinlig identifierare.
3.2.1. Attributprofiler
Hot relaterade till bindningar associerade med attributprofiler diskuteras ovan. Inga ytterligare profilspecifika hot är kända.
4. Sammanfattning
Säkerhet och integritet måste hanteras på ett systematiskt sätt, med tanke på mänskliga frågor som sociala ingenjörsattacker, policyfrågor, nyckelhantering och förtroendehantering, säker implementering och andra faktorer ligger utanför detta dokuments omfattning. Säkerhetstekniska lösningar har en kostnad, så krav och policyalternativ måste också betraktas som ett ”måste” juridiska och regulatoriska krav. Detta icke-normativa dokument sammanfattar allmänna säkerhetsfrågor och tillvägagångssätt samt specifika hot och motåtgärder för användning av SAML-påståenden, protokoll, bindningar och profiler på ett säkert sätt som upprätthåller integriteten. Normativa krav specificeras i de normativa SAML-specifikationerna.
