Tillägg av avsnitt kring Inloggning till Windows och ändring av struktur på sidan.
1.2
2021-02-11
SITHS Förvaltning
Uppdatering av hur spärrkontroll fungerar
1.21
2021-02-15
SITHS Förvaltning
Teknisk beskrivning av SITHS Root CA ersatt av denna sida
1.22
2021-02-22
SITHS Förvaltning
Tillägg av information om plattformskrav för SITHS Admin och Mina sidor
1.23
2021-03-01
SITHS Förvaltning
Tillägg av information om att stänga av strömspartläge och använda så nya kortläsardrivrutiner som möjligt.
1.3
SITHS Förvaltning
Tillägg av rubrik för SITHS Testsida
1.31
SITHS Förvaltning
Mindre textjusteringar och tillägg av spärrlistors giltighetstid för Utfärdande CAs
1.32
SITHS Förvaltning
Tillägg av information om pin-cache.
1.33
SITHS Förvaltning
Lagt till information om Underskrift och Förnyad autentisering utan Net iD Enterprise/Plugin
1.34
SITHS Förvaltning
Uppdaterade informationen om RFID och MIFARE
1.35
SITHS Förvaltning
Lade in avgränsare mellan avsnitt
1.36
SITHS Förvaltning
Lade till länk till Edge i IE11 Mode för både Mina Sidor och SITHS-Admins plattformskrav
1.37
SITHS Förvaltning
Lade till länk till Edge i IE11 Mode för både Mina Sidor och SITHS-Admins plattformskrav
1.38
SITHS Förvaltning
Lade till länkar till information om alternativa sätt att logga in i Windows med SITHS eID-appen och information om begränsad support för användning av SITHS eID-appen tillsammans med virtualiserade klientplattformar (VDI)
1.40
SITHS Förvaltning
Justerade information om olika varianter av inloggning för Windows:
Interaktiv inloggning till Windows-dator
Stöd för ytterligare autentiseringslösningar för inloggning till applikationer efter inloggningen till Windows-datorn
Förtydliganden kring Pin-cache/Pin-SSO
1.41
SITHS Förvaltning
Lade till länk till sida om hur inläsning av SITHS-kort går till på Windows och beskrivningar av de två olika autentiseringslösningarna Out-of-band och Dubbelriktad TLS (mTLS)
2.0
SITHS Förvaltning
Stor ombearbetning av strukturen för sidan
Inledning
Referensarkitekturer för Legitimering och Underskrift
Inera har tillsammans med kommuner och regioner tagit fram arkitekturdokument för hur tjänster med behov av legitimering och underskrift ska integrera mot infrastrukturen för legitimering och underskrift av användare:
Klicka nedan för att läsa mer om Referensarkitekturerna
Referensarkitekturer för Legitimering och Underskrift
Vid användning av SITHS för att legitimera medarbetare krävs att tjänsten implementerar en eller flera av de autentiseringslösningar som erbjuds för att konsumera SITHS e-legitimation. All användning av SITHS e-legitimation för användare bör ske enligt Referensarkitekturen för Identitet och åtkomsthantering
Visa mer information om SITHS Autentiseringslösningar
Lade till information om att PIN-SSO över mTLS också kan etableras vid första inloggningen via out-of-band.
1.02
2023-02-02
SITHS Förvaltning
Lade till lite förtydliganden om SITHS eID för Windows MD-paketering och att dessa innehåller SAC minidriver för att ge stödet för mTLS som autentiseringsmetod.
1.03
SITHS Förvaltning
Gjorde om avsnittet för användardialoger per autentiseringsmetod. Klistrade även in hur pin-dialogen ser ut för underskriftskoden om underskriftscertifikatet anropas via Microsoft CAPI2 för SAC minidriver och hur det ser ut när det anropas via CAPI2 eller webbläsaren och Net iD plugin.
1.04
SITHS Förvaltning
Lade till information om Microsofts turordning för presentation av certifikat vid ceritfikatvalsdialog/API via Microsoft CryptoAPI/CNG vid användning av SAC minidriver
1.05
SITHS Förvaltning
Lagt till information om PIN-SSO för macOS och förtydligat när PIN-SSO är aktuellt mha. en matris.
1.06
SITHS Förvaltning
Borttag av Net iD
Översikt
SITHS har två olika autentiseringslösningar:
Inloggning via dubbelriktad TLS (mTLS):
Användare - för legitimering och underskrift av användare med hjälp av SITHS eID-appen för Windows i MD-paketering
MD-paketen innehåller SAC minidriver som står för stödet för autentiseringsmetoden mTLS
Servrar - för identifiering av tjänster vid kommunikation mellan IT-system
Inloggning via separat säkerhetskanal (Out-of-band): för legitimering och underskrift av en användare med hjälp av SITHS eID-apparna
Dubbelriktad TLS kräver inte någon anslutning för att använda som autentiseringslösning.
För mer information om hur du ansluter till att använda autentiseringslösningen out-of-band se följande länkar:
Denna autentiseringslösning levereras som en del av SITHS eID-appen för Windows.
I denna lösning lagras certifikaten på det smarta kortet och importeras till Windows certifikatlagring. Vid inloggning integrerar sedan tjänsten mot operativsystemets och webbläsarens inbyggda funktioner för att be användaren välja ett certifikat som hen vill använda vid legitimering.
Användardialogerna presenteras primärt av webbläsaren och Operativsystemet och ligger således bortom SITHS kontroll.
På de flesta SITHS-kort finns även Telia e-legitimation som identifierar användaren. Att använda dessa certifikat vid legitimering av användaren är förenat med en avgift för varje legitimering/spärrslagning. För att använda detta krävs ett separat avtal med Telia.
Säkerställ att kortläsaren inte har strömsparläge aktiverat. Detta görs antingen i Datorns BIOS, Via enhetshanteraren eller genom inställningar i drivrutinerna för den enhet som används
Säkerställ att datorn använder så nya drivrutiner som möjligt för kortläsaren och att dessa laddas ner från tillverkaren av kortläsaren istället för via Windows Update
Pin-cache och Pin-SSO
Pin-cache funktionen som används med de flesta lösningar för smarta kort (inkl. SITHS) gör att användaren inte behöver ange pin-kod igen så länge SITHS-kortet sitter kvar i kortläsaren. För att Användaren ska bli helt utloggad från en tjänst måste hen:
Använda tjänstens egen funktion för utloggning
Avlägsna SITHS-kortet från kortläsaren
Utöver detta bör även alla tjänster komplettera med en egen inaktivitetstimeout. Denna hjälper dock inte om användare glömmer att avlägsna sitt SITHS-kort.
Klicka nedan för att läsa mer om Pin-cache och Pin-SSO
Läs mer om Pin-cache och PIN-SSO
Vid användning av SITHS och autentiseringslösningar baserade på dubbelriktad TLS (mTLS) finns funktioner som gör att pin-koden för legitimering inte behöver anges vid varje ny begäran om legitimering/autentisering
Detta är ett måste för användarupplevelsen vid exempelvis inloggning till Windows. Det har också gett ett mervärde vid inloggning till tjänster som inte följer Referensarkitekturen för Identitet- och åtkomsthantering eftersom användaren inte behöver ange sin pin-kod upprepade gånger eller när man ska logga in i en annan tjänst som hanterar autentisering via samma AD-miljö som den AD-miljö som hanterar användarens inloggning till själva Windows-datorn.
I referensarkitekturen baseras Single Sign-On (SSO) upplevelsen på att man utfärdar identitetsintyg som är giltiga för inloggning i flera tjänster som använder samma IdP (enligt standarderna SAMLv2 eller OIDC).
Pin-cache är aktiverad som default enligt:
Applikation
Autentiseringsmetod
PIN-SSO
SITHS eID-app för Windows MD
(MD=Minidriver, dvs. paket som innehåller SAC minidriver för att hantera stödet för autentiseringsmetoden mTLS)
mTLS
Ja
OOB**
Nej
SITHS eID-app för macOS
mTLS
Nej
OOB
Nej
SAC minidriver för Linux
mTLS
Nej
** Pin-cache för mTLS aktiveras både vid första inloggningen med mTLS via SAC minidriver OCH i samband med den första inloggningen användaren gör i SITHS eID-appen över autentiseringslösningar baserade på out-of-band. Out-of-band använder sig dock INTE av pin-cachen själv utan den aktiveras bara för mTLS.
Inloggning via separat säkerhetskanal (out-of-band)
Denna autentiseringslösning kan användas både för SITHS eID på kort och Mobilt SITHS
Denna autentiseringslösning tillhandahålls av själva SITHS eID-appen och baserar sig på att en IdP integrerar mot ett gränssnitt på Autentiseringstjänsten som har en direktkommunikation med SITHS eID-appen. SITHS eID-appen hanterar i sintur inloggning och användardialogen istället för att interaktionen med användaren hanteras av datorns operativsystem och webbläsare.
I denna lösning lagras certifikaten:
För Mobilt SITHS - I den mobila enhetens hårdvarulagring (chip)
För SITHS eID på kort - i datorns minne för användning av SITHS eID-appen så länge kortet sitter i kortläsaren.
Användardialoger för de olika autentiseringslösningarna
Användardialogen skiljer mellan de två autentiseringslösningarna Dubbelriktad TLS och Out-of-band.
Out-of-band - SITHS eID-appen förfogar över majoriteten av användarinteraktionen
Dubbelriktad TLS - Nästan hela användarinteraktionen hanteras av Operativsystemet och webbläsaren
Visa exempel för användardialoger per autentiseringslösning
Out-of-band - SITHS eID på denna enhet
Samma utseende i alla webbläsare.
1 - Val av metod i IdP
2 - Appväxling
3 - Appen startas och användare anger pin-kod eller skannar sin biometri (om mobilt)
Denna användardialog finna bara på Datorer
Den dyker bara upp i vissa webbläsare och kan då se något annorlunda ut beroende på webbläsare
3 - Användare öppnar appen i mobiltelefonen och väljer att skanna QR-kord
4 - Användare skannar QR-kod
5 - Användare anger pin-kod eller skannar biometri
Dubbelriktad TLS/Mutual TLS (mTLS) - SITHS-kort på denna enhet
Här exemplifierat med SITHS eID för Windows MD(SAC minidriver).
Olika certifikatvalsdialog beroende på webbläsare. PIN-dialogen hanteras av Windows användargränssnitt
Turordningen för certifikaten i certifikatvalsdialogen och via Microsoft CryptoAPI/CNG styrs av Windows och presenterar det certifikat som har längst giltighetstid först.
Eventuellt val av metod i IdP
Certifikatväljare: Google Chrome
Certifikatväljare: Microsoft Edge
Certifikatväljare: Internet Explorer 11 och IE11-mode i Edge
Svårt att se vad som är rätt:
Svårt att se vad som är rätt (men lite lättare):
PIN-dialoger (samma för alla)
Legitimering
Underskrift
Applikationer för användning av SITHS e-legitimation
Här hittar du information om och länkar/instruktioner för hur du hämtar de applikationer som användaren behöver vid användning av SITHS e-legitimation: Programvaror och tillbehör för SITHS
Applikationer för out-of-band (SITHS eID-apparna inkl. Mobilt SITHS)
På nedan sidor hittar du information om den nya SITHS eID appen och Mobilt SITHS samt filmer och bilder som ytterligare beskriver Utfärdande av Mobilt SITHS, samt legitimering och underskrift med SITHS eID appen:
Flöden för legitimering och underskrift med out-of-band
Flöden för legitimering respektive underskrift med SITHS eID appen
Legitimering med SITHS eID
Underskrift med SITHS eID
Applikationer för dubbelriktad TLS (mTLS)
SITHS eID-appen för Windows
Från och med version 2.0 av SITHS eID-appen för Windows kommer detta finnas paketeringar som installerar stöd för båda autentiseringslösningarna out-of-band och dubbelriktad TLS (mTLS).
Historiskt har dubbelriktad TLS hanterats med hjälp av klientapplikationen Net iD Enterprise. Det vanligaste är att tjänster som implementerat autentiseringslösningen dubbelriktad TLS för användare som har Net iD Enterprise använder någon eller båda av nedan:
Inbyggd funktionalitet i webbläsaren/applikationen och operativsystemet i kombination med Net iD eller;
Net iD plugin (legacy)
För inloggning med SITHS-kort till Windows eller via MTLS i en webbläsare/egenutvecklad applikation är det rekommenderat och även vanligast att använda inbyggd funktionalitet i operativsystemet i kombination med import av certifikat från SITHS-kortet med hjälp av Net iD Enterprise.
Net iD plugin för legitimering och/eller underskrift med SITHS
Net iD plugin stöds i dagsläget endast på Internet Explorer 11 förutsatt att användarens klientdator tillåter att det körs.
Då Net iD Enterprise inte alltid kommer ingå i Ineras produktutbud rekommenderas tjänster som idag använder Net iD plugin för följande syften hänvisas istället till nya arkitektruella lösningar för att åstadkomma denna funktionalitet:
Begära pin av användaren (förnyad autentisering) - ForceAuthN via IdP Autentisering via SITHS eID. Detta fungerar dock bara för Inloggningsmetoderna SITHS eID
Läs mer om Net iD plugin för legitimering och/eller underskrift med SITHS
Användning av Net iD plugin har med tiden kommit att bli allt svårare att vidmakthålla då webbläsarutvecklarna tagit bort alternativt begränsat stödet för de API:er, NPAPI (Chrome/Firefox) och ActiveX (Internet Explorer), som använts av tredjepartsmjukvaror som Net iD plugin.
Detta förutsätter också att användarens klientdator tillåter körning av ActiveX plugins (disabled by default) och att just SecMakers plugin för Net iD tillåts (default deny). Detta kan styras med hjälp av AD-kontrollerade Grupp principer (GPO).
Underskrift
Underskrift med Net iD är beroende av Net iD plugin och lösningen skiljer sig för varje implementation.
Ineras nya Underskriftstjänst följer specifikationer från Digitaliseringsmyndigheten (DIGG), läs mer här: Underskriftstjänsten
Två stora skillnader när det kommer till underskrifter med hjälp av Net iD plugin och Ineras nya Underskriftstjänst är:
Underskriftslösningen med Net iD plugin blir proprietär för varje tjänst som bygger en integration mot Net iD plugin. Varpå hela ansvaret för den juridiska giltigheten för underskriften vilar på den organisation som utvecklat och/eller beställt utveckling av den tjänst som integrerar mot Net iD plugin för att skapa elektroniska underskrifter
Formatet för själva underskriften hanteras helt av den egna tjänsten. Ineras Underskriftstjänst följer DIGGs specifikationer och använder nationellt och internationellt godkända underskriftsformat.
För support kring användning av Net iD plugin hänvisas kunden till att teckna extra supportavtal med SecMaker som är leverantör av Net iD.
Vid underskrift via Net iD plugin har användaren en annan kod, Underskriftskoden.
Flöde för legitimering med dubbelriktad TLS (mTLS)
Visa flöde för legitimering med dubbelriktad TLS (mTLS)
Flöde för underskrift med Net iD plugin
Flöden för legitimering respektive underskrift med Net iD
Rot- och utfärdarcertifikat (Installation av tillit)
Här hittar du information om SITHS rot- och utfärdarcertifikat, samt vad som gäller kring installation av tillit till dessa: Rot- och utfärdarcertifikat
Spärr och spärrkontroll
Ett certifikat kan spärras för att förhindra vidare användning. Detta kan ske när man ska avsluta sin anställning, när man har tappat bort sitt SITHS eID eller när en server ska avvecklas.
Klicka nedan om du vill läsa mer om hur SITHS spärrkontroll
Visa information om hur spärr fungerar inom SITHS
Beställning och utförande av spärr
En spärr inom SITHS kan utföras enligt följande matris
Aktör/Beställare
Utförare
Metod
Kommentar
Användare
Nationell spärrfunktion hos Telia Kundtjänst
Telefon till 020-32 32 62
Ej funktionscertifikat
Användare
Användare
Mina sidor
Ej funktionscertifikat
Användare
ID-administratör
SITHS Admin
Användare/Innehavare
SITHS Föraltning
SITHS Admin
Vid anmälan om missbruk
ID-administratör
ID-administratör
SITHS Admin
SITHS PA
SITHS Förvaltning
SITHS Admin
Kortproduktion
Kortproduktion
Via API om det är problem att producera kort
Realisering av spärr
När en spärr har begärts av respektive Utförare kan det beroende på metod för kontroll ta en viss tid innan ett system kan få uppdaterad information om detta och använda den för att neka en användare att logga in.
OCSP
Är en metod där ett system kontrollerar ett certifikat åt gången
För denna metod realiseras spärren I princip omedelbart
Varje OCSP-svar får en tidsstämpel som säger hur länge svaret får användas av förlitande part. För SITHS gäller:
notBefore → Tidpunkt då frågan ställs
notAfter → 48 h framåt från notBefore
CRL
Är en metod där ett system kan hämta en lista över samtliga spärrade certifikat per certifikatsutfärdare
För denna metod finns en ledtid på upp till 65 minuter. En ny spärrlista ges ut av CA var 60:e minut, samt att det finns en cache på 5 minuter innan ny hämtas till den server (CDP) som är avlämningspunkt mot förlitande part.
Varje CRL får en tidsstämpel som säger hur länge den får användas av en förlitande part, för SITHS gäller:
Spärrlistor för certifikat till slutanvändare och funktionscertifikat:
lastUpdate → Tidpunkten då CRL skapas av CA
nextUpdate → 72h från lastUpdate
Spärrlistor som utfärdas av Root CA för utfärdande CAs:
lastUpdate → Tidpunkten då CRL skapas manuellt då rooten är offline
nextUpdate → ~12 månader
Net iD Client är en annan produkt från SecMaker med liknande funktionalitet som Net iD Enterprise. Net iD Client ingår inte i Ineras avtal med Telia och stöds därför inte av Inera i dagsläget.
Legitimering och underskrift av användare kan ske med olika tekniker. Samtliga är förknippade med någon form av inloggningsmetod, ofta med en tillhörande applikation som installeras på användarens dator.
I SITHS finns i dagsläget två applikationer som används för att möjliggöra användning av SITHS e-legitimation vid legitimering och underskrift av användare:
Lade till information om hur användarupplevelsen är vid interaktiv inloggning till Windows, samt upplåsning av kort vi inloggningsskärmen.
1.11
SITHS Förvaltning
Lade till länk till SITHS sida för programvaror
1.12
SITHS Förvaltning
Lade till länk för information om PIN-SSO till skillnad mot IdP-baserad SSO under rubriken Interaktiv inloggning till Windows med SAC minidriver
1.13
SITHS Förvaltning
borttag av Net iD
Interaktiv inloggning till Windows-dator med SITHS eID på kort
Klicka nedan för att läsa mer om inloggning till Windows-dator med SITHS eID på kort.
Support kring interaktiv inloggning till Windows-datorer med SITHS eID på kort hanteras dock inte via Inera. Hjälp med att aktivera detta och support vid problem måste säkras via egna supportavtal om din organisation inte känner sig säker på att kunna hantera detta med egna resurser.
Inloggning till Windows med SITHS e-legitimation på SITHS-kort
Om användaren har ett användarnamn (domäninloggningsnamn) angivet i HSA när certifikatet eller kortet beställs inkluderas det i certifikatet som ett “User Principal Name”. Certifikatet får då också övriga egenskaper som behövs för att det ska gå att använda vid interaktiv inloggning till Windows istället för angivande av användarnamn och lösenord.
Vid denna typ av interaktiv inloggning kommer även inloggning till övriga applikationer som hanterar autentisering med hjälp av samma samma AD-miljö att kunna hanteras via PIN-SSO/Pin-cache. För mer information se rubriken Autentiseringslösningar för SITHS på denna sida.
Förutsättningar
Något av följande krävs för att ge stöd för interaktiv inloggning till Windows tillsammans med SITHS eID på kort:
Lokalt i er organisation
Att ni installerar nedan mjukvara på klientdatorerna i er organisation. Information om och nedladdning av mjukvaror för SITHS finns här Programvaror och tillbehör för SITHS
Installera SITHS eID-app med tillägget MD (minidriver) på aktuella Windows-datorer
Att ni konfigurerar er lokala AD-installation och aktuella AD-konton enligt instruktioner från Microsoft för hur man implementerar stöd för inloggning till Microsoft AD med certifikat från en tredjepartsutfärdare (SITHS)
Interaktiv inloggning till en dator (“lokal datorinloggning”) med Windows styrs enligt Windows-arkitekturen av s k autentiseringsmoduler (authentication providers) i operativsystemet. Microsoft rekommenderar inte att byta ut de inbyggda autentiseringsmodulerna till tredje-parts-programvara. Det gör att de autentiseringsmöjligheter som finns är begränsade till det som tillhandahålls i Windows. En sådan möjlighet är att använda smarta kort som följer Microsofts Minidriver-specifikation.
I miljöer där säker åtkomst till applikationerna är det primära och klientdatorerna ses som delade arbetsplatser, kan det vara lämpligast att endast kräva SITHS-kort vid applikationsåtkomst och inte för inloggning till klientdatorn.
Om man vill använda SITHS-kortet för den interaktiva inloggningen till Windows-datorer, kan SITHS eID-appen för Windows installationspaket med tillägget MD användas. I dessa paketeringar ingår
en minidriver (SAC minidriver) med stöd för SITHS-korten.
en funktion för att låsa upp ett låst SITHS-kort vid Windows inloggningsskärm med hjälp av upplåsningskod (puk).
Interaktiv inloggning till Windows med SAC minidriver
Välj ditt användarnamn
Välj Inloggningsalternativ
Välj smartkortssymbolen
Det kan finnas flera om flera kortläsare och kort är anslutna till datorn
Ange din pin-kod
Notera att inloggningen med SITHS-kortet sker lokalt mot Windows/AD med hjälp av det inbyggda stödet för smarta kort i Windows. I Windows/AD-miljön ställs s.k. Kerberos-biljetter ut för att användaren ska få åtkomst till olika Windows-resurser. Denna teknik är dock inte kopplad till den IdP-baserade inloggning som beskrevs ovan, vilket medför att kortinloggning i Windows/AD i sig inte ger SSO-funktionalitet mot tjänster som är kopplade till IdP.
SITHS eID för Windows i MD-paketering (med SAC minidriver) funktion är att agera drivrutin mot SITHS-kortet och importera certifikaten till Windows-datorns “MyStore” och därigenom göras dem valbara för användaren vid Windows inloggningsskärm förutsatt att AD-miljön har konfigurerats korrekt.
Upplåsning av blockerat kort med PUK vid Windows inloggningsskärm med SAC minidriver
Autentisering med SITHS eID (inkl. Mobilt SITHS) “out-of-band” till applikationsresurser i Windows-miljö
Detta scenario stödjer inte inloggning vid Windows-datorer via inloggningsskärmen. Utan endast inloggning till applikationer efter att användaren loggat in på Windows-datorn.
För information om inloggning till Windows se avsnittet Interaktiv inloggning till Windows-dator med SITHS-kortovan.
Klicka nedan för att läsa mer om inloggning till applikationer efter att du loggat in till Windows-datorn då även användning av SITHS eID-appen och Mobilt SITHS stöds.
Visa information om autentisering med SITHS eID “out-of-band” till applikationsresurser i Windows-miljö
SITHS eID på kort respektive mobil enhet tillsammans med autentiseringslösngar baserade på out-of-band teknik går att integrera som primära alternativt kompletterande autentiseringsmetoder i en lokal Windows-miljö. Detta möjliggör autentisering mot kopplade applikationsresurser i Windows-miljön, t.ex. Office365, Google Apps eller dylikt.
För att åstadkomma detta behöver organisationens AD-installation (Azure AD eller ADFS) anslutas för att konsumera autentiseringsmetoderna som tillhandahålls av Inera Autentiseringstjänst.
Det är även möjligt att integrera en lokal “on-prem” AD-installation med Azure AD och på så sätt skapa en hybrid-lösning där användare som är kopplade till den lokala AD-installationen kan autentiseras via Azure AD, som i sin tur är kopplad till autentiseringsmetoderna för SITHS eID.
Generella förutsättningar
Lokalt i er organisation
Azure AD alternativt ADFS används i rollen som lokal IdP (Legitimeringstjänst). Anslutning för autentiseringsmetoderna görs enligt något av nedanstående anslutningsmönster.
Klientprogramvaran SITHS eID-app för Windows-datorer installeras
Vid behov laddas SITHS eID-app för mobila enheter ner och användarna hämtar Mobilt SITHS
AD-installationen konfigureras med vilka applikationsresurser som ska kräva/använda vilken autentiseringsmetod.
Vid behov hanteras eventuell hybridlösning med on-prem AD-installation i kombination med Azure AD.
Anslutningsmönster IdP-proxy
I detta alternativ ansluts AD-installationen till Ineras IdP enligt anslutningsmönstret “IdP-proxy”. Endast Azure AD stöds av Microsoft i detta anslutningsmönster.
Förutsättningar
Lokalt i er organisation
Azure AD används i rollen som lokal IdP. Denna behöver anslutas till Inera IdP för konsumtion av autentiseringsmetoderna SITHS eID på kort respektive mobil enhet.
Följ anvisningar för anslutning hos Inera Säkerhetstjänster enligt referens nedan. Se även MS dokumentation för anslutning av en SAML 2.0 Identity Provider (IdP).
Inera IdP tillhandahåller autentisering med SITHS eID och out-of-band-teknik med hjälp av Inera Autentiseringstjänst.
Anslutningsmönster: Anslutning till Inera Autentiseringstjänst
I detta alternativ ansluts lokal AD FS eller en Azure AD-installation till Inera Autentiseringstjänst.
I denna konfiguration stödjer Microsoft officiellt s.k. multifaktorautentisering (MFA) i Windows-miiljön, vilket innebär att autentisering med SITHS eID kan användas som komplement till en primär autentiseringsmetod. Exempelvis om den primära metoden är användarnamn+lösenord, kan man även kräva autentisering med SITHS eID i ett extra användarsteg.
Förutsättningar
Lokalt i er organisation
AD FS alternativt Azure AD ansluts till Inera Autentiseringstjänst för konsumtion av autentiseringsmetoderna SITHS eID på kort respektive mobil enhet. Följ anvisningar för anslutning hos Inera Säkerhetstjänster.
Inera Autentiseringstjänst tillhandahåller autentisering med SITHS eID och out-of-band-teknik.
Klicka nedan för att visa förutsättningar för Testsidan
Visa förutsättningar
OBS! Det går endast att installera en SITHS eID app åt gången. Vill man använda olika miljöer måste man göra en ominstallation till en app som använder rätt miljö.
På Android fungerar det dock att ha flera appar installerade samtidigt då operativsystemet har funktioner som låter användaren välja vilken av apparna som ska öppnas.
Användaren behöver ha någon av SITHS klientapplikationer:
SITHS eID - Inloggningsmetoderna "SITHS eID på denna enhet" och "SITHS eID på annan enhet" kräver att användaren har någon av SITHS eID apparna och en giltig e-legitimation, för mer information: Utgivning och användning av SITHS e-legitimation
Net iD Enterprise - Inloggningsmetoden "Net iD på denna enhet med SITHS e-legitimation" behöver användaren ha Net iD Enterprise, för mer information: Programvaror och tillbehör för SITHS
En giltig e-legitimation och klientapplikation för rätt miljö enligt nedan matris:
Rätt SITHS eID app och SITHS e-legitimation för rätt miljö
Miljö
SITHS eID app
Typ av SITHS-kort
Net ID
TEST
T SITHS eID
TEST-kort
Net iD Enterprise
(samma för alla miljöer)
QA
QA SITHS eID
Produktion
SITHS eID
Produktionskort
Användning av SITHS på tunna klienter och virtualiserade klientplattformar (VDI)
SITHS på tunna klientplattformar tillsammans med dubbelriktad TLS (mTLS)
Stöd för användning av SITHS på klientplattformar tillsammans med dubbelriktad TLS (mTLS) och Net iD ingår i licensen för Net iD som tillhandahålls av Ineras. För att få support och stöd vid uppsättning och felsökning krävs dock extra supportavtal med leverantören av Net iD alternativt med annan aktör på marknaden som tillhandahåller liknande tjänster.
Stöd för användning av SITHS på klientplattformar med dubbelriktad TLS (mTLS) och SITHS eID-appen beskrivs under rubriken nedan.
SITHS eID-appen på tunna klientplattformar
Inera tillhandahåller begränsad support för användning av SITHS eID-appen på tunna klienter och virtualiserade klientplattformar (VDI). För att erhålla denna support krävs att ni som kund tecknar ett extra supportavtal. Beställning av VDI-support kan göras via det formulär som hittas här: Beställ och ändra
Exempel på testfall som kan genomföras i lokal miljö
Visa regressionstestfall för inloggning till virtualiseringsplattformar
confluence.macros.advanced.include.unable-to-render Den inkluderade sidan kunde inte hittas.
För att logga in och använda SITHS Admin som ID-administratör behöver användaren följande applikationer
Net iD Enterprise
SIS Capture Station - för ID-administratörer som beställer Ordinarie SITHS-kort från Thales kortfabrik.
Mina sidor
Mina sidor används av en användare för att hantera SITHS eID på sitt SITHS-kort. Exempelvis om hen ska hämta nya certifikat, spärra SITHS eID eller ta bort gamla certifikat.
För att, som användare, logga in och använda SITHS Mina sidor fullt ut och kunna hämta nya och administrera befintliga certifikat på sitt kort behöver användaren följande applikationer:
Net iD Enterprise
RFID - Inpassering, parkering och lunchautomater mm.
SITHS-kort används också för Inpassering, paerkering och lunchautomater hos många kunder. I detta sammanhang är det inte e-legitimationen på SITHS-kortet som används. Istället används en annan teknik och ett annat chip som också finns på SITHS-kortet.
I dagsläget används MIFARE Classic EV 1 som teknik för RFID. För att ta del av den A-nyckel som behövs för att kunna läsa information i sektor 14 & 15 kontakta Inera support.
För support kring inköp av läsare och integration av SITHS-kortet för dessa användningsområden hänvisas till era egna leverantörer för dessa lösningar.
Detaljerad beskrivning av MIFARE-kodning för SITHS-kort
Mifarekodning
Användning av sektorer
Sektor 0
MAD information
Sektor 14
På alla kortprodukter kodas de 16 sista siffrorna kortets serienummer i sektor 14 på både block 0 och block 1.
Block 2 - Innehåller det statiska värdet ”1.3KNR”.
Sektor 15
På de kortprodukter som i fabrik förses med HSA-id certifikat kodas dessutom HSA-id i sektor 15.
Block 0 används till den första delen av HSA-id (HSA-id prefix) upp till 16 ASCII tecken. Om HSA-id inte tar upp 16 bytes på sektorn nulltermineras strängen med 0x00
Block 1 används till den andra delen av HSA-id (HSA-id suffix) upp till 16 tecken ASCII. Om HSA-id inte tar upp 16 bytes på sektorn nulltermineras strängen med 0x00
Bindestrecket som separerar prefix och suffix utelämnas. {hsa-id prefix}-{hsa-id suffix}
Övriga sektorer
Får användas fritt av Ineras kunder.
Applikations ID
Health Services Carelink AB, dvs Inera AB, är registerar som ägare AID ”A00C” hos NXP.
Specifikationen beskriver att informationen läggs på en sektor med 4 block men skulle likaväl läggas på en sektor med 16 block. I detta fall så kommer MAD2 att användas.
Åtkomststyrning och kryptering
Sektor 0
Låst så att endast Leverantör av Kortproduktionstjänst kan ändra i MAD
Nyckel
Värde
Rättighet
A
A0 A1 A2 A3 A4 A5
Läs
B
Hemlig nyckel som ägs av leverantör av kortproduktionstjänst
Skriv
Sektor 14 & 15
Sektor 14 och 15 är skrivskyddade och är ej publikt åtkomliga varken för läsning eller skrivning. Kontakta Inera support om du behöver det hemliga värde som används som A- och B-nyckel och som kan användas för att läsa dessa sektorer
Nyckel
Värde
Rättighet
A
Hemlig nyckel som ägs av Inera AB
Läs
B
Hemlig nyckel som ägs av Inera AB
Läs
Övriga sektorer
Lämnas orörd med standard accessvillkor och nycklar
Nyckel
Värde
Rättighet
A
FF FF FF FF FF FF
Läs
B
FF FF FF FF FF FF
Läs
MIFARE-dokument
Nedan finns en specifikation över vilken information som skrivs i detta chip och hur den kodas:
Nedan guider ska ses som exempel och Inera har idag inte möjlighet att ge någon detaljerad support eller konsultation kring integration med SITHS-certifikat i den egna miljön. Våra kunder tecknar oftast egna avtal med olika tjänsteleverantörer och leverantörer av konstulttjänster på marknaden.
Bland annat tecknar många avtal direkt med Ineras underleverantörer Cygate och SecMaker