/
Lansering av Inera IdP-Invånare våren 2026

Lansering av Inera IdP-Invånare våren 2026

Innehåll:

Bakgrund

Under 2025 påbörjades ett arbete för att samordnad Ineras olika IdP-erbjudanden. Först ut var Idp-Plus som togs fram för att uppfylla de nya säkerhetskrav som EHM ställde för åtkomst till Nationella Läkemedelslistan, NLL. Tjänsten lanserades 30 september 2025, Den 26 januari 2026 lanserades en ny version av IdP-Bas, vilket gjordes i samma säkra driftsmiljö som för IDP-Plus. Det 3:dje steget för att samordna Ineras Idp-tjänster gäller IdP-Invånare, dvs. den funktion som t.ex. används för invånarna när de loggar in i 1177. Lansering av nya IdPn skedde 19 maj, men på samma sätt som för tidigare IdPer, det är anslutande part som bestämmer när övergången ska göras, och migreringsfönstret kommer hållas öppet ett par månader.

 

Nya funktioner i IdP-Invånare (version 3.2)

Legitimeringstjänst IdP för medabetare - Bas, Legitimeringstjänst IdP för medabetare - Plus samt Legitimeringstjänst IdP för invånare delar kodbas och har därmed den mesta funktionaliteten gemensam. Det är främst konfiguration som styr vad de olika IdPerna erbjuder för funktionalietet och inloggningsmetoder.

Exempel på funktionalitet:

  • Temabyggare - Webbgränssnitt som ger möjlighet för kunder beställa en eget visuell profil

  • Export och importfunktion för konfigurerade SP-klienter

  • Versionshantering av klienter för att kunna spåra förändringar och möjliggöra snabb rollback

  • Tidsstyrd aktivering av förändringar i konfigurerade SP-klienter

  • Stöd för att i framtiden kunna hantera andra eIDn än SITHS, BankID, Freja eID+ och Freja OrgID

  • Bättre och skalbar prestanda för att säkra framtida användningskrav och trafikvolymer

  • Effektivare driftsförvaltning - samma kodbas för Ineras olika IdP-erbjudanden

  • Effektivare drift - fullt ut automatiserad och versionshanterad release och deploy

Vad behöver anslutna organisationer göra i samband med nya releasen?

Den nya versionen av IdP:n sätts upp i en helt ny driftsmiljö och vi vill därför att alla ansluter sina TEST/QA-system till den nya IdP-Invånare QA-miljö. Byte till den nya driftsmiljön innebär både för- och nackdelar för dig som kund, några som kan nämnas är:

Fördelar:

  • En ny QA-miljö sätts upp med IdP-Invånare, så eventuella pågående tester i gamla CGIs QA-miljö påverkas ej

  • Som kund bestämmer man själv när övergång till den nya IdP-Invånare ska ske, både QA och PRODUKTION, vår målsättning är att så många som möjligt genomför flytten i produktion före halvårsskiftet 2026.

Nackdelar:

  • SSO kommer inte fungerar mellan de två driftsmiljöerna, av detta skäl ser vi gärna att övergång till den nya IdP:n sker under en begränsad tid.

  • En ny driftmiljö innebär även nya IP-adresser som kan kräva brandväggsöppningar, se mer information här

  • Migreringen kommer inte bli en 1 till 1 migrering utan vissa mindre justeringan kan bli növändiga för vissa klienter och SP/RP.

  • En ny teknisk bilaga behöver skickas in med uppgifter som behövs för att lägga upp kiienterna i den nya IdPn.

 

Teknisk information

Utförlig teknisk dokumentation för Ineras IdP-tjänster finns samlad här:

Legitimeringstjänst IdP - Inera - Identitet och åtkomst - Confluence

Sammanfattad teknisk information för drift finns nedan:

Den nya driftsmiljön är uppsatt på motsvarande sätt som den gamla men med ett nytt signeringscertifikat. Den nya miljön kommer också ingå i domänen inera.se och den får därför ett nytt DNS-namn. Det nya DNS-värdet i produktion blir idp.invanar-idp.inera.se och i QA idp.qa.invanar-idp.inera.se

  • För SAML-SP (SP=Service Provider=Klient) betyder det att konfigurera den nya URLen för IdP:n, samt hämta och byta ut IdP-metadata, läs mer här

  • För OIDC-RP (RP=Requesting Party=Klient) måste förvaltaren kontrollera rutinen, då byte INTE kan ske automatiskt eftersom IdPn fått nytt DNS-namn, läs mer här

  • Viktigt att ni även kontrollerar er nätverks/brandväggs-konfiguration då den nya IdPn tillhör en ny domän och sitter på ett nytt IP-nät, läs mer här

Viktigt att tänka på: Det finns ingen SSO mellan nya och gamla IdPn, så har ni tjänster som nyttjar SSO, se till att ordna med en gemensam övergång till nya IdPn,

 

IdP SAML Metadata

Då version 3.2 sätts upp i en ny driftsmiljö med ett nytt signeringscertifikat så kan denna förändring kräva lite andra handgrepp jämfört med då bara signeringscertifikatet byts ut. Både den gamla driftsmiljön och den nya driftsmiljön kommer vara i drift parallellt under ett par månader så kan ni själva bestämma när övergång ska ske, skulle problem uppstår vid byte så är det bara att peka tillbaka mot den gamla IdPn.

Adresser för nerladdning av metadata

IdP OIDC information

Den nya driftsmiljön kommer läsa över all klientkonfiguration enligt tidplanen ovan. I OIDC-världen finns ingen utväxling av metadata som för SAML utan här sker ofta uppdatering av IdP:ns nycklar, som används för signering, automatiskt i bakgrunden. Men i detta fall så är det ju från klientens (RPs) synvinkel en helt ny IdP som sätts upp, och den måste således konfigureras upp i RP:n

Adresser för nerladdning av signeringsnycklar (OIDC)

Adresser för .well-known/openid-configuration

 

OBS Tänk även på den utgående brandväggsöppningen som kan behövas, se “Nätverksinformation” nedan

Nätverksinformation

  • Nät 82.136.183.0/24 bör redan vara hanterat avseende routing och brandväggsregler, se vidare information på denna länk: https://inera.atlassian.net/wiki/spaces/IAM/pages/300389655/N+tverksinst+llningar+f+r+SITHS#kontroll_over_sjunet

  • I de fall OIDC används se även till att det finns brandväggsöppningar för utgående trafik till IdPn. Det är nödvändigt för att RP (Requesting Party) ska nå fram till IdPns JWKS URI. För PRODUKTION ska denna öppning ske till 82.136.183.199 , för QA är till det 82.136.183.183 och för TEST blir det 82.136.183.167:

Certifikatsinformation

De nya certifikaten kommer fortfarande att vara utfärdade av SITHS och vara av typerna enligt nedan:

Tester av IdP 3.2

Förslagsvis ansluter man en utvecklings- eller testmiljö till IdP 3.2 för att säkerställa att man når nya IdPn och och inloggningen fungerar. Därefter är det en stark rekommendation att genomföra mer omfattande tester för att säkerställa att nya IdPn inte får någon oönskad effekt.

OBS. Upptäcker ni avvikelser mellan nya och nuvarande IdP är det enklast och snabbast att maila ett ärende till idpinvanare@inera.se

Att tänka på innan anslutning till IdPn beställs

Är det en 1177 uthoppstjänst som du ska ansluta till IdPn så måste först en beställning göras via <LÄNK>

Inläsning av metadata i IdP-Invånare

IdPn läser aldrig av metadata direkt från SPns angivna metadata URL, det är ett arbete som i dagsläget sker helt manuellt, så ändrar ni SPns metadata så behöver ni be Inera att läsa om metadatat. Det är ett vanligt fel att man byter certifikat hos SPn, men glömmer tala om för Inera och då kommer t.ex. utloggningarna (som signeras) sluta att fungera

Signerat metadata som levereras via fil

Vid inläsning och lagring till fil är det vanligt att ”osynliga” tecken lagras i filen (radmatningar, space, osv). Är metadatafilen signeras så kommer inläsning i IDP inte att fungera om något tecken tillkommit eller försvunnit efter att signaturen räknats fram.

Så vid lagring av metadata till fil vill vi helst hämta den direkt från en publicerad URL, om ni av någon anledning inte kan eller vill exponera URL för metadata, skapa då filen genom att ni internt anropar URLen för metadata med kommandot CURL -o <filnamn.txt>  <URL> . Vill ni ”manuellt” lagra den föreslår vi att man använder en enkel editor typ Notepad som varken formaterar eller strukturerar metadata.

Supporterade Attribut

Det attribut som kan efterfrågas finns samlade på denna sida:

Attributstyrning SAML - IdP för medarbetare - Inera - Identitet och åtkomst - Confluence

 

LOA som IDP-Invånare supporterar

Vilka LOA-nivåer IdP-Invånare supporterar framgår av IdPns metadatafil, i den går att läsa följande:

<saml2:AttributeValue>http://id.inera.se/loa/loa0</saml2:AttributeValue>

<saml2:AttributeValue>http://id.inera.se/loa/loa1</saml2:AttributeValue>

<saml2:AttributeValue>http://id.swedenconnect.se/loa/1.0/uncertified-loa3</saml2:AttributeValue>

<saml2:AttributeValue>http://id.swedenconnect.se/loa/1.0/uncertified-loa2</saml2:AttributeValue>

Mer dokumentation finns här: SAML profil - IdP för invånare

Nödvändiga verktyg

För att se vad som verkligen händer vid in och utloggning i IdPn behöver trafiken analyseras utöver nätverks granskningen via F12 i borwsern, bör något “add on” installeras i browsern t.ex. SAML-decoder för att enklare förstå vad som händer i SAML dialogen. Dessa verktyg kan oftast laddas ner kostnadsfritt.

När uppkoppling mot IdPn är gjord men något går fel

Data saknas i SAML Assertion

Se till att efterfrågat attribut verkligen supporteras av IdPn. Efterfrågas ett attribut som är satt ”optional” så blir det inget fel, men attributen kommer naturligtvis saknas.

Samtliga supporterade attribut finner du här: https://inera.atlassian.net/wiki/x/U4EmUwE

IDPn visar en felsida

Om IDP visar en felsida i samband med in eller utloggning så visas även ett felmeddelande i browserns adressfält, oftast framgår det där ganska tydligt vad som är fel. Här är några exempel:

Ex:1

https://idp.qa.invanar-idp.inera.se/_error?status=403&error=%C3%85tkomst%20f%C3%B6rbjuden&message=Relay%20state%20data%20is%20longer%20than%20160%20bytes&datetime=2026-06-18T09:46:22.089644700

Det framgår ganska tydligt ann man i anropet haft ett relay state som är fler en 160 tecken (enligt ” SAML 2.0 Bindings specification” bör den inte ens överskrida 80 tecken, som den säger: ” This 80-byte limit ensures compatibility with bindings such as HTTP Redirect and avoids truncation due to URL length limits in browsers”)

 

Ex:2

https://idp.qa.invanar-idp.inera.se/_error?status=403&error=%C3%85tkomst%20f%C3%B6rbjuden&message=Unable%20to%20decode%20message&datetime=2026-05-28T09:36:31.805999930

Detta meddelande talar om att IdPn INTE lyckats fastställa signaturens äkthet i samband med en utloggningsbegäran. Det vanligaste felet är att SPn signerat med ett annat certifikat än det man angivit i sin metadatafil.

 

Ex:3

https://idp.qa.invanar-idp.inera.se/_error?status=403&error=%C3%85tkomst%20f%C3%B6rbjuden&message=Logoutrequest%20is%20not%20signed&datetime=2026-05-19T16:11:53.324982009

IdPn kräver signerad utloggningsrequest

 Ex:4

https://idp.qa.invanar-idp.inera.se/_error?status=403&error=%C3%85tkomst%20f%C3%B6rbjuden&message=No%20metadata%20found%20for%20entityId&datetime=2026-06-02T15:15:47.948230364

Ingen konfiguration hittat i IdPn för angivet EntityID, antingen saknas Klienten i IdPn (eller den är inaktiverad), eller så är EntityID felastavat i requesten (obs tänk på att små och stora bokstäver har betydelse)

 

 FAQ IdP 3.2 (uppdateras vartefter frågor inkommer)

Fråga: Om vi byter till nya IdP-Invånare QA 3.2 och vill gå tillbaka till “gamla IdP”, hur gör vi då?

Svar: Ni behöver ändra tillbaka URL och eventuellt läsa om metadata/nyckel beroende på hur ert system fungerar.

Fråga: Vi vill byta certifikatet i vårt metadata hur gör vi det?

Svar: Byt certifikat och meddela Inera att metadata behöver läsas om från er SP. Levererar ni metadata via fil, maila in en ny metadatafil till idpinvanare@inera.se så uppdaterar vi.

Fråga: Vi ser att vårt metadata har felaktiga kontaktuppgifter, hur uppdaterar vi det?

Svar: Se frågan ovan, samma rutin gäller.

Fråga: Vi har flera system som kör SSO, kommer SSO fungera mellan den gamla och nya IdPn som ni sätter upp?

Svar: Nej, planera därför så att era tjänster börja nyttja den nya IdPn vid samma tidpunkt

Fråga: Det står att i version 3.2 så finns ny funktionalitet: “Beställa en eget visuell profil”. Hur gör man det?

Svar: Kontakta idpinvanare@inera.se så berättar vi mer.

Fråga: Det står att i version 3.2 så finns ny funktionalitet, “Temabyggare - Webbgränssnitt som ger möjlighet att som kund själv anpassa utseendet till egen visuell profil i QA-miljö”, hur kommer jag åt den?

Svar: För närvarande hanteras temahanteringen av IdP-förvaltningen, vill ni ha ett eget tema maila i så fall till idpinvanare@inera.se så får vi ta ett möte och diskutera det.

Om du behöver skicka in ett supportärende

Innan du skickar in ett supportärende, se till att ha läst igenom ALL information på denna sida, vi är rätt säkra på att svaren på din fråga finns i texten ovan. Men om texten inte hjälper så är du välkommen in med ett mail till idpinvanare@inera.se, men tänk på att vi då behöver viss information för att kunna hjälpa till:

  • “Copy paste” på informationen som visas i browserns adressfält

  • Dator eller mobil

  • Om mobil, vilket operativsystem, version av OS, telefonmodell

  • Vilken webläsare används och vilken är satt som default (gäller både dator och mobil)

  • Ev. skärmbild på problemet

  • Exakt datum och tid och eventuell id/felkod om det inte framgår av URL

Publik Information