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.
Thomas Nilsson
