onsdag 28 oktober 2009

Prestanda i WS-Security

Jag skrev förra hösten om säkerhet i web services och XML. Tidigare den här månaden skrev jag om SAML 2.0.

Då kan ni förstå hur uppspelt jag blev av att IBM har testat prestanda i WS-Security -- Java Web Services: The high cost of (WS-)Security! Här kommer en sammanfattning.

WS-* för säkerhets skull
WS-* innehåller allehanda tekniker för att säkra dina web services. WS-Security för kryptering och signering av XML, WS-Policy för att förhandla fram säkerhetsnivå mellan klient och server och WS-SecureConversation för att säkra en serie meddelanden mellan klient och server.

Dyra operationer
WS-Security löser de traditionella problemen med meddelandesäkerhet:
  • Confidentiality -- hemlighålla meddelandet mha kryptering
  • Integrity -- försäkra sig om att meddelandet inte manipulerats eller skadats
  • Authenticity -- försäkra sig om att meddelandet kommer från en betrodd avsändare
Men det är dyra operationer.

XML-kryptering handlar om att generera symmetrisk nyckel, kryptera payload, kryptera den symmetriska nyckeln med mottagarens publika nyckel och sen lägga till krypterad nyckel, eget certifikat och information om vilka algoritmer som används i XML:en. Det tar tid och XML:en växer rejält.

XML-signering handlar om att kanonikalisera payload:en (typ "ta bort all white space och alla radbrytningar"), beräkna en checksumma, kryptera den med sin privata nyckel och sen lägga till krypterad checksumma, eget certifikat och information om vilka algoritmer som används i XML:en. Gissa vad? Det tar tid och XML:en växer rejält.

Men hur dyrt är det? Det har IBM tagit reda på.

Testkonfiguration
Testsystemet var en 64-bitars Linux, Java 1.6 från Sun, Tomcat 6, Axis 2 och Rampart 1.5, en säkerhetsmodul för Axis 2. Man körde anropen internt på en maskin för att inte introducera nätverksstrul i mätningarna. 1000 anrop med små svar (blå staplar), 1000 anrop med stora svar (röda/orangea staplar). Mätningarna gjordes med följande konfigurationer:
  • plain: Ingen säkerhet
  • ssl: HTTPS till servern (envägs)
  • username: WS-Security:s UsernameToken i klartext i anropen
  • sign: WS-Security-signering av meddelande och headers, med tidsstämpel
  • encr: WS-Security-kryptering av meddelande
  • signencr: Kombinationen av sign och encr ovan
Signering + kryptering ger 2000 % sämre prestanda
Det visar sig att envägs-SSL har ganska god prestanda, särskilt vid större meddelanden (handskakningen blir mindre andel). Men WS-Security suger enormt med energi -- 2000 % sämre prestanda med både signering och kryptering.

Orsakerna är flera. Först och främst så kräver signeringen att man kanonikaliserar XML:en för att white space inte ska påverka signaturen. Det är en transform som lättast utförs med en DOM vilken i sin tur tar tid att generera. Resten av prestandan går åt till att beräkna checksumma och till symmetrisk kryptering -- båda CPU-krävande operationer.

WS-SecureConversation presterar bättre
WS-SecureConversation är i princip säkerhet för en hel web service-session. Istället för att generera symmetriska krypteringsnycklar och kryptera dem med asymmetrisk nyckel för varje meddelande så kommer server och klient överens om en sessionsnyckel och kör på den. Det minskar både storleken på meddelanden (inget cert och mindre nyckelinfo att skicka) och minskar arbetet med kryptering och dekryptering (bara symmteriskt). Därför presterar WS-SecureConversation bättre än vanlig WS-Security-kryptering:


Hur mycket större blev XML:en?
Hur mycket större blir då din XML av att signera och/eller kryptera den? Ja, ett anropsmeddelande kan blir 12 gånger så stort.


Slutsatser
  • Om dina klienter kopplar direkt till slutmottagaren (inga servrar emellan) och du inte behöver kunna bevisa meddelandets äkthet i efterhand så duger SSL.
  • Om du har mellanliggande servrar så bör du köra WS-Security. SSL:en termineras ju vid första servern och du har inget tätt skydd även om du sätter upp nya SSL-koppel bakåt. Hemliga data riskerar att hamna i loggar och cache:ar utanför din kontroll. Observera att det kan vara data som du inte ens vill ha i dina system -- kreditkortsnummer med efterföljande PCI-DSS-certifiering till exempel.
  • Om du vill kunna bevisa ett meddelandes äkthet (authenticity) så bör du köra WS-Security. Med SSL skulle du få lov att "spela in" hela nätverkssessionen för att kunna bevisa något.
(Det finns möjlighet att skaffa hårdvarustöd för WS-Security, t ex Vordel XML Gateway men det är en annan historia, med en annan prislapp.)

måndag 26 oktober 2009

Säkerhet och Unicode

Globaliserade webbapplikationer, dvs med stöd för världens alla språk, är bra ur användbarhetssynpunkt. Men det har lett till en rad säkerhetsproblem, primärt spoofing och kanonikaliseringsproblem. Ämnet behandlas i "Unicode Technical Report #36 UNICODE SECURITY CONSIDERATIONS av Mark Davis and Michel Suignard och dess refererade rfc:er. Jag serverar er en sammanfattning (med några personliga tillägg).


Tecken visuellt lika varann

Pixelgrafiken har länge gjort att vissa tecken liknar varann, särskilt i låga upplösningar. Till exempel I och l eller O och 0. Också kombinationer av tecken kan lura ögat, exempelvis 'rn' som i vissa typsnitt ser ut som 'm'. Med unicodes över 96.000 tecken så har antalet visuella kollisioner ökat dramatiskt.


Spoofade domännamn

När domännamn tilläts innehålla unicode-tecken och inte bara ASCII (dvs införandet av Internationalized Domain Names, IDN) så öppnades en ny säkerhetsrisk -- spoofade domännamn. Ta till exempel www.projektplаtsen.se och www.projektplatsen.se. Det är inte samma adress! Ser ni skillnaden? OK, jag ger er unicode som hjälp:


www.projektplаtsen.se

0077 0077 0077 002e 0070 0072 006f 006a

0065 006b 0074 0070 006c 0430 0074 0073

0065 006e 002e 0073 0065


www.projektplatsen.se

0077 0077 0077 002e 0070 0072 006f 006a

0065 006b 0074 0070 006c 0061 0074 0073

0065 006e 002e 0073 0065


Det är alltså ett kyrilliskt 'a' som spökar.


De vanligast förekommande spoof-tecknena är de kyrilliska bokstäverna 'асһеіјорѕху' som i många typsnitt är skrämmande lika de latinska 'acheijopsxy'. Teckenkoderna är förstås helt olika:


асһеіјорѕху (kyrilliska)

0430 0441 04bb 0435 0456 0458 043e 0440

0455 0445 0443


acheijopsxy (latin)

0061 0063 0068 0065 0069 006a 006f 0070

0073 0078 0079


Ett specialfall med bärighet på oss i Sverige är 'ä'. I unicode kan det både skrivas som den unika bokstaven 'ä' (unicode 00e4) och som 'a¨' (unicode 0061 0308). Men domännamn måste vara unika efter en så kallad kompatiblitetsnormalisering till ASCII Compatible Encoding, ACE. Det gör att båda varianterna av 'ä' kommer ge samma unika domännamn.


Toppdomänen (.se, .com osv) är fortfarande bara ASCII så där kan inte spoofning ske. Förutsatt att ingen spoofar punkten förstås. Tecknet '·' visas i en del typsnitt som en vanlig punkt.


En .se-domän får enligt IIS innehålla bokstäverna a-z, å, ä, ö, é och ü samt siffrorna 0-9, bindestreck och skrivtecken som förekommer i de officiella svenska minoritetsspråken eller i våra nordiska grannländers språk.


För dem av er som verkligen vill veta vilka tecken som tillåts i IDN så finns unicode.org:s kompletta lista.


Mixed-Script Spoofing

Exemplet med projektplatsen.se hade bokstäver från två alfabet. Spoofning via blandning av olika alfabet kallas mixed-script spoofing. Frågan är om vi borde förbjuda domäner eller text med mixade alfabet? Ska vi t ex förbjuda domännamn med 13 latinska bokstäver plus en kyrillisk som i fallet med projektplatsen.se? Nja. Länder med icke-latinska tecken lever i samma anglifierade värld som vi och vill mixa sina egna bokstäver med latinska, t ex en rysk domän för XML-dokument: XML-документы.com.


Men det kan vara intressant att detektera mixade alfabet i sin indatavalidering. Exempelkod i Java från unicode.org:

/**
* Returns the script of the input text. Script values of COMMON and INHERITED are ignored.
* @param source Input text.
* @return Script value found in the text.
* If more than one script values are found, then UScript.INVALID_CODE is returned.
* If no script value is found (other than COMMON or INHERITED), then UScript.COMMON is returned.
*/
public static int getSingleScript(String source) {
if (source.length() == 0) {
return UScript.COMMON;
}
int lastScript = UScript.COMMON; // temporary value
int cp;
for (int i = 0; i < source.length(); i += UTF16.getCharCount(cp)) {
cp = UTF16.charAt(source, i);
int script = UScript.getScript(cp);
if (script == UScript.COMMON || script == UScript.INHERITED) {
continue;
}
if (lastScript == UScript.COMMON) {
lastScript = script;
} else if (script != lastScript) {
return UScript.INVALID_CODE;
}
}
return lastScript;
}


Single-Script Spoofing

Att spoofa med hjälp av tecken från ett enda språk/alfabet kallas single-script spoofing. Och det finns många möjligheter att spoofa inom ett språk. Ta till exempel skillnanden mellan ett minustecken '-' och ett riktigt bindestreck '‐':


a-b.com

0061 002d 0062 002e 0063 006f 006d


a‐b.com

0061 2010 0062 002e 0063 006f 006d


Det skulle inte mixed-script detection-koden upptäcka. I Sydostasien finns det till och med exempel på tecken som kan kombineras i olika ordning men ger samma visuella text. För er med alla teckentypsnitt installerade så kan ni prova 101c 102d 102f och 101c 102f 102d.


Domännamn från höger till vänster?

Exempelvis arabiska och hebreiska skrivs från höger till vänster, och de tillåts i internationella domännamn. För att hantera texter med en mix av vänster-till-höger och höger-till-vänster (t ex siffror som alltid skrivs vänster till höger) så finns Unicode Bidirectional Algorithm med en specifikation som får quick sort att se ut som Hello World.


Vissa tecken är dessutom riktningsneutrala, till exempel skiljetecken som '.' och '?'. Deras riktning beror på omgivande teckens riktning. Som exempel har vi nedan en domän där ordningen på två arabiska labels i en path byts om en latinsk label kommer med i mitten och "ändrar riktning" på de separerande punkterna:


http://سلام.دائم.com

http://سلام.a.دائم.com


Det här är som upplagt för bidirectional spoofing där man tror att det är en vanlig vänster-till-höger-domän men den egentligen ska läsas höger till vänster. Därför har man man specat följande skall-krav (2. Preparation Overview -> 4 Check bidi):

  • Varje distinkt label i ett domännamn (label3.label2.label1.com) skall bestå av tecken som skrivs vänster-till-höger eller höger-till-vänster, inte både och.
  • Om en label har tecken som skrivs höger till vänster så skall första och sista tecknet vara strikt höger-till-vänster, ej riktningsneutralt.

Snedstreck och sneda streck

Har ni kollat in unicode-tecknet 2044? Så här ser det ut ''. Jaha, kan det vara farligt? Ja, om vi tänker oss följande webbadress ...


www.dinbank.selogincheckUser.jsp?inxs.ch


... så är det inte många som skulle förstå att den tillhör domänen inxs.ch. Den typen av attack sorterar under syntax spoofing och utnyttjar att unicode har tecken som liknar vanliga escape-tecken.


Några andra läskiga tecken

Det finns mer läskigheter. Vad sägs om följande unicode-tecken:

  • 20A8: '₨' som är skrämmande likt 'Rs'
  • 200D: '‍', zero width joiner som inte har något synligt tecken alls (prova att kopiera till en texteditor och "stega" igenom med piltangenterna så märker du att det faktiskt finns ett tecken där emellan fnuttarna)
  • 0000 (dvs null) som funkar utmärkt i Javasträngar men inte syns. Testa koden nedan:
public class NullInStringTester {

public static void main(String[] args) {
String strWithNull = "John" + '\u0000' + "Wilander";
System.out.println("Before replacement: " + strWithNull);
String strNullReplaced = strWithNull.replace('\u0000', 'X');
System.out.println("After replacement: " + strNullReplaced);
}
}

Välj nivå på valideringen

Så hur ska man hantera det här? Ja, Mark och Michel föreslår att man först väljer en av fem nivåer i fallande strikthet:

  • ASCII-Only: Alla tecken måste vara ASCII
  • Highly Restrictive: Alla tecken i varje identifierare eller token ska komma från ett alfabet/språk eller från någon av kombinationerna ASCII + Han + Hiragana + Katakana; ASCII + Han + Bopomofo; eller ASCII + Han + Hangul
  • Moderately Restrictive: Tillåt latinska tecken ihop med andra alfabet/språk förutom kyrilliska, grekiska och Cherokee. I övrigt som Highly Restrictive.
  • Minimally Restrictive: Tillåt valfri blandning av alfabet/språk som exempelvis Ωmega, Teχ, HλLF-LIFE och Toys-Я-Us. I övrigt som Moderately Restrictive
  • Unrestricted: Helt fritt, exempelvis INY.org

Generella tips till programmeraren

Tips till er som skriver kod och ska hantera unicode, till exempel UTF-8:

  • Om du parse:ar nummer och tal -- upptäck siffror från oväntade språk eller i blandning mellan olika språk och varna användaren.
  • Om du definierar format på identifierarere i programmeringsspråk, protokoll och liknande -- använd "Security Profile for General Identifiers".
  • Vid ekvivalenstest av identifierare -- kör transformen Normalization Form KC (NFKC) Compatibility Decomposition followed by Canonical Composition samt toLowerCase() för att nå kanonisk form (exempelkod i Java). Visa användaren de kanonikaliserade identifierarna.
  • Om du konfigurerar typsnitt -- använd en storlek som gör att teckenskillnader syns och se till att omöjliggöra alltför små tecken.
  • Om du stöter på okända eller osupportade tecken -- visa aldrig ett vanligt frågetecken eller inget tecken alls, utan visa teckenkoden i hex eller en svart fyrkant med ett frågetecken i (unicode fffd).

Specifika UTF-8-attacker

UTF-8 är ett av tre format för unicode (de andra är UTF-16 och UTF-32). UTF-8 är av variabel längd så ett tecken kan vara mellan en och fyra bytes.


Innan version 3.0 av unicode så var det tillåtet att tolka UTF-8 utan att den var på kortast möjliga form. Det gav upphov till att UTF-8 och UTF-16 kunde tolkas olika. Numer är det bara kortast möjliga form (shortest form) som gäller.


Om man konsumerar en UTF-8-ström byte för byte och stöter på en otillåten byte så får man inte hoppa över den ihop med kommande byte(s). Det har nämligen använts för att få filter att göra fel. Om vi tänker oss följande html:


<span style="width:100%" ?> onMouseOver=doBadStuff() ...


... där ? representerar den otillåtna byte:en c2. Om vi då kastar c2 ihop med nästkommande byte i tron att det är ett tvåbytes-tecken så kastar vi '>' och onMouseOver hamnar innanför span-taggen.


Dags att sätta punkt

Det är dags att sätta punkt för det här långa blogginlägget. Frågan är bara om jag ska sätta ...

  • 002e (full stop)
  • 3002 (ideographic full stop)
  • ff0e (fullwidth full stop) eller
  • ff61 (halfwidth ideographic full stop)
... som alla ska tolkas som punkt enligt RFC 3490, Internationalizing Domain Names in Applications :).


PS. Vill ni också leka med unicode, testa kanonikaliseringar och rota i regexpar? Kolla då på International Components for Unicode. De har också Javapaket att ladda hem. DS.

onsdag 21 oktober 2009

AppSec Research 2010 Challenge 5

Utmaning fem är publicerad på konferenswikin. Tävla och vinn en biljett till nästa års stora konferens i Stockholm.

Och om ni inte orkar tävla så måste ni i alla fall gå in och provköra exemplet :).

måndag 19 oktober 2009

TLS/SSL Cheat Sheet

Ännu ett OWASP-projekt har levererat -- TLS Cheat Sheet. En guide till hur du implementerar TLS/SSL i din applikation.

"This article provides a simple model to follow when implementing transport layer protection for an application. Although the concept of SSL is known to many, the actual details and security specific decisions of implementation are often poorly understood and frequently result in insecure deployments."

Läs guiden här.

söndag 18 oktober 2009

Orizon 2.0 på AppSec 2010 i Sthlm

OWASP-projektet Orizon -- ett verktyg för källkodsanalys -- gör sig redo för att släppa version 2.0 under AppSec Research 2010 i Stockholm.

"A lot of working will be done starting by today in order to reach a next major bump for Owasp AppSEC 2010 in Stockholm."

Läs mer på deras blogg eller kolla in demon nedan.



torsdag 15 oktober 2009

DDS: Programmera med personnummer, del 2

Det är flera som frågat när del två av mitt bloggande om personnummer i IT-system kommer. Förra bloggposten avslutades med att vi fått in ett personnummer innehållande ett 'Y' och jag gav mig på jakt efter sanningen. Kunde svenskar ha personnummer med bokstäver?

Vem bryr sig?
Varför grotta ner sig i formatet på personnummer? Jo, det är ju just sånt här vi försöker lösa när vi bygger system. Det ska fungera för verksamheten, gå att underhålla och vara säkert. Då måste centrala begrepp redas ut och modelleras rätt i koden.

Vad säger Wikipedia?
Jag började där vi alla börjar när vi har fått ett problem på halsen -- Google :). Wikipedia dyker alltid upp i sökträffarna och de har bra info om personnummer.

Svenska personnummer är hårt reglerade av Folkbokföringslagen §18 och Skatteverket. Så här ligger det till (Å=år, M=månad, D=dag, F=födelsenummer, K=kontrollsiffra):

ÅÅMMDD-FFFK - till och med det år personen fyller 99 år
ÅÅMMDD+FFFK - från och med det år personen fyller 100 år

FFF är udda för män, jämn för kvinnor. Om det inte längre finns något FFF att tilldela för ett visst datum så får man ett personnummer med ett närliggande datum i samma månad.

I datorsystem formateras personnummer som ÅÅÅÅMMDDFFFK -- alltså fyra siffror i årtalet och inget skiljetecken. De två första siffrorna är inte del av det egentliga personnumret och ska därför inte vara med i beräkningen av kontrollsiffran.

Samordningsnummer tilldelas personer som inte är eller har varit folkbokförda i Sverige. De fungerar precis som personnummer men man adderar 60 till dagen, dvs DD är mellan 61 och 91.

Vad gav Google mer?
Wikipedia sa tyvärr inget om bokstäver i svenska personnummer. Några sökträffar senare hittade jag Socialstyrelsens termbank, uppgifter om svenska biobanker och diverse RIV-dokument (Regelverk för Interoperabilitet inom Vård och omsorg). Det spräckte direkt mitt tidsestimat på arbetsuppgiften. Tydligen finns också ...
  • Reservnummer
  • Katastrofnummer
  • Tvillingnummer
  • Försöksperson-id
OMG! Hur såg alla dessa nummer ut och vilka av dem förväntades vi hantera?

Vad säger Skatteverket?
Det var dags att lämna tangentbordet och plocka upp telefonen. Skatteverket var ofta refererade på nätet så jag började där. Växeln slussade mig till en expert som i sin tur slussade mig till überexperten på svenska personnummer -- Selimovic Fahrudin. Han slängde in ytterligare en nummertyp i grytan -- GD-nummer -- och redde sen ut en del:

Personnummer har ett fast format och Skatteverket ser till att det inte slarvas på den fronten. Så dyker det upp några bokstäver i ett svenskt personnummer så är det fel.

Samordningsnummer tilldelas av Skatteverket som på begäran av en myndighet men de har bara funnits sedan år 2000. Innan dess fick samma personer istället så kallat Tilldelat personnummer eller TP-nummer. Men det får inte finnas några bokstäver där heller.

GD-nummer tilldelas av Skatteverket till personer som äger fastigheter i Sverige men inte har något personnummer (t ex inte bor här). Jag fick ringa X gånger till Bolagsverket och sen tillbaka till Skatteverket innan jag fick tydlig information om dem. GD stod tidigare för Gemensamma distriktet och fungerade som en "virtuell kommun" i Stockholm. Numer kan man tillhöra Stockholm eller Malmö och 'GD' står inte för något speciellt. Skattesatsen i GD är 25%.

Bolagsverket har ett gäng dokument som säger att GD-nummer är "ett juridiskt nummer där månad är större än 1, t ex 3020002568". Det är fel. GD-nummer är en löpnummerserie som börjar på "3020" och var i oktober 2009 uppe i 3022xxxxxx. Det har jag också fått bekräftat från Bolagsverket. Hur som helst -- inga bokstäver där heller.

Selimovic ansåg att det kunde finnas två rimliga förklaringar till vårt 'Y' i patientens personnummer. Antingen är det ett finskt personnummer eller så är det ett reservnummer.

Finska personnummer
Tillbaka till Wikipedia som mycket riktigt säger att finska personnummer (egentligen personbeteckning) har antingen en siffra eller en bokstav mellan a och y som kontrolltecken. Patienten kunde alltså vara finsk!

Reservnummer
Reservnummer används huvudsakligen för att kunna koppla ihop patient och vårddokumentation när personnummer eller samordningsnummer saknas eller är okänt. Patienter som behöver någon form av reservnummer är nyfödda, utländska medborgare (arbetande eller turister), asylsökande, medvetslösa patienter, förvirrade patienter med flera.

Det är Socialstyrelsen som har hand om reservnummer så det fick bli ett samtal till dem. Där fick jag till slut tag på Leif Forsberg på Patientregistret som är expert på personnummer i sjukvården. Han berättade att reservnummer tyvärr inte har ett fastlagt format utan att Socialstyrelsen endast gått ut med en rekommendation. De rekommenderar ett korrekt födelsedatum samt minst en bokstav i de fyra sista siffrorna för att man inte ska råka skapa ett befintligt personnummer. Det skulle alltså kunna förklara vår mystiske patient!

Men som utvecklare går det ju inte att programmera utifrån en rekommendation. Jag ville veta hur det verkligen såg ut. Den vänlige Leif erbjöd sig då att göra en statistisk körning på hur reservnumren ser ut. Han hittade tre olika varianter av reservnummer i patientregistret för 2008:
  • Ca 12 000 reservnummer hade en eller flera bokstäver i de fyra sista fälten och korrekt födelsedatum
  • Ca 10 000 reservnummer hade ett nummer som börjar med 50-99 och resten är ett löpnummer av olika sort
  • Ca 3 000 reservnummer var bara ett löpnummer
Vår patient skulle alltså kunna ha ett reservnummer.

Katastrofnummer, tvillingnummer, försöksperson-id?
Alla de andra numren -- katastrofnummer, tvillingnummer och försöksperson-id -- verkar bara vara alternativa benämningar på reservnummer.

Lösning på problemet
När vi kommit så här långt kunde vi konstatera att vi sannolikt inte behövde hantera finska personnummer men eventuellt behövde hantera reservnummer som tydligen inte hade något fastlagt format.

Då kom lösningen -- datakällan meddelade att de inte hade några patienter med annat än siffror i personnumret i databasen. Vi riskerade därmed inte att stänga ute någon med reservnummer eftersom reservnummer inte finns i den aktuella databasen :).

Konklusion
Person-id-begreppet är tydligen inte så enkelt som i högskolans programmeringsuppgifter. Luhn-algoritmen är kul att implementera men verkligheten är ett sammelsurium av strikta regler, rekommendationer, synonyma begrepp, gamla begrepp och hundratals administrativa system.


Jag har uppdaterat svenska Wikipedia med det mesta av det jag kom fram till.

Lycka till där ute!

onsdag 7 oktober 2009

SAML 2.0 -- nu interoperabelt

Det är som bekant alltid en lång resa från standard till kommersiella produkter som kan kommunicera med varann. Ta bara web service-resan med WS-I Basic Profile och det faktum att det fortfarande närmast är raketforskning att få .Net och Java att prata SOAP med varann om man vill applicera WS-security och WS-policy. För ett par dagar sedan togs ett viktigt steg när det gäller att få SAML att fungera interoperabelt.

Vad är SAML?
SAML (security assertion markup language) 2.0 har funnits sen 2004 och används typiskt för single sign-on (SSO) i webbappliktioner och webbtjänster. En så kallad Identity Provider kan med hjälp av SAML utfärda säkerhetspåståenden (security assertions) som ett antal Service Providers kan välja att lita på. Såna säkerhetspåståenden kan vara vem du är, när du autentiserade dig, vilket system du använder med mera.


Två tjänsteleverantörer litar på en identitetsleverantör mha SAML.

Varför SAML?
Man kan vilja använda SAML av flera orsaker:
  • Cross-Domain SSO. SSO löses traditionellt med cookies vilket kräver att alla applikationer och tjänster publiceras under den domän kakan gäller för. För att lösa SSO till olika domäner (cross-domain SSO, CDSSO) så behövs SAML.
  • Interoperabilitet. Olika SSO-tekniker och -produkter fungerar dåligt ihop eftersom de har olika sätt att hantera autentisering och sessioner. SAML är ett standardiserat sätt att lösa det på.
  • Auktorisering och spårbarhet i web services. De säkerhetstekniker man ser i WS-security och WS-policy handlar om skydd av information med hjälp av kryptering och elektroniska signaturer. SAML löser problemet med behörighetskontroll och spårbarhet i web services.
  • Federering. Att hantera identiteter över organisationsgränser är svårt. SAML klarar att samla lokala identiteter till en (eller några) federerade identiteter.
Något nytt under solen?
Så varför skriver jag om en fem år gammal teknik? Jo, för bara ett par dagar sen blev interoperabilitetstesterna av ett antal faktiska SAML-produkter klara!

Liberty Alliance har under sommaren samordnat interoperabilitetstesterna i den nya SAML 2.0 v1.5 eGovernment Profile. Myndigheter i Danmark, Nya Zeeland och USA har arbetat fram testkriterierna. Några exempel på detaljnivån:
  • Service Provider Authentication Request MUST be communicated using HTTP Redirect binding
  • Identity Provider Authentication Response MUST be communicated using HTTP POST binding or SOAP Artifact binding
  • Assertion MUST be signed
Och så var det testresultatet då. Följande produkter deltog i och klarade testerna:
  • Entrust IdentityGuard Federation Module 9.2 och Entrust GetAccess 8.0
  • IBM Tivoli Federated Identity Manager (TFIM) 6.2
  • Microsoft Active Directory Federation Services (AD FS) 2.0
  • Novell Access Manager 3.1
  • PingFederate v6.1
  • SAP NetWeaver Identity Management 7.2
  • Siemens DirX Access V8.1