Innehållsförteckning
...
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?
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.
- För SAML-sidan är exempel på produkt "Shibboleth Service Provider". Som bibliotek kan nämnas danska statens OIOSAML (finns både C# och Java), "Sustainsys.Saml2", "opensaml". Se sammanställning på https://medium.com/the-new-control-plane/i-need-a-saml-stack-now-63d9691e2d43
- För OIDC, se https://openid.net/developers/certified/
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:
- https://admin.idp.inera.se/public/validate-saml, om metadatat valdieras korrekt av IdP:ns egen validator kan metadatat läsas in i IdP:n
- https://validator.sambi.se/validator/, den denna är dock inte heltäckande men ger bra grundförutsättningar
Behöver en SP signera <saml2p:AuthnRequest> meddelandet?
...
Ytterligare verktyg som rekommenderas:
- https://tools.chilkat.io/xmlDsigVerify.cshtml, för validering av XML-signaturer
- https://redkestrel.co.uk/tools/decoder, för att inspektera publika certifikat
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.
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.
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 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?
Ja, förutsatt att verksamheterna för sina medarbetare har angivet dessa i sin katalog (HSA), se /wiki/spaces/CHDOK/pages/3475212224
Kommer
...
- 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: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?
...
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?
- Produktion: https://test.idp.inera.se/
- TEST/QA-miljö Stage: https://test.idp.ineraqa.org/
- Test: https://test.idp.ineratest.org/
...