FAQ - IdP

Owned by Former user (Deleted)
Last updated: dec. 11, 2023 by admin (Unlicensed)Version comment
12 min read

Innehåll:

Undersidor:


vilka förmågor har IdP 1.x?

  • Stöd för OpenID Connect   baserat på Heart-profilen http://openid.net/specs/openid-heart-oauth2-1_0-2017-05-31.html samt OAuth 2.0 för auktorisering. Observera att OAuth2 kan kombineras med OIDC och SAML.
  • På sikt stöd för mobil autentisering.
  • Stöd för det som kallas för "Medarbetaruppdrag" som används för vårdverksamhet och för "Administrativa uppdrag" som kan användas för behörighetsstyrning av administrativa system.
  • Integration med tjänstekontrakt för behörighetshantering 2.1.x som finns här 
    http://rivta.se/domains/domain-infrastructure_directory_authorizationmanagement.html
  • Korrekt hantering av LOA-nivå, dvs endast produktionskort SITHS får LOA3, även reservkorten blir LOA3 i produktion.
  • Parametern RequestedAuthnContext kan endast användas för att specifiera begärd LOA-nivå från SP:n, enligt https://www.sambi.se/wordpress/wp-content/uploads/2014/12/Sambi-Bilaga-2-Tekniska-krav.pdf, dvs SP (Service Provider) kan endast signalera LOA-nivå, ej autentiseringsmetod.
  • Enbart attribut som efterfrågas kommer att returneras i biljetten, tidigare fick man allt.
  • LogoutRequest kommer inte att propageras till andra SP:ar, dock termineras SSO sessionen så att en ny SP måste autentisera sig
  • Driftsätts i en Openshift-miljö för enklare deploy och möjlighet till orkestrering.
  • Testmiljöer  finns tillgängliga

vilka förmågor har IdP 2.x?

 kan jag använda OTP (SMS-inloggning) för att autentisering i min e-tjänst?

  • Nej, SMS-inloggning är borttagen fr o m IdP 1.x och ersätts av inloggning via Mobilt SITHS.

om mitt system redan är ansluten till den nuvarande autentiseringstjänsten som ingår i lokala Säkerhetstjänster, vad måste jag göra för att gå över till IdP från Inera?

kommer det att finnas en lokal IdP att installera i egen driftsmiljö och skiljer den sig från den nationella?

  • Ja, det finns en lokal IdP som i stort är identisk med den nationella förutom att det finns möjlighet att konfigurera till egen katalog i stället för Katalogtjänst HSA. Se www.inera.se/sakerhetstjanster för vilka som kan beställa och nyttja den lokala IdP:n.

hur passar detta in när det gäller rika klienter, t ex journalsystem?

Fel/Status-koder

403 Åtkomst nekad

Indikerar att någon är fel uppsatt mellan IdP och SP. 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.

412 

  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. Problemet planeras att rättas i IdP 2.0


No certificate selected

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 Administration, 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, idag endast olika varianter av SITHS Type 3 CA v1 och SITHS e-id Root CA v2

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 (oftast begärs nivå 3 men autentiseringen görs på nivå 2, t ex gamla SITHS certifikat eller reservkort i testmiljö efter 1/10 2020)

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

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

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:

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


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.





Publik Information