Teknisk Anslutningsguide Efos Server

Transkript

1 Teknisk Anslutningsguide Efos Server Efos Sid 1/23

2 Revisionshistorik Version Datum Författare Kommentar Första grova utkastet Uppdaterat syftet Uppdatering av kommentarer från Alyassiri Hasanein Svar på frågeställningar från Risto Eriksson Uppdaterat alla delar i dokumentet Niclas Hedlund, Säkerhetstjänsten Kommentarer har blivit införda En del kommentarer har blivit åtgärdade Jonas Öholm SecMaker Kommentarer tillagda Tagit bort kapitel 7. Hantering av nycklar och trust stores. Tagit bort generella frågeställningar Hanterat alla kommentarer. Skickas ut för kommentarer Robert Tencic Försäkringskassan Kommenterat dokumentet och föreslagit förbättringar Hanterat Robert Tencic kommentarer och förbättringsförslag Christoffer Johansson, Inera Kommentarer tillagda Publicering av dokumentet på Ineras Webb Uppdaterat efter ny information på Efos dagen Diverse rättningar och tillägg av IPadresser. 21 Mera information om certifikat från Efos server. Sid 2/23

3 Innehållsförteckning 1. Introduktion Syfte Bakgrunden Målgrupper Referenser Terminologi Teknisk överblick av Efos Teknisk Beskrivning Tillgänglig dokumentation Tillgänglighet (SLA) Information om API för e-tjänster Miljöer TLS Certifikat Brandväggsöppningar Presentation (Visible Data) Tekniska krav Klienter för produktion Klienter för test Kompatibilitet utan Efos Access server Användning av SITHS-certifikat Användning av Efos-certifikat Ansökan Sida 1 Beställ anslutning till Efos server Sida 2 Uppgifter om kontaktpersoner och miljö Sida 3 Uppgifter om servercertifikat för produktion och konfiguration Sida 4 Uppgifter om användning Efter ansökan Sid 3/23

4 7. Felanmälan och support Sid 4/23

5 1. Introduktion 1.1 Syfte Detta dokument är en teknisk anslutningsguide för Efos Access server. Denna Access server är en ny infrastrukturkomponent och behövs för att kunna ersätta den nuvarande plugin tekniken som används i SITHS. Access servern kommer att fungera på ett likartat sätt som BankID och dess klienter, förutom att kunna hantera både personnummer och HSA-id som id begrepp. Alla applikationer som skall göra en inloggning och/eller underskrift med Efos-kort och vill använda andra webbläsare än Internet Explorer kommer att behöva ansluta till Efos Access server via en IdP (utom underskrifter). Dokumentet är uppdelat i dessa kapitel: 1. Introduktion detta kapitel inklusive bakgrunden 2. Teknisk översikt av Efos 3. Teknisk beskrivning 4. Information om API för e-tjänster/idp 5. Kompatibilitet utan Efos Access server 6. Ansökan 7. Felanmälan och support 1.2 Bakgrunden Den 30 oktober 2018 lanseras e-identitet för offentlig sektor, Efos, som ska ersätta Identifieringstjänst SITHS och Försäkringskassans MCA. I och med lanseringen av Efos kommer sättet för hur man utfärdar och administrerar e-identiteter att förändras. I projektet ingår även lansering av en mobil E-identitet för offentlig sektor, Mobilt Efos, som lanseras senare under 2018, se tidplan nedan. Det innebär att det kommer att vara möjligt att utfärda e-legitimationer till en speciell applikation, som kan installeras på mobiltelefoner och surfplattor. Inför lanseringen av Efos är det mycket som måste åtgärdas och kontrolleras för att det ska fungera att använda Efos-certifikat i alla sammanhang som man idag använder SITHS-certifikat. Det är viktigt att övergången går både snabbt och sker på ett säkert sätt. Under en period kommer SITHS och Efos vara i parallell drift för att underlätta övergången. Se [R3] Tidsplan för Efos införande för detaljer när de sista beställningarna av ordinarie SITHSkort för att SITHS Administration att stängas för kortbeställningar. Se även hur länge reserv korten kommer att gå att beställa Här kan du ta del av de viktigaste förändringarna mellan Efos och SITHS. Sid 5/23

6 Nytt administrationsverktyg Verktyget kommer att kunna användas för att utfärda certifikat inom alla organisationer inom den svenska offentliga sektorn och som har avtal med Inera och/eller Försäkringskassan om att använda tjänsten. I tabellen nedan kan du se likheter och skillnader verktyget kommer att ha jämfört med idag. Ny funktionalitet E-identitet för offentlig sektor - funktionalitet E-legitimationer/certifikat på smarta kort, mobila bärare, nya och kommande bärare Modernt användargränssnitt Möjlighet till mobil användning, autentisering och signering - utöver motsvarande funktionalitet med smarta kort. Citrixstöd Supportavtal Underskrifter med alla Webbläsare Identifieringstjänst SITHS - funktionalitet E-legitimationer/certifikat på smarta kort Gammalt användargränssnitt Endast autentisering och signering med smarta kort. Ej Citrixstöd, utan extra supportavtal Supportavtal ingår ej, kostar extra Underskrifter enbart med Internet Explorer Nya produkter E-identitet för offentlig sektor - produkter Net id Enterprise - Win/Linux/OSX Nytt administrationsverktyg Net id Access inklusive klient. - Win/iOS/Android/Linux/OSX Net id Connect för Citrix Identifieringstjänst SITHS - produkter Net id Enterprise - Win/Linux Telias SITHS admin, Självadministration och Statistik & Loggar Ingen Net id Access Ingen Net id Connect för Citrix, utan extra supportavtal Sid 6/23

7 Anpassningar och konsultstöd kan köpas till från SecMaker som en del av avtalet Anpassningar och konsultstöd har köpts till från olika aktörer oberoende av avtalet Ny PKI-struktur I samband med att vi lanserar E-identitet för offentlig sektor, kommer vi att få en ny PKIstruktur (se bild 1, CA och PKI strukturerna). Den är baserad på certifikatens olika syften och användningsområden, samt anpassad efter nya regelverk och krav. Den nya PKI-strukturen innebär också att vi får nya rotcertifikat och utfärdarcertifikat ( som samtliga RA-organisationer måste installera tillit till. Mer om detta kan du läsa nedan. Bild 1, CA och PKI strukturen. För mera information gå till Ineras webbplats för Identifieringstjänst SITHS och E-identitet för offentlig sektor Efos [referens R2] Sid 7/23

8 1.3 Målgrupper De huvudsakliga målgrupperna för dokumentet är: Systemägare Systemförvaltare Systemarkitekter Utvecklingsteam Journalsystemleverantörer Tjänsteleverantörer 1.4 Referenser I följande avsnitt anges länkar till ytterligare relevant dokumentation och en sammanställning av samtliga referenser som har förekommit i dokumentet. Ref Dokument-id Länk R1 R2 referensarkitektur_identitet _och_atkomst.pdf Identifieringstjänst SITHS och E-identitet för offentlig sektor - Efos Identitetochatkomst-RevA.pdf /siths /e-identitet_for_offentlig_sektor R3 Tidsplan för Efos införande /e-identitet_for_offentlig_sektor under rubriken Lanseringsplan Efos och avveckling SITHS R4 R5 Sökvägar och brandväggsöppningar för Efos Efos net id kompatibilitet vid installation ochanvändning /e-identitet_for_offentlig_sektor under rubriken Införandeguide för tekniskt ansvariga /e-identitet_for_offentlig_sektor under rubriken Införandeguide för tekniskt ansvariga 1.5 Terminologi Begrepp BankID Definition E-legitimation som tillhandahålls av företaget Finansiell id-teknik till kunder i olika banker och andra organisationer. Sid 8/23

9 Certifikat Efos Efos Server Identifiering Kryptering Net Id Enterprise MCA PKI System Architecture Document (SAD) SAMLidentitetsintyg SAT Transport Layer Security (TLS) SITHS Ett elektroniskt, av CA-systemet, signerat intyg av en publik nyckels tillhörighet till en specifik nyckelinnehavare. E-identitet för offentlig sektor Infrastukturkomponent Efos out-of-band authentication service för kommunikation till klienten. Process vari en användare eller resurs anger sin identitet. Omvandling av klartext till kryptotext med hjälp av ett krypteringssystem och aktuell kryptonyckel i syfte att förhindra obehörig åtkomst av konfidentiell information. Klient som krävs vid användning av SITHS- och Efos-kort. Myndighets CA Public Key Infrastructure, Formell beskrivning av ett IT-systems arkitektur. SAML 2.0 är en öppen XML-baserad standard för utbyte av data vid autentisering och auktorisation. En användare kan med SAML 2.0 loggas in till ett system med en identitet som inte har någon anknytning till systemet. Genom SAML 2.0 uppnås så kallad federerad inloggning. SAML-identitetsintyget är den information som användaren tar med sig när denne loggar in eller förflyttar sig mellan två system. System Acceptance Test Protokoll som används för att kryptera kommunikation mellan två enheter för att försvåra avlyssning eller manipulation av informationen. Elektronisk tjänstelegitimation för kommun och landsting, ffa vårdpersonal. Sid 9/23

10 2. Teknisk överblick av Efos Både SITHS- och Efos-kort fungerar med de inloggningslösningar som existerar, t.ex. dubbelriktad TLS mellan webbläsare och webbserver. Från version av Net id Enterprise stöds även Edge. Lösningar som använder Net ids plugin fungerar dock endast med Internet Explorer 11, med både SITHS- och Efos-kort. Både SITHS och Efos kommer att kunna fungera på samma sätt som tidigare. Däremot erbjuder och rekommenderar Efos en ny och mer användarvänlig metod för inloggning och underskrifter. Efos nya metod använder inte plugin tekniken utan använder sig av en mellanhand som sköter kontakten mellan Efos klienten och e-tjänsten/idp. Däremot inkluderar Efos-tjänsten en ny autentiseringsmetod enligt principen Out-of-Band authentication som för tillfället möjliggörs med hjälp av produkten Net id Access. Inom Efos finns denna server/ mellanhand centralt placerad och levererar framförallt tre grundläggande funktioner: 1. Ta emot inloggnings- och underskriftsbegäran från förlitande parter 2. Sköta kommunikationen med Net id Access apparna för Windows/macOS/Linux/iOS/Android 3. Låta förlitande part begära/ polla efter status för inloggnings- och underskriftsbegäran och när appen är klar ge ett svar tillbaka om det gick bra eller inte Första gången ett visst kort/certifikat används med Net id Access appen/klienten på en viss device/dator förhandlas det fram en hemlighet som ger ett extra skydd mellan app och server. Hemligheten baseras på det unika certifikatet. Aktiveringen ska endast behöva göras en gång per device/dator och kan se ut såhär: Efos använder ett webbservice gränssnitt som liknar det som Mobilt BankID använder. Detta gränssnitt har tre grundläggande funktioner: Authenticate Vill man initiera en inloggningstransaktion anropar man Authenticatefunktionen. Avser inloggningen ett SITHS-kort måste man ange HSA-id, gäller det ett Efos-kort kan det vara personnummer eller HSA-id. Är det ett Mobilt Efos måste det vara ett personnummer. Sign - Vill man initiera en underskriftstransaktion anropar man Sign-funktionen. Avser underskriften ett SITHS-kort måste man ange hsaid, gäller det ett Efos-kort kan det vara personnummer eller HSA-id. Det man önskar få signerat skall vara Bas64-kodat och kan anges som visningsbart i klienten eller dolt. Är det ett Mobilt Efos måste det vara ett personnummer. Collect Både Authenticate och Sign ger ett 23 tecken långt transaktionsid tillbaka. Förlitande part använder detta transaktionsid i sina Collect-anrop för att till slut få besked om allt gick bra eller inte. Gick allt bra kan förlitande part besluta att returnera en biljett till själva applikationen. Flödet för en underskrift kan ses på bild 2, samt beskrivning av de olika stegen enligt nedan Sid 10/23

11 E-tjänst/IdP Inloggning eller underskrift 1 Användaren Klient och E-legitimation EFOS Server Bild 3, Flödesbeskrivning av kommunikationen för underskrifter och Efos 2 Sid 11/23

12 3. Teknisk Beskrivning 3.1 Tillgänglig dokumentation För att få en djupare teknisk detaljerad beskrivning finns det ett antal dokument som ger en mera detaljerad beskrivning. Följande information finns tillgänglig: Översikt för Access-konceptet så att alla tekniker och andra är med på principerna. Denna beskrivning finns inte tillgängligt för tillfället utan är på gång. En mera detaljerad beskrivning av själva kommunikationen på protokoll-nivå. Denna beskrivning finns inte tillgängligt för tillfället utan är på gång. Själva WSDL-filen 1 som definierar XML strukturerna i protokollet: Exempel 2 för hur de olika funktionsanropen ser ut: Tillgänglighet (SLA) Arbete med SLA pågår med Inera, det är planerat att vara klart 2 veckor innan driftsättning. Nuvarande krav på tillgänglighet från Inera är för Access server: 99,98%/mån, 00-24, max stopp 11min/mån, 2ggr/mån. 4. Information om API för e-tjänster 4.1 Miljöer Efos SAT miljö för test Testmiljön för Efos kallas SAT i vilken utpekade kortadministratörer kan ta ut certifikat för test, i dagsläget beställs dessa från Inera. Dessa testcertifikat är i princip identiska med de certifikat som utfärdas i produktionsmiljön och är utgivna från en likadan PKI-struktur. SAT-miljön är inte del i någon extern ackreditering som ex. Svensk e-legitimation eller Microsofts Root CA 1 Kan komma att ändras innan lanseringen 2 Kan komma att ändras innan lanseringen Sid 12/23

13 program och kräver därför inte samma handläggning avseende rutiner och hantering av certifikat och kort. Adresserna för mobilklienterna (Android och ios) skall kunna ansluta till centrala miljön kommer vid ett senare tillfälle innan lanseringen av Mobilt Efos. URL för Efos testserver Namn IP-nummer Kommentar Vid anrop till denna Efos server kommer den att presentera ett webbserver certifikat från Swedish Public Sector Function CA SAT v1. För att kontakta behöver man ha ett klient funktionscertifikat av typen SITHS funktionscertifikat (SITHS Type 3 CA v1) eller Efos funktionscertifikat (Swedish Public Sector Function SAT CA v1). Men det finns ett generiskt certifikat från Swedish Public Sector Function CA SAT v1 som förvaltningen kan skicka för test. Alla variabler, nyckellängder mm är precis likadana, med den skillnaden att revokeringskontroll genom OSCP, CDP och AIA görs av SAT-servrar istället. Detta gör att man måste göra ytterligare brandväggsöppningar för revokeringskontroll för system som använder testcertifikat. Man måste också ha en annan tillit installerad i produktionsmiljön än i testmiljön. Efos produktionsmiljö URL för Efos server Namn IP-nummer Kommentar Vid anrop till denna Efos server kommer den att presentera ett webbservercertifikat från Swedish Public Sector Function CA v1. Kommunikationen med Efos servern i produktion behöver e-tjänsten/idp ett certifikat utställd av en special CA (preliminärt namn är Swedish Public Sector Customer CA v1) som skyddar enbart mellan e-tjänst/idp och Efos servern. I leveransen till den tekniska kontaktpersonen kommer det att skickas certifikat (med nyckel från CSR) samt CA-certifikat för denna speciella Efos funktions CA. Observera att normala utgivningsrutiner kommer att hanteras genom kontroller av organisationen och vem som har rätt att beställa. Truststoren för att kommunicera med Efos produktionsserver kommer att kräva att man installerar det CA certifikat som kommer från den speciella CA:n. Sid 13/23

14 4.2 TLS Certifikat Det behövs ett funktionscertifikat för att kommunicera med Efos server. Detta funktionscertifikat måste installeras / konfigureras i din "key store". Funktionscertifikatet verifieras av Efos servern när TLS kanalen är etablerad till den, samt Efos servern presenterar sedan sitt servercertifikat i sin tur. För att möjliggöra den här valideringen måste utgivaren av serverns certifikat installeras / konfigureras i din "trust store". Key stores eller trust stores hanteras annorlunda beroende på din miljö och förklaras senare i detta dokument. Observera att olika certifikat används för produktion och test. Observera att certifikaten kan behöva konverteras till ett annat filformat som accepteras av din miljö. 4.3 Brandväggsöppningar Observera att länkar och destinationer som används för få tag på certifikat och spärrinformation fortfarande ska vara öppna och fungerade. Det spelar ingen roll om e-tjänsten eller IdP som skall kommunicera med Efos Server finns på Sjunet eller internet. Det är samma adresser för accesservern. Se [R4] Sökvägar och brandväggsöppningar för Efos för alla IP-nummer som är påverkade. 4.4 Presentation (Visible Data) I fältet VisibleData som är det data som presenteras för användaren vid en underskrift, skall innehålla en text med teckenkodningen UTF-8 samt har vissa enklare formateringsfunktioner. Om man nyttjar :, dvs. kolon följt av mellanslag kan man få en tabellformatering. T.ex. sågär: Patientens namn: Frida Kranstege Patientens personnummer: Medicin: Vila och ett glas kranvatten Skäl: Trött och törstig Ansvarig läkare: Ville Villesson Mera beskrivning av detta kommer vid ett senare tillfälle. Sid 14/23

15 4.5 Tekniska krav Access server stödjer enbart http/1.1eller http/2.0 samt kräver att man använder TLS 1.1 eller TLS 1.2. Diskussioner förs för att lägga till TLS Klienter för produktion Följande programvaror krävs för att e-tjänster/idp skall fungera med Efos: Net id Enterprise Minst version för att kunna läsa Efos-korten. Krävs för bakåtkompatibilitet för nuvarande inloggningsmetod Net id Access Client Egen applikation, nytt paket kommer släppas Används för ny metod för autentisering och underskrifter Finns även till Android och iphone för Mobilt Efos Sid 15/23

16 Det är viktigt att alla tester som handlar om Net id Access sker baserat på rätt version av Net id Access-klienten. Se efter mera information i dokumentet [R5] Efos Net id kompatibilitet vid installation ochanvändning Klienter för test Observera att alla testklienter är pre-versioner av de klienter som kommer att bli släppta. För Windows/macOS gäller: OBS! Testar man på en eklientpc måste man använda MSI-paketet För ios gäller: I skrivande stund är Beta 11b den senaste För Android gäller: I skrivande stund är Beta 13 den senaste Se efter mera information i dokumentet [R5] Efos Net id kompatibilitet vid installation ochanvändning. 5. Kompatibilitet utan Efos Access server Konsekvenser av detta blir att: Efos-korten kommer att kunna använda Internet Explorer 11, Chrome och Firefox för inloggning som tidigare men inte Chrome. Edge kräver dock att man kör Net id Enterprise för att dubbelriktad TLS ska fungera. Däremot stödjer inte Chrome och Edge underskrifter utan att Net id Access används. Internet Explorer och Firefox (kräver en del konfiguration) klarar av att skapa underskrifter med pluginen både för Efos- och SITHS-kort. Sid 16/23

17 5.1 Användning av SITHS-certifikat Man kan mycket väl och utan problem använda befintliga SITHS-kort tillsammans med Access servern för att skapa underskrifter och göra autentiseringar. Efos servern har fullt stöd för SITHS-certifikat på kortet. 5.2 Användning av Efos-certifikat Alla ordinarie Efos-kort har två certifikatspar på Efos-korten som är utgivna till hälso- och sjukvården, ett par med personnummer och ett par med HSA-id. Ordinarie kort utgivna till statliga myndigheter har inget certifikat med HSA-id utan enbart ett med personnummer. Reservkort har enbart certifikatpar med HSA-id i sig. 6. Ansökan För att ansöka om att testa och få använda produktions Efos servern använd denna URL: Ansökningsguiden är indelad i fyra sidor. 6.1 Sida 1 Beställ anslutning till Efos server Sid 17/23

18 Alla ovanstående fält måste fyllas i. Företagsnamn och organisationsnummer måste vara enligt officiella register som tex Bolagsverket. 6.2 Sida 2 Uppgifter om kontaktpersoner och miljö Det är viktigt att ansvarige person kommer att ha det fulla ekonomiska och juridiska ansvaret för anslutningen. Det kan komma krävas en fullmakt eller underskrifter från firmatecknare i avtalet. Det är viktigt att välja en kontaktperson som har en bra överblick vad som skall göras samt att telefonen är ett mobilnummer. Sid 18/23

19 Eftersom Efos Test Access server använder inkommande IP-adress som sökbegrepp till konfigurationen för den anslutande part, är det viktigt att man använder den utgående IPadressen och inte själva Webbserverns adress för IdP eller e-tjänsten. Om denna adress inte har blivit specificerad vid ansökningstillfället kan det kompletteras senare 6.3 Sida 3 Uppgifter om servercertifikat för produktion och konfiguration Namnet är enbart till för att hjälpa till i felsökning och vid referenser till certifikatet. Sid 19/23

20 Adressen används för framtida funktioner bl.a. för att skicka en påminnelse när e-legitimationen är på väg att upphöra, eller annan information av vikt för anslutande part. Ingen reklam eller annat kommer att skickas här enbart information av stor vikt för anslutningen. CSR (Certificate Signing Request) För att komma åt produktionsservern behöver e-tjänsten/idp ett speciellt funktionscertifikat. Detta funktionscertifikat ges ut från en speciell CA, och därmed behövs en CSR. Om en CSR inte kan skapas vid ansökningstillfället behöver detta kompletteras och skriv detta i CSR rutan. En CSR behöver skapas innehållande en publiknyckel samt Proof-of-Possession signatur. Proof-of-possession är en metod för att skriva under själva CSR:en. Fungerar på samma sätt som en vanlig underskrift, och bevisar att underskriften är gjord med den privata nyckeln som angiven i CSR:en. Exempel på hur en CSR skall se ut: -----BEGIN CERTIFICATE REQUEST----- MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxDTALBgNVBAgMBFV0YWgxDzANBgNV BAcMBkxpbmRvbjEWMBQGA1UECgwNRGlnaUNlcnQgSW5jLjERMA8GA1UECwwIRGln aunlcnqxhtabbgnvbammfgv4yw1wbguuzglnawnlcnquy29tmiibijanbgkqhkig 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8+To7d+2kPWeBv/orU3LVbJwDrSQbeKamCmo wp5bqdxiwv20zqrb7apuokyoveffoeqs6t6gimniolhbih6m4zgz/cpvwbokzc+c 1Po2EmvBz+AD5sBdT5kzGQA6NbWyZGldxRthNLOs1efOhdnWFuhI162qmcflgpiI WDuwq4C9f+YkeJhNn9dF5+owm8cOQmDrV8NNdiTqin8q3qYAHHJRW28glJUCZkTZ wiasr6crbq8tbyne0dc+caa3doikz1eoshwztx+n0zkfqcbgxi4djx+c1bjptypr BPZL8DAeWuA8ebudVT44yEp82G96/Ggcf7F33xMxe0yc+Xa6owIDAQABoAAwDQYJ KoZIhvcNAQEFBQADggEBAB0kcrFccSmFDmxox0Ne01UIqSsDqHgL+XmHTXJwre6D hjszwbvetok0g3+dr4fs11wuunt5qclsx5a8uk4g6akhmzuhlsj7xzjgmqxgecpy Q4mC3yT3ZoCGpIXbw+iP3lmEEXgaQL0Tx5LFl/okKbKYwIqNiyKWOMj7ZR/wxWg/ ZDGRs55xuoeLDJ/ZRFf9bI+IaCUd1YrfYcHIl3G87Av+r49YVwqRDT0VDV7uLgqn 29XI1PpVUNCPQGn9p/eX6Qo7vpDaPybRtA2R7XLKjQaF9oXWeCUqy1hvJac9QFO2 97Ob1alpHPoZ7mWiEuJwjBPii6a9M9G30nUo39lBi1w= -----END CERTIFICATE REQUEST Sida 4 Uppgifter om användning Sid 20/23

21 Här anges hur många anrop som ni tror kommer att ske under en dag när det är som mest. Detta är enbart uppskattningar. Här anges hur många anrop som ni tror kommer att ske under en timme när det är som mest. Detta är enbart uppskattningar. Detta är en försäkran om att det är möjligt att få statistik från den anslutande parten för hur många anrop som sker. Beskrivning av vad det är för typ av tjänst och vad den skall användas till. De som skall göra underskrifter via Efos servern anger detta men även av vilken typ. Normalt sätt är det PKCS#7 men i speciella fall där man behöver integrera in underskrifter i Sid 21/23

22 ett standardiserat dokument finns möjligheten att få det i RAW format (enbart själva underskrift värdet, resten får man hantera själv). Detta fält används för att ge extra information som kan behövas. 6.5 Efter ansökan Ineras förvaltning av Efos kommer att validera ansökan och se om den uppfyller kraven på att få göra en anslutning. Godkännande av anslutning sker via Efos PA. Vid godkänd ansökan kommer information skickas till kontaktpersonerna. All kommunikation går via kontaktpersonen. Se felanmälan för fel och annan rapportering. 3 månader efter ansökan vill vi se ett exempel på ett SAMLv2 intyg eller motsvarande standardiserat åtkomstintyg i enlighet med Referensarkitekturen för identitet och åtkomst Sid 22/23

23 7. Felanmälan och support Om du vill göra en felanmälan som handlar om kommunikationen till eller från Efos Access Server använd kontaktuppgifterna under fliken Kundservice på. Viktigt att märka anmälan med att det handlar om Efos och Net id Access. Sid 23/23