Jämförda versioner

Version Gammal version 9 Ny version Aktuell
Ändringar gjorda av

Stefan Ehlert

Stefan Ehlert

Sparat den

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.

Innehållsförteckning

Expandera
titleVisa innehållsförteckning

Innehållsförteckning

Revisionshistorik

Expandera
titleVisa 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

Expandera
titleVisa undersidor

Underordnade sidor (visning av underordnade)

Ineras support

Hur tar jag kontakt med Ineras support?

...

  • 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

...

  • 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. Som användare bör man kontakta 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.

...

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

...

  • 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.

...

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

Image Modified

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).

...

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 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.

Anslutningsfrågor SAML

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 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?

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?

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

  • Nej, detta är inte ett krav enligt sambi-profilen. 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.

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

  • SP måste ha stöd för SLO och uppdragsbyte görs genom utloggning med efterföljande inloggning.

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

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

Kommer denna IdP ha samma förmågor och fungera på samma sätt som den äldre IdP:n gör idag (detta utifrån en service providers perspektiv)?

  • Avsikten med denna IdP är att kunna svara upp till Sambis och eHälsomyndighetens krav såsom en intygsutfärdare
  • Det kommer inte att ske någon försämring utifrån nuvarande funktionalitet. För många SP's kommer ett byte till nästa IdP kunna ske genom att uppdatera sitt metadata och byta till nytt IdP metadata samt skicka in en ny förstudie med den nya mallen. Se Anpassning av SP vid byte från nuvarande autentiseringstjänst till Inera IdP 1.0 för information om vilka tekniska förändringskrav som ställs på SP. OBS: Om er organisation ej tecknat Kundavtal 2 eller avtal för användning av tjänst kommer detta behövas INNAN den tekniska, uppdaterade anslutningen kan påbörjas, se https://www.inera.se/tjanster/sakerhetstjanster/Sakerhetstjanster/ under "Beställ Säkerhetstjänster - IdP".

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.

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.

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

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?

 Kan jag testa mina autentiseringsmetoder

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årt journalsystem 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/få en SAML-biljett av, vara samma IdP som användaren loggade in till. 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.

Kan man använda SAML och MS ADFS?

 Vad betyder felmeddelandet "HTTP ERROR 403 Problem accessing /idpidx509 Invalid x.509 certificate response vid inloggning?"

  • Det är något problem med certifikatet, överföring till IdP har ej fungerat. Pröva med att starta om webläsaren. Exempel på orsaker;
    • Användning av certifikat (kort) i en miljö som inte har tillit till en utgivare (testkort i produktionsmiljö eller vice versa)
    • Användning av kort med certifikat från utgivare IdPn inte har tillit till (företagskort etc), se även fråga 21 ovan

Vad betyder felmeddelandet "Inget certifikat valt"?

  • Det finns inget certifikat att läsa. Kontrollera kortläsaren och att kortet sitter i.

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):
      Image Removed
  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 ta fram min etjänsts OIDC request (endast jwt) och se vilka scope/claims som begärs?

...


...

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):
      Image Added
  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):
    Image Removed
  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.:
    Image Removed
  10. en rad med SAMLRequest= i anropet syns, då har AuthNRequest-et fångats
  11. Kopiera den urlen/raden i anropslistan med HTTP-Redirect?SAMLRequest i sig enligt 4) ovan (högerklicka på raden och Kopiera URL eller liknande)
  12. Gå till https://www.samltool.com/url.php
  13. Klistra in url i rutan "Data to be URL Decoded"
  14. Tryck ”URL Decode Data”
  15. Kopiera den resulterade (väldigt likartad) texten
  16. Gå till menyalternativet två steg ner, "Base 64 Decode + Inflate", https://www.samltool.com/decode.php
  17. Klistra in i översta rutan "Deflated and Encoded XML"
  18. Ta bort all text innan är-likamed tecknet (t ex ”https://idp.ineratest.org/saml/sso/HTTP-Redirect?SAMLRequest=”)
  19. Klicka "Decode and Inflate XML"
  20. 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)
    Image Modified
  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:
  7. Image Modified


...

Felsökningsfrågor OIDC

Hur kan jag

...

  • 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-*

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

...

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):
    Image Added
  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.:
    Image Added