Certifikatbaserad inloggning via SITHS, tillämpningsexempel

Transkript

1 Certifikatbaserad inloggning via SITHS, tillämpningsexempel För att logga in i en webbapplikation med hjälp av SITHS-kort och certifikat behöver webservern och applikationen konfigureras för hantering av certifikat. Denna instruktion utgår ifrån att en klient med en fungerande NetID installation och ett aktivt SITHS-kort finns att tillgå. Instruktionen förutsätter också att läsaren är väl förtrogen med IIS och administrationen av denna. IIS webbserver Grundläggande konfiguration i servern för att få tillgång till SITHS-kortets identitetsinformation görs genom att konfigurera en webbserver till att kräva klientautentiserad SSL. En mer grundläggande beskrivning av hur man skapar en https/ssl instans av IIS7 finns på: I detta exempel har en IIS version 7 på Win2008 plattform använts. För IIS version 6 på Win2003 eller äldre är handgreppen och utseendet lite annorlunda, men principen är densamma. Vad ska ske? Installera CA och Server-certifikat Konfigurera IIS att kräva klientcertifikat Konfigurera accessregler baserade på certifikatet Grundinstallation webbserver Webbservern skall kunna prata https (ssl) då autentiseringen utnyttjar SSL-förhandlingen för att plocka upp klienten/användarens certifikatinformation. De grundläggande kraven här är de standardmässiga kraven för att sätta upp en https-website. Förberedelse: Beställ ett webbserver-certifikat från er RA organisation alternativt Inera 1 med rätt hostnamn och domän inlagt. 1 Kontakta Kundstod@inera.se för att ansöka. Nedladdningsbara dokument för ansökan finns på Sid 1/17

2 CA-Cert Installera SITHS CA-certifikat i webbserverns container för betrodda utgivare. 1. Öppna Server Certificates på toppnivån för IIS-servern 2. Installera i Betrodda utgivare/trusted Root Certification Authorities Sid 2/17

3 3. Tryck next/accept tills dess att allt är installerat och klart. Servernycklar Installera servernycklar och certifikat i containern för servercertifikat i IIS 1. Logga in i IIS manager och gå till Server Certificates. 2. Importera PKCS#12 containern som levererats från er RA organisation (alternativt Inera), och mata in det lösenordet. Sid 3/17

4 Observera att IIS cetifikat-import frågar efter en.pfx fil, men att även.p12 filer hanteras om en sådan fil pekas ut. Konfiguration Skapa en site eller uppdatera en existerande site till att använda https/ssl och det importerade SITHS certifikatet. Konfigurera webbservern att kräva klientcertifikat. 1. Logga in i IIS manager Sid 4/17

5 2. Skapa eller editera en https binding 3. Välj det certifikat som skall användas för denna webserver 4. Välj SSL module 5. Kryssa i Require SSL och ändra Client certificates från *IGNORE* till require. Sid 5/17

6 Verifiera 1. Testa genom att surfa till webbservern för att verifiera att servern frågar efter klientens certifikat/nyckel. 2. Ange PIN och kontrollera att en uppkoppling görs och att den vanliga webbapplikationen presenteras. Autenticering i applikationen eller webbsidan Hur applikationen skall tillgodogöra sig den information som IIS-webservern tillhandahåller beror mycket på hur applikationen hanterar inloggning och användarautentisering. Certificate authentication Det enklaste fallet är en grundläggande klientautentisering, där certifikatinformationen översätts till något som den bakomliggande applikationen kan hantera (username/password) Applikationen/webbsidan har inte själv något användarbegrepp baserat på certifikatinnehållet utan förlitar sig helt på att webbservern hanterar detta. Det användarid som IIS ser är det som kopplats till certifikatet i IIS-konfigurationen. Med Microsofts terminologi är detta att använda Client Certificate Mapping Authentication. Här finns det några olika sätt att hantera de användare som skall ha rätt att logga in, om man vill begränsa accessen till en mindre grupp än alla som har ett aktivt och fungerande certifikat. Sid 6/17

7 Microsoft definierar två sätt (egentligen tre om man räknar med AD-integration): 1. One-to-One Client Certificate Mapping One to One är en konfigurering där man definierar vilka enskilda användares certifikat som skall få tillträde. Kommentar: Denna är administrativt besvärlig eftersom varje enskilt certifikat skall konfigureras, och lämpar sig därför bara för små installationer med få användare. 2. Many-to-One Client Certificate Mapping Many-to-One är en wildcard-matchning av utvalda fält i certifikatet, och kan användas för större mängder användare där inga individuella skillnader vad gäller behörigheter finns. (T.ex. Tillåt alla användare som tillhör organisation X) Kommentar: I detta fall sker en statisk mappning mot delar av informationen av certifikatet och kan därför användas för att t.ex. koppla ett OU eller något annat lämpligt fält till ett användar-id/passwd. 3. Active Directory mapping Active Directory Mapping är en mappning där användarens certifikat kontrolleras mot användarens lagrade certifikat i domänens Active Directory. Detta förutsätter att IISservern ingår i en Active-Directory domän, och att användarna hanteras via AD:t. Kommentar: De användare som skall godkännas för applikationen måste här ha sina certifikat lagrade i Active Directory. Detta är en betydligt enklare lösning för administration och användning av resurser med många användare. Förberedande installation Rollen för att utnyttja Client Certificate Mapping är inte default-installerat i en IIS, utan behöver läggas till. a. Server Manager -> Roles -> Web Server (IIS) -> Add Roles b. Bocka för IIS Client Certificate Mapping Authentication c. Install XML-filer För hantering av konfigurationen behöver man editera konfigurationsfilerna direkt, det finns inget GUI-baserat verktyg för detta. De XML-baserade konfigurationerna för IIS:en finns i %WinDir%\System32\Inetsrv\Config För att editera One to One eller One to Many I filen applicationhost.config skall man leta rätt på sektionen: <iisclientcertificatemappingauthentication enabled="false"> </iisclientcertificatemappingauthentication> Och fylla på med information om sin mappning. Noggrannare instruktioner om detta finns i referenslistan nedan. Sid 7/17

8 Alternativ IIS-extension Microsoft har publicerat en IIS Adminstration pack som innehåller en GUI-version av en konfigurationseditor. Denna kan installeras från Den kommer då att dyka upp som en ikon i IIS management delen: IIS Autenticering Konfiguration One-to-One 1. Skapa ett certifikat som IIS en kan använda: Plocka fram det certifikat som skall användas via t.ex. NetID s administration och spara det I Base64-kodat format. NetID exporterar certifikaten i binär-format, så en liten omväg är nödvändig. a) Visa i NetID -> Flik Information -> Kopiera till fil -> Välj Base64 kodad X.509 b) Editera det sparade certifikatet och plocka bort -----BEGIN CERTIFICATE----- och END CERTIFICATE---- raderna. c) Fomattera om texten i certifikatet till en enda rad, genom att ta bort alla radbrytningar. d) Spara till lämplig textfil. 2. Öppna IIS konfigurationseditor och gå till: system.webserver/security/authentication/iisclientcertificatemappingauthentication 3. Sätt enabled till true Sid 8/17

9 4. Sätt onetoonecertificatemappingsenabled till true 5. Editera onetoonemappings 6. Klistra in det base-64 kodade certifikatet i Certifikatfältet. Observera att det måste vara den Base64-kodade versionen av certifikatet, som dessutom Sid 9/17

10 skall vara omformatterad som en enda rad med text. 7. Fyll i username och password som användaren skall kopplas till. 8. Stäng CollectionEditorn 9. Tryck Apply uppe i högra hörnet på Configuration Editorn för att spara ner den ändrade konfigurationen. 10. Verifiera genom att logga in med SITHS-kortet. (Vid fel kommer en 401 Unauthorized att presenteras) Konfiguration Many-to-One Sid 10/17

11 1. Öppna IIS konfigurationseditor och gå till: system.webserver/security/authentication/iisclientcertificatemappingauthentication 2. Sätt enabled till true 3. Sätt manytoonecertificatemappingsenabled till true 4. Editera manytoonemappings och fyll I grunddata om användaren 5. Fyll i Rules-fältet med lämpliga data att matcha mot. Sid 11/17

12 I exemplet ovan har vi alltså satt upp kriteriet att SERIALNUMBER skall matcha OCH att Issuer skall vara SITHS CA TEST v4 Även andra fält i certifikatet kan på samma sätt användas som identifiering. 6. Stäng CollectionEditorn Sid 12/17

13 7. Tryck Apply uppe i högra hörnet på Configuration Editorn för att spara ner den ändrade konfigurationen. 8. Verifiera genom att logga in med SITHS-kortet. (Vid fel kommer en 401 Unauthorized att presenteras) Active directory lagrad certifikatinformation Om en domän är konfigurerad för Certifikatinloggning, kan även en IIS utnyttja detta, för att hantera autentisering och auktorisering av domänanvändaren. Detta kräver att klient och server är del av en domän, och att användaren finns i AD t. Dessa instruktioner förutsätter att en AD domän redan finns konfigurerad. Obs! Active Directory autentisering kan inte användas samtidigt med IIS autentiseringen som beskrivits ovan. Förberedande installation Rollen för att utnyttja Active Directory Client Certificate Mapping är inte default-installerat i en IIS, utan behöver läggas till. a. Server Manager -> Roles -> Web Server (IIS) -> Add Roles b. Bocka för Client Certificate Mapping Authentication c. Install Active Directory Mapping 1. Enabla Client Certificate Mapping I IIS-serverns rootkonfigurationer Home -> Authentication Sid 13/17

14 Enable 2. Installera användarens certifikat i AD t som Name mapping i användarens post. 3. Verifiera genom att logga in med SITHS-kortet. Kerberosbaserad inloggning i IIS I en intranätsmiljö med alla användare i AD t kan den vanliga kerberosbaserade autenticeringen i domänen användas för att skapa en Single Sign On lösning. Kortinloggningen i ADt används som accesskontroll för alla interna resurser i nätet som kan prata kerberos. I denna lösning används inga specifika kortkontroller i IIS en, utan autenticering och auktorisering av användaren sker via Active Directory på samma sätt som i en standardmiljö baserad på username/password. Sid 14/17

15 Revokeringskontroller För att verifiera att revokeringskontroller görs av IIS en kan man titta i EventManagern. 1. Öppna Applications and Service Logs -> Microsoft -> Windows -> CAPI2 2. Högerklick på Operational 3. Välj Enable Log 4. Surfa till IIS en från en Internet Explorer med NetID 5. Högerklick på Operational -> Refresh 6. Dubbelklick på EventID 90 X509 Objects och välj Details fliken. 7. Scrolla ner i texten till dess att rubriken OCSP eller CRL syns. 8. Där borde en text liknande OCSP_BASIC_GOOD_CERT_STATUS eller en motsvarande kod från en CRL check visa att status är OK. Sid 15/17

16 9. Om servercertifikatet är revokerat kommer Explorern att presentera följande sida. Applikationsinloggning I en webbapplikation som i sig själv har ett identitetsbegrepp och en egen användardatabas behöver tillverkaren av applikationen anpassa sin autentisering till den certifikatinformation som IIS tillhandahåller. OBS! En sådan identitetsmappning är en separat lösning per applikation, och här kan endast generella riktlinjer ges. Detaljerna beror på den applikation som skall integreras. För att en applikation skall anpassas till en certifikatbaserad inloggning bör man ta reda på vilka typer av autentisering som applikationen stöder. Kan den autentiseras via AD/Kerberos, LDAP, NTLM eller annan liknande nätbaserad metod bör dessa övervägas i första hand. I andra fall kan applikationen behöva plocka upp innehållet i certifikatet, och själv korrelera det mot applikationens interna användarbegrepp. Alla sådana anpassningar är unika och helt beroende på hur applikationsutvecklarna har konstruerat ID-begrepp, behörighetsdatabas och hur öppna och väldokumenterade de autentiseringsgränssnitt som tillhandahålls av applikationen är. Sid 16/17

17 Referenser 1. Instruktioner One to One CCM: a) 2. Instruktioner Many to One CCM: a) CertificateMappingAuthentication b) 3. Instruktioner AD Mapping: a) b) tificatemappingauthentication Sid 17/17