Gå till slutet av bannern
Gå till början av bannern

FAQ - IdP

Hoppa till slutet på meta-data
Gå till början av metadata

Du visar en gammal version av den här sidan. Visa nuvarande version.

Jämför med nuvarande Visa sidhistorik

Version 1 Nästa »

Innehåll:


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

  • Nej, det är inte nödvändigt för ett befintligt system. Skicka nytt metadata i ett ärende till Ineras kundservice med information om e-tjänst och nät (Sjunet/Internet).

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

  • Nej, uppdatera befintliga förstudien och skicka in till Ineras Kundservice för granskning.

Fråga: 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. Exempel på produkt är "Shibboleth Service Provider". Som bibliotek kan nämnas "Sustainsys.Saml2", "opensaml" eller "oiosaml" (som bygger på opensaml).

Fråga: Hur ska vi exportera vår SPs 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. säkerhetstjänsters metadata (testmiljö på internet) som man direkt kan hämta ifrån tjänsten på https://idp2.acctest.sakerhetstjanst.inera.se/idp/saml. Som SP räcker det dock att man kan förmedla tjänstens metadata t.ex. via mail till IdP:ns förvaltningsorganisation.

Fråga: Kan vi validera vår SAML Metadata i någon utsträckning innan vi skickar in den?

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

  • Nej, detta är inte ett krav enligt sambi-profilen.

Fråga: 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.

Fråga: 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.

Fråga: Behöver en SP hantera ”unsolicited responses”?

  • Ja en SP ska stödja unsolicitated responses”. Om man ska prioritera så är detta något man kan implementera senare.

Fråga: 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.

Fråga: 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 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.

Fråga: 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.

Fråga: Kommer Ineras IdP att av Sambi bli en godkänd intygsutfärdare?

Fråga: 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?

Fråga: Kommer Ineras ”IdP 1.0” ha samma förmågor och fungera på samma sätt som säkerhetstjänsters autentiseringstjänst gör idag (detta utifrån en service providers perspektiv)?

  • Avsikten med IdP 1.0 är att kunna svara upp till Sambis 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. Målsättningen är att inga (eller ytterst få) implementationsändringar skall behöva ske.

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

  • Ineras IdP finns som två leveranser. Dels den Nationella som primärt är till för de nationella tjänsterna (NPÖ, Pascal, Svevac etc), dels som en lokal tjänst som man (landstingen) gratis kan ladda ned och installera & drifta på egen hand. Den Nationella IdP’n kan man även få avtala om att nyttja såsom en tjänst.

Fråga: Hur blir det med hänvisningstjänst (discovery service) för val av identifieringstjänst? Behövs det och stöds det i så fall av IdP 1.0

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

Fråga: Kommer det finnas testmiljöer för SAMBI?

  • Ja, det finns 2 testmiljöer, dels en ”trial” i Sambis trialmiljö, dels en QA-miljö (mer kontrollerad).

Fråga:  Krävs avtal av något slag för användning av ev. testmiljöer?

  • För trialmiljön hos Sambi krävs inget avtal, för QA-miljön behövs ett avtal.

Fråga: Krävs Efos-kort eller motsvarande även i testmiljöer?

  • För Säkerhetstjänsternas IdP i QA-miljön krävs SITHS/Efos. Framöver kanske IdP’n även kan komma att stödja flera kort/inloggningsmetoder. För Trialmiljön i Sambi finns det stöd för flera olika typer av identitetshandlingar.

Fråga: 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.

Fråga: 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.

 Fråga: Kommer vi att få Single Sign-on (SSO) om vi ansluter vårt journalsystem till Ineras 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.



  • Inga etiketter

Publik Information