2.6 FAQ - IdP

Owned by Stefan Ehlert
Last updated: okt. 14, 2024
12 min read

Innehållsförteckning

 Visa innehållsförteckning

Revisionshistorik

 Visa revisionshistorik
VersionDatumAktörKommentar
0.1

  

Stefan Ehlert

  • Kopierad från gammalt dokument
0.2 Stefan Ehlert
  • Lagt till nya frågor
  • Rensat bort irrelevanta frågor
  • Grupperat frågor i kategorier
0.3 Stefan Ehlert
  • (AUT-982) Lagt till information kring sömlösa nyckelbyten

Undersidor

Ineras support

Hur tar jag kontakt med Ineras support?

För att ta kontakt med Ineras support börjar man enklast här: Kontakta oss - Inera

Vad ska jag skicka med vid kontakt med Ineras support?

Såvida det inte gäller någon av kategrierna nedan så behöver ingen specifik information inkluderas.

Jag vill göra en felanmälan:

  • Detaljerad information om vad som går fel för dig och/eller andra användare.
  • Inkludera så exakta tidsstämplar som möjligt för när problemet uppstått.
  • Om ni hamnar på IdP:ns felsida (https://idp.inera.se/_error), inkludera den kompletta URL:en med samtliga URL-parametrar.
  • Om ni får ett fel levererat via ett protokoll-svar (OIDC/SAML), inkludera gärna felkoder och felmeddeladen ni får via svaret.

Jag behöver hjälp med felsökning:

  • Detaljerad information om vad som går fel för dig och/eller andra användare.
  • Inkludera så exakta tidsstämplar som möjligt för när problemet uppstått.
  • Inkludera ert client ID (OIDC) eller ert entityID (SAML).
  • Hur ser ert användarflöde ut? Inkludera gärna information kring HTTP-trafik och OIDC- eller SAML-meddelanden.
  • Vad har du/ni redan testat för att komma vidare?

Anslutningen mot IdP:n fungerar inte:

  • Detaljerad information om vad som går fel för dig och/eller andra användare.
  • Inkludera så exakta tidsstämplar som möjligt för när problemet uppstått.
  • Inkludera ert client ID (OIDC) eller ert entityID (SAML).
  • Hur ser ert användarflöde ut? Inkludera gärna information kring HTTP-trafik och OIDC- eller SAML-meddelanden.


Fel- och statuskoder

400 - Felaktigt anrop

Denna felkod kastas vid ett flertal scenarion. Dessa kan vara bland annat:

  • Certifikatsfel (felaktig certifikatskedja)
  • Saknande certifikatsinformation (inget certifikat kunde läsas från användaren)
  • Ett attribut som begärts som antingen essential: true (OIDC) eller isRequired="true" (SAML) kunde inte erhållas via legitimeringsförsöket
  • HSA är inte tillgängligt
  • Slutanvändaren avbröt legitimeringsförsöket

Kontakta Ineras support ifall felet inte kan lokaliseras på egen hand. 

401 - Otillåten åtkomst

Detta fel indikerar att legitimeringsbegäran inte tillåts. Vanliga fel brukar vara att legitimeringsbegäran skickades med felaktigt client id (OIDC) eller entityId (SAML). Även ogiltiga signaturer på OIDC och SAML meddelanden brukar kunna orsaka statuskod 401. Om detta fel hittas så rekommenderas i första hand att konfigurationen för hur anslutningen mot IdP:n sker kontrolleras. Kontakta Ineras support ifall felet inte kan lokaliseras på egen hand. 

403 - Åtkomst förbjuden

Indikerar att någon är fel uppsatt mellan IdP:n och RP:n/SP:n. Vanliga fel brukar vara fel elller utgånget certifikat i RP:ns JWKS eller SP:ns metadata som finns inläst hos IdP:n. Som användare bör man kontakta systemadministratören för systemet man försöker logga in på och som systemadministratör bör man kontrollera med IdP-förvaltningen att metadata är korrekt och inläst.

404 - Resursen kunde inte hittas

Användaren navigerade till en icke-existerande resurs. Detta är ett vanligt fel om användaren navigerar till IdP:ns adress direkt via webbläsaren (exempelvis https://idp.inera.se/) utan att påbörja ett inloggningsförsök från en e-tjänst. För att komma kring problemet bör legitimeringsförsöket påbörjas från aktuell e-tjänst.

406 - Inte acceptabelt

Legitimeringsbegäran mot IdP:n har specifierat att legitimeringen måste slutföras med särskilda förutsättningar, exempelvis att ett specifikt personnummer och därmed en specifik person måste slutföra legitimeringsförsöket. Denna mekanism för att på förhand välja vilken person som ska slutföra legitimeringen kallas "Förval av principalen". Dokumentation för hur denna mekanism fungerar hittas här för OIDC och här för SAML.

Om denna felkod fås bör systemadministratören kontaktas i första hand för att kontrollera att de i förhand specifierade uppgifterna verkligen är korrekta och tillämpbara för denna legitimeringsbegäran.

409 - Konflikt

Kritisk information för sessionen som inte får ändras har ändrats. Denna felkod kan slutanvändaren få presenterat för sig vid två scenarion:

  • Slutanvändarens session bytte IP-adress. IP-adressen för sessionen får på grund av säkerhetsskäl inte bytas.
  • Slutanvändaren påbörjade en ny SSO-session och försöker hämta information från den gamla sessionen. Endast en aktiv SSO-session per användare kan vara aktiv på samma gång. 

412 - Förutsättningar ej uppfylld

  1. Supporten har vid något enstaka tillfälle fått rapport om att användaren mötts av kod 412. Det har då varit något i den egna klientmiljön som begränsat anslutningen och man har behövt lägga till IdP:ns adresser under Betrodda platser/Trusted Sites
    https://idp.inera.se
    https://secure.idp.inera.se
    1. Se även IdP med Edge och IE 11 och Trusted sites
  2. Ett annat fall då 412 dyker upp är om en i inloggningsflödet klickar på en knapp (t.ex. uppdragsval) två gånger i snabb följd. Då hinner det gå iväg två anrop, varefter inloggningen fallerar beroende på vilket av de två anropen som får svar först.
  3. Om slutanvändaren hamnar i ett för IdP:n oväntat läge då det förväntas att en session ska finnas men inte kan hittas så kastas denna felkod.

417 - Förväntningar uppfylls ej

Denna felkod kan innebära flera scenarion:

  • IdP:n har svårigheter med att kommunicera med externa tjänster.
  • E-tjänsten har begärt egenskaper för användaren från IdP:n som inte kan erhållas för den aktuella användaren. Detta kan exempelvis bero på saknande uppgifter i HSA eller att fel e-legitimation använts.
  • Ett ogiltigt läge har uppnåtts i IdP:n varifrån legitimeringsförsöket inte kan få fortsätta.

Kontakta Ineras support ifall felet kvarstår och orsaken till varför slutanvändaren inte lyckas legitimera sig inte kan idenfitieras på egen hand.

422 - Felaktigt format

Ett anrop skickades till IdP:n som inte kunde hanteras. Med största sannolik är något i anropet felformatterat. Kontrollera anropet ni skickar på eventuella fel. Se dokumentationen för IdP:n för hur SAML- och OIDC-anrop bör formatteras.

429 - För många anrop

Användaren har laddat om en sida under legitimeringsflödet där det inte är tillåtet att ladda om sidan. Om en slutanvändare har fått detta fel bör användaren påbörja ett nytt legitimeringsförsök.

500 - Internt systemfel

Ett internt systemfel uppstod. Dessa fel kan orsakas av en mängd olika scenarion. Om en slutanvändare fått felkod 500 och det felet inte försvinner även efter upprepade legitimeringsförsök bör Ineras support kontaktas.

502 - Certifikatskedjan kunde inte byggas

Ett internt systemfel uppstod där en certifikatskedja inte kunde byggas eller verifieras korrekt. Ett sådant fel kan medföra allvarliga problem som påverkar möjligheten för slutanvändare att kunna legitimera sig via IdP:n. Ta kontakt med Ineras support för vidare information om när felet kan vara avhjälpt. 


Övriga fel

No certificate selected / Inget certifikat användes

Kortets certifikat lyckades inte föras över till IdP. Kontrollera att kortet sitter i kortläsaren, NetId är installerat och har information om kortet/certifikaten under E-legitimationer, kortläsaren fungerar och att det är rätt kort för aktuell miljö (testkort fungerar inte i produktionsmiljöer och tvärtom).

Status of certificate: NAME_CHAINING

Valt certifikat på kortet är inte utgivet av en godkänd utgivare. Beroende på vilken miljö legitimeringsförsöket sker så är endast dessa utfärdare godkända:

Test/Stage:

  • TEST SITHS e-id Root CA v2
    • TEST SITHS e-id Person HSA-id 3 CA v1
    • TEST SITHS e-id Person HSA-id 2 CA v1
    • TEST SITHS e-id Person ID 2 CA v1
    • TEST SITHS e-id Person ID 3 CA v1
    • TEST SITHS e-id Person ID Mobile CA v1

Produktion:

  • SITHS e-id Root CA v2
    • SITHS e-id Person HSA-id 3 CA v1
    • SITHS e-id Person HSA-id 2 CA v1
    • SITHS e-id Person ID 2 CA v1
    • SITHS e-id Person ID 3 CA v1
    • SITHS e-id Person ID Mobile CA v1

Error during authentication: Non-matching Levels of Assurance

E-tjänst begärde autentisering med annan nivå än den som användarens certifikat utvärderades till. Vanligaste felet är att legitimeringsbegäran förväntar sig tillitsnivå 3 men legitimeringen slutförs med tillitsnivå 2.


Frågor kring användarflöden

Hur och när påverkas min autentiseringsanslutning av störningar i nationell HSA katalog?

Om er anslutning INTE begär valbara attribut (via registrerat metadata) vars källa anges som HSA på Attributlista utan endast har behov av attribut från autentiseringen i sig (t ex tidpunkt och certifikatsutfärdare) och själva certifikatet (t ex personnummer/HSAid och tillitsnivå) är er anslutning ej beroende av HSA. För detaljer rekommenderas studier av hela Attributlista-sidan och dess mappningsmatriser. OBS: beroende till de på certifikaten angivna OSCP/CRL-tjänsterna kan av uppenbara skäl inte undvikas.

Vad krävs för att vår tjänsts användare ska kunna göra ett användarval på nytt?

Byte av användarval (exempelvis medarbetaruppdragsval) görs genom utloggning med efterföljande inloggning.


Frågor relaterade till SAMBI

Kommer IdP att bli en av Sambi godkänd intygsutfärdare?

Det finns inga planer på detta idag. De tekniska kraven som uppfylls oavsett godkännande är dessa: https://www.sambi.se/wordpress/wp-content/uploads/2014/12/Sambi-Bilaga-2-Tekniska-krav.pdf 

Kommer IdP:en att driftas lokalt (av landstingen/vårdgivarna) eller nationellt (av t.ex. Inera)?

IdP:n finns som två leveranser. Dels den Nationella som primärt är till för de nationella tjänsterna (NPÖ, Intygstjänster, Pascal, Svevac etc), dels som en lokal tjänst som olika aktörer kan ladda ned och installera & drifta på egen hand. Se https://www.inera.se/sakerhetstjanster för vilka aktörer som kan beställa och nyttja den lokala Idp:n. Den Nationella IdP’n kan man även få avtala om att nyttja såsom en tjänst.

Kommer det finnas testmiljöer för SAMBI?

Kanske, det finns 2 testmiljöer för Säkerhetstjänster - IdP, TEST och QA. Båda kan i framtiden komma att aktiveras mot Sambis trialmiljö.

Krävs avtal av något slag för användning av Sambis testmiljöer?

För trialmiljön hos Sambi krävs inget avtal


Gemensamma anslutningsfrågor

Vi vill ansluta en ny systemtestmiljö till ett befintligt system. Behövs det en ny förstudie då?

Delvis, det behövs en uppdaterad förstudie som reflekterar testmiljöerna för att felsökning och support ska kunna fungera. Skicka uppdaterad förstudie och nytt metadata i ett ärende till Ineras kundservice med information om e-tjänst, miljö, systemID och nät (Sjunet/Internet).

Om en SP/RP utvecklar en större ny funktion (t ex ett administrationsgränssnitt) behövs då ny förstudie?

Delvis, uppdatera befintliga förstudien och tydliggör denna ändring funktion, specificera ev skillnader mellan lagrum, syfte och SAML/OIDC attribut/claims och skicka in till Ineras Dokumentgranskning, glöm inte att bifoga metadata i ärendet som då skapas (eller kombinera förstudie och metadata i en zipfil).

Finns det någon Utility-SDK eller motsvarande för de funktioner som SP ska göra?

Ja. Det finns både färdiga produkter som kan användas som SP och underliggande bibliotek då SP-funktionaliteten skall implementeras i den egna produkten.

Vad måste jag testa innan vi går vidare mot produktionsmiljön?

Det är upp till anslutande systems förvaltning att besluta om omfattning och strategi för att testa applikationen men nedan finns en lista på minimikrav och rekommenderade tester.

Obligatoriska tester innan anslutning mot produktionsmiljön:

  • Inloggning fungerar som avsett
  • Alla valda autentiseringsmetoder fungerar
  • Rätt claims/attribut returneras (om det ska returneras några)
  • Inloggning fungerar på olika enheter
  • Med en inloggad användare, försäkra att en annan användare måste autentisera sig vid inloggning
  • Med flera inloggade användare, utloggning påverkar inte en annan användare
  • Inloggning misslyckas då obehörig försöker ansluta

Rekommenderade tester att utföra, om applicerbara:

  • Inloggningsflöde utan uppdragsval
  • Inloggningsflöde med HSA-uppslag och val av medarbetaruppdrag
  • Växla användare på samma SP
  • Efter inloggning på en SP, logga in på en till utan att behöva upprepa autentiseringsstegen
  • LogoutRequest från SP1 så måste ny SP3 autentisera sig
  • Kontrollera att rätt LoA-nivå returneras i biljett/token
  • Testa att attribut som listas i förstudie kan returneras med korrekta värden i biljett/token från HSA, och vice versa (inte fler än som angivits)
  • Försök att logga in med utgånget kort/cert
  • Försök att logga in med spärrat kort
  • Testa att inloggning med för låg LoA inte tillåts
  • SAML: Testa inloggning med ForceAuthn="true" för att tvinga ny autentisering

Krävs SITHS-kort eller motsvarande även i testmiljöer?

Ja. För att testa att inloggingsflöden fungerar som de ska måste dessa testas med testkort. Om ni vill kan Inera leverera testkort här: https://www.inera.se/kundservice/formular/bestall-tjanst/SITHS/formular...bestall-testkort-utfardade-i-siths-preprod-miljo/. Även SITHS ombud kan leverera dessa.

Hur kan jag testa mina SITHS eID:n?

Kommer det att finnas stöd för inloggning till Windowsapplikationer (rika klienter)?

Inera och dess IdP har hitintills för de lokala installationerna av IdP’n haft stöd för autentisering även till Windowsklienter via WS-Trust.
Detta stöd avser man att ej längre tillhandahålla då efterfrågan hitintills har varit noll.
Förslaget till kunderna är att i sina Windowsapplikationer bygga in stöd för WEB-SS0, ex via embedded webläsare. Förutsättningarna ute i landet är så varierande att det är svårt att tillhandahålla något generellt.

Vem är det som ska tillhandahålla en IdP? Vårdgivaren eller systemleverantörer?

Generellt sätt kan man säga att det är användarorganisationens ansvar att hålla med en IdP. Det är ju ytterst användarorganisationens ansvar att tillhandahålla uppgifter till eTjänsterna så att de kan säkerställa användarens behörigheter i eTjänsten.
Dock så är det ju både rimligt & möjligt att användarorganisationen kan köpa detta som en tjänst. T.ex av Inera -eller någon annan leverantör av en IdP.
Användarorganisationen äger dock ansvaret att förse IdP'n med kvalitetssäkrade uppgifter kring sina medarbetare, ex via HSA-katalogen.

Kommer vi att få Single Sign-on (SSO) om vi ansluter våra system till IdP?

Med SSO menas att en användare genom EN inloggning får åtkomst till de system användaren är behörig till. För att SSO ska fungera så måste de system som användaren vill ha åtkomst till vara anslutna till samma IdP. En förutsättning för att få SSO är att det är samma HTTP-session som används gentemot IdP'n. Med detta menas att det är samma webbläsare som används för att logga in i de olika applikationerna.

Kommer Ineras IdP att kunna ställa ut biljetter med de attribut som eHälsomyndigheten kräver för kommunikation med deras tjänster?

Ja, förutsatt att verksamheterna för sina medarbetare har angivet dessa i sin katalog (HSA), se /wiki/spaces/CHDOK/pages/3475212224

Vi kommer byta våra signeringsnycklar, hur säkerställer vi att det blir ett sömlöst byte?

Både OIDC och SAML möjliggör sömlösa nyckelbyten. För att åstadkomma detta behöver IdP:n få tag i den nya nyckeln inför att den befintliga/gamla nyckeln går ut. Dokumentation för hur ett sömlöst nyckelbyte genomförs hittas här för OIDC och här för SAML.


Anslutningsfrågor SAML

Hur ska vi exportera vår SP:s SAML V2.0 Metadata?

Som SP MÅSTE man på något sätt skapa metadata, antingen manuellt eller automatiskt. Publiceringen av metadata enligt ”well known location” dvs på samma url som dess id (entitiy-id) är dock frivilligt. Se t.ex. IdP:ns metadata (testmiljö) som man direkt kan hämta från tjänsten på https://idp.ineratest.org/saml. Som SP räcker det dock att man kan förmedla tjänstens metadata t.ex. via ett ärende och Inera Support.

Kan vi validera vårt SAML Metadata i någon utsträckning innan vi skickar in den?

Ja, validering kan göras med hjälp av flera verktyg:

Ytterligare verktyg som rekommenderas:

Behöver en SP signera <saml2p:AuthnRequest> meddelandet?

Nej, detta är inte ett krav. Om en SP ändå signerar alla sina AuthnRequests och vill att IdP skall validera att AuthnRequest faktiskt är signerade så kan detta styras i metadata genom att sätta AuthnRequestsSigned="true" på <SPSSODescriptor>-elementet. IdP:n kommer då endast acceptera AuthnRequests från denna SP om de är signerade.

Behöver en SP använda Identity Discovery Profile [SAML2Prof]?

När SAMBI blir realiserat kommer det finnas krav på att man som SP måste stödja användning av val av IdP via en så kallad Discovery Service. Detta är dock något som inte finns på plats ännu och som SP skulle man kunna skjuta på denna implementation till ett senare tillfälle.

Vad gäller för SP och stöd för HTTP-POST?

För SSO response, ska SP minst stödja HTTP-POST. Ytterligare uppgifter om krav på bindings finns i förstudien.

Behöver en SP hantera ”unsolicited responses”, så kallad Idp-initierad inloggning?

Det rekommenderas att SP stödjer Idp-initerad inloggning. Om SP dock anger i metadata att den alltid kommer att signera sina AuthnRequests så kommer IdP:n inte att behandla begäran om idp-initierad inloggning mot SP.

Behöver en SP verifiera signaturen på den utfärdade SAML-biljetten?

Ja. Notera att enbart Assertion-delen i ett SAMLResponse signeras. Detta i enlighet med SAMBI-profilen.

Behöver en SP stödja SLO?

Rent tekniskt är det inget måste för att få SSO att fungera. Dock krävs SLO stöd om en meningsfull utloggning av användaren skall kunna ske. Om en SP inte har möjlighet att avsluta en SSO-session hos IdPn så medför en lokal utloggning inget då SSO kan erhållas om ny anslutning till SP'n görs. Likaså krävs SLO stöd om en användare vill byta uppdrag.

Kan man använda SAML och MS ADFS?

Ja, se Attributstyrning SAML för mera information om hur metadata ska vara utformat i fallet med ADFS.

Hur blir det med anvisningstjänst (discovery service) för val av identifieringstjänst? Behövs det och stöds det i så fall av IdP?

I Sambifederationen kommer det att behövas en hänvisningstjänst (discovery service), denna kommer att tillhandahållas av federationen. Det är dock ännu så länge oklart vilka användningsmönster som ska stödjas i Sambi. Beroende på vilken ”typ av SP” man är i Sambifederationen och vilka användarorganisationer det är som ska nyttja SP’n så kan en SP själv välja att tjäna som en hänvisningstjänst. T.ex om SP’n endast har två användarorganisationer så kan den välja att enbart hänvisa till dessa två.

Det finns också ett alternativ med IdP-initierad inloggning där användarorganisationen bestämmer vilken IdP som ska användas. Ett mönster som som Ineras eTjänster följer är att SP-initierad inloggning leder till Ineras IdP, om en organisation vill ha en annan IdP så ska man använda IdP-initierad inloggning. Detta kan realiseras genom en användarportal hos användarorganisationen som innehåller de URL:ar som leder till rätt IdP för den användarorganisationen.


Gemensamma felsökningsfrågor

Hur kan jag effektivt felsöka min anslutning?

Ineras tjänsteförvaltningar och leverantörer med tillgång till Ineras Kibanainstallation på elk.drift.inera.se/ (kräver VPN konto) kan själva söka och läsa efter alla testmijlöers loggar. Indexet heter "ind-*idp*,-ind-pidp-*"


Felsökningsfrågor SAML

Hur kan jag ta fram min etjänsts SAML AuthNRequest (HTTP-POST) för felsökning?

  1. Setup
    1. Starta Chrome, Firefox, IE11 eller annan webbläsare med utvecklarverktyg
    2. Tryck F12, utvecklarverktygen kommer fram
    3. Om det inte är aktiverat, starta registrering av nätverkstrafik genom att välja flik som heter "Nätverk/Network" eller liknande
    4. "Play/record" om det inte redan spelas in
    5. Klicka i "Preserve log" (Chrome) eller klicka ur "Rensa poster vid navigering" (Edge)
    6. Läget ska likna ett av dessa i Chrome respektive Edge (klicka för större bild):
  2. Browsa till etjänsts inloggningssida och påbörja autentisering
  3. Notera när en rad med SAMLRequest= i anropet syns, då har AuthNRequest-et fångats
  4. Kopiera den urlen/raden i anropslistan med HTTP-Redirect?SAMLRequest i sig enligt 4) ovan (högerklicka på raden och Kopiera URL eller liknande)
  5. Gå till https://www.samltool.com/url.php
  6. Klistra in url i rutan "Data to be URL Decoded"
  7. Tryck ”URL Decode Data”
  8. Kopiera den resulterade (väldigt likartad) texten
  9. Gå till menyalternativet två steg ner, "Base 64 Decode + Inflate", https://www.samltool.com/decode.php
  10. Klistra in i översta rutan "Deflated and Encoded XML"
  11. Ta bort all text innan är-likamed tecknet (t ex ”https://idp.ineratest.org/saml/sso/HTTP-Redirect?SAMLRequest=”)
  12. Klicka "Decode and Inflate XML"
  13. AuthNRequest- finns nu troligen i nedersta rutan

Hur kan jag fånga fram min etjänsts SAML response (HTTP-POST)?

  1. Se avsnittet om Setup ovan (verkar endast fungera i Edge. Chrome visar inte innehållet)
  2. Browsa till etjänsts inloggningssida och påbörja autentisering
  3. Välj eventuellt medarbetaruppdrag
  4. Notera när en rad med "indentity-response" fångats (Innehållstyp: Dokument)
  5. Kopiera hela värdet i fältet "SAMLResponse" under "Text"->"Svarstext" tabben.
  6. Gå till https://www.samltool.com/decode.php och klistra in hela respons-värdet och dekoda så kommer SAML biljetten visas:


Felsökningsfrågor OIDC

Hur kan jag ta fram min etjänsts OIDC request (endast jwt) och se vilka scope/claims som begärs?

  1. Se avsnittet om Setup ovan
  2. Browsa till etjänsts inloggningssida och påbörja autentisering
  3. Notera när anropet mot <IdP-domän>/oidc/authenticate skett (oftast första utanför etjänstens domän)
  4. Filtrera "Innehållstyp" på Annat/Other så bör anropet ligga överst (metoden ska vara POST)
  5. Titta på detaljerna för "Headers"->"Form Data" (Chrome) och "Text"→"Begärantext" (Edge) om de inte syns till höger när du markerat anropet
  6. Läget ska likna följande i Chrome respektive Edge (klicka för större bild):
  7. Markera och kopiera värdet av "request" parametern (i Chrome kan man behöva rensa "request")
  8. Gå till https://jwt.io/ och klistra in i "Encoded" fältet (algithmen RS256 sätts från jwt:n).
  9. Under Payload finns nu den autentiseringsförfrågan som etjänsten skickade.:

Publik Information