Certifikatsenabla en webbapplikation

Här ser vi ett inte helt ovanligt webbformulär för inloggning klippt från en webbsida. Vi önskar alltså ersätt detta formulär med en certifikatinloggning utan att behöva riva upp himmel och jord. Gör man på detta sätt kan man enkelt få en känsla av SSO, även om det undertill sker en fullständig autentisering med certifikat och kortets privata nyckel

certenable_01

OBS! Att lösa problemet på nedanstående sätt kan kräva OK från IT-avdelningen. Kanske har de andra lösningar på gång, t.ex. en integration baserat på Kerberos eller SAML.

1.
I detta tänkta exempel står en IIS eller Apache med en .Net eller Tomcat-baserad applikationslogik och längst bak en databas med en helt egen hantering av användare.

2.
Först det enkla. Konfigurera webbservern så att den kräver klientcertifikat för att upprätta en SSL-session. Glöm inte att addera de rotcertifikat som ska vara betrodda, se SSL-bilden

certenable_02

certenable_02_IIS7

3.
Testa sedan uppkopplingen med en webbläsare och det aktuella smartkortet. Lyckas inloggningen? Om du använder ett Net iD-paket med SSO aktiverat kan du först logga på en annan site (e-Dos) och där ange PIN. Stäng webbläsaren, öppna den igen och surfa till din nykonfigurerade site, ingen PIN-kod behöver då anges.

4.
Har man kommit såhär långt är det dags att modifiera webbapplikationens inloggningslogik. Inget formulär behöver visas utan man styr användarna direkt till applikationens startsida. Men här uppstår ett problem, certifikaten lär knappast innehålla de användarnamn man tidigare använt. t.ex. jonoho1, jenalm1 och andmos1. Inte heller kommer något lösenord att lämnas till applikationen. Vill man i detta läge slippa integrera mot AD eller annan datakälla utan tills vidare hålla fast vid den bakomliggande kontodatabasen nödgas man skapa en egen mappningslogik baserat på inloggningen via certifikat och SSL. Då bestämmer man sig först vilket fält i klientcertifikaten som ska användas som ID-begrepp. Använder man HCC på SITHS-kort så är troligen HSA-ID det man vill använda. HSA-ID:t är alltid unikt inom SITHS precis som personnummer är unikt för privatpersoner i Sverige. Här ett exempel på Subject/Ämne/Certifikatobjekt med HSA-ID:

T = Konsult
E = jonas.oholm@secmaker.com
SERIALNUMBER = SE2321000016-5G74
G = Jonas
SN = Öholm
CN = Jonas Öholm
O = Stockholms Läns Landsting
L = Stockholms län
C = se

I alla lägen hittas HSA-ID:t på samma ställe i certifikaten. Det gör det enkelt att parsa fram HSA-ID vid inloggningen och skicka detta mot bakomliggande logik. En enkel konverteringstabell är förstås inte helt optimalt men har man bråttom så kan det kanske tillåtas att passera i väntan på en större ”renovering”. T.ex. såhär:

jonoho1 => SE2321000016-5G74
jenalm1 => SE165565594230-11RQ
andmos1 => SE165565594230-11SH

Att parsa fram HSA-ID:t kan göras på flera sätt men ett enkelt ASP-script som nyttjar inbyggd IIS-funktionalitet kan se ut såhär:

certenable_03

certenable_04

Varning för:: Javaapplets laddade via dubbelriktad SSL
En liten varning rörande laddningen av Java Applets från sidor som kräver klientcertifikat. I JRE 1.3 fungerade det som så att appleten laddades över befintlig, av webbläsaren framförhandlad SSL-session. Det var mycket bra. Gör man samma sak med en senare JRE så vill appleten förhandla fram en egen session med en egen och synnerligen illa designad certifikatvalsdialog. Det går dock att lösa med en intrikat cookie-hantering.

certenable_05