Ett nytt krig relaterat till IT-infrastrukturen tornar
upp. Denna gång handlar det inte bara om teknik utan snarast en
blandning av både hårda och mjuka ting nämligen SmartCards och PKI.
Då slogs kabelsystemsaktörerna, LAN-aktörerna och protokoll
aktörerna. Om de hade gått IBM's väg hade vi haft IBMs kabelsystem,
TokenRing och kört APPC/APPN. Marknaden valde RJ45 kontakten,
Cat5/6-kabeln, Ethernet och TCP/IP. Detta kanske inte är i samma
storleksordning och i samma omfattning som det kring
kommunikationsplattformen som utspelade sig ca 1985-1995, men det
har större påverkan än vad vi kanske tror vid en första
anblick.
I takt med att stark autentisering efterfrågas allt oftare och PKI
är ett allt naturligare val så börjar allt fler aktörer kravställa
att kunden/användaren använder en förutbestämd PKI. Vill det sig
riktigt illa så har den egna organisationen en lösning vilken
används vid access till den egna infrastrukturen, ex 802.1x
autentisering, domänpåloggning och vid access till de egna
verksamhetssystemen. De övriga verksamhetssystemen som
organisationen kommer i kontakt med i någon annans regi har valt en
handfull andra PKI'er.
Det som nu utspelar sig ter sig allt annat än bra. Det krävs ett
SmartCard för att vara ansluten till den egna infrastrukturen och
de egna verksamhetssystemen. Vid access till andra
verksamhetssystem i annans regi skall alltså ytterligare ett
SmartCard användas. I bästa fall har du en klientarbetsplats som
klarar flera SmartCard, har ett klientprogram (CSP Cryptographic
Service Provider) som klarar flera kort av sannolikt olika typer
och med olika operativsystem. I sämsta fall, och mest troligt,
uppstår det total anarki med resultat av att en bråkdel fungerar, i
värsta fall helt slumpmässigt
Flera svarar att lösningen är att börja tänka i termer av
identitetsfederering. Jag är en varm förespråkare av federering,
men vad spelar det för roll om den egna organisationens
autentiseringslösning inte är vatten värd. Oavsett federering eller
ej, så måste varje lösning som vill kalla sig för stark
autentisering också leva upp till omvärldskraven.
Aktörerna som förespråkar erkända PKI'er gör det av minst två
orsaker. Dels att de vill säkerställa att den
autentiseringslösningen de väljer uppfyller de högt ställda kraven,
dels begränsa antalet tänkbara lösningar vilket givetvis gör
underhållet enklare. Avsaknaden av federativt stöd i de aktuella
verksamhetssystemen som skyddas av en utpekad PKI leder till att
organisationen som vill nyttja verksamhetssystemet tvingas anamma
PKI med allt vad det innebär med ytterligare ett kort och kanske
ytterligare en CSP. Första gången kanske det sker utan konflikt,
men andra gången eller i konkurrens med den egna PKI'n så är det
sannolikt kört. Det är bara att konstatera att detta är en
återvändsgränd.
Antingen bygger den egna organisationen en PKI värd namnet,
tillser att ha lösningar för federering likt SAML, samt kravställer
att verksamhetssystem som tillhandahålls i annans regi har stöd för
federering och att de accepterar autentisering i nivå med den PKI
ni byggt upp i er egen organisation, vilken självfallet håller
högsta klass.
Eller, förlitar ni er på någon redan etablerad PKI som ni använder
i er egen organisation och som också ligger till grund i
federeringssammanhang. I enstaka fall kan man tänka sig att två
organisationer som förlitar sig på samma PKI inte behöver ta vägen
över en federation.
Federationens baksida, den enda(?), är signeringsproblematiken.
Där förutsätter vi att de sker med den privata delen av vårt
asymmetriska nyckelpar. Helst utförd med det nyckelpar, i god
europeisk anda, som är avsedd för signering. Så väl lagstiftningen
som federeringstekniken kommer sannolikt att finna varandra i detta
avseende, i minst nu när eDelegationen talar uteslutande om
federerade lösningar.
Det är bättre att förekomma, som så många gånger förr. Attackera
utmaningen i de olika skikten precis som vi gjorde i kriget rörande
kommunikationsplattformen. Bestäm hur dina tankar går i detta
avseende. Vill du ha din egen plastbit, med eller utan SIS-märkt
ID-kort, RFID och magnetremsa? Vilket format och vilket
operativsystem vill du ha på kortet? Vilken klientprogramvara vill
du använda? Vill du bygga hela eller delar av din PKI själv? Vilka
krav ställer du på en PKI och ett eventuellt
federationsmedlemskap?
Det är givetvis inte de enklaste frågorna, men agerar du passivt
så har du snart ett knippe kort som förväntas fungera i din
tekniska plattform. Jag kan tänka mig flera angenämare utmaningar
och betydligt mer produktivitetshöjande.
