Välkomna till introduktionskurs i Sambi

Vad är IIS? Internetstiftelsen i Sverige https://www.youtube.com/watch?v=jkeioxrmcny

IIS är federationsoperatör

Sambis styrgrupp Från vänster: Petter Könberg, Inera, Danny Aerts, IIS (styrgruppsordförande), Carina Landberg, IT-forum Stockholms län. Saknas på bilden: Stefan Leonardsson, ehälsomyndigheten, Stephen Dorch, ehälsomyndigheten

Dagens agenda 09.00 Varför Sambi? 10.00 Fika 10.15 Vad är Sambi och hur fungerar Sambi? 12.00 Lunch 12.45 Teknik, SSO, SAML, Metadata 14.15 Fika 14.30 Status, pågående arbeten, komma igång, sammanfattning, examensprov! 16.00 SLUT

Kort presentation av deltagarna Vilka är ni och varför ni är intresserade av Sambi? Vad förväntar ni er av kursen?

Förmiddagens agenda 09.00 12.00 Fikapaus ca kl 10.00 10.15 Lunch kl 12.00 VARFÖR SAMBI Bakgrund och historia Förstudie och 16 principer Målsättning, målgrupper VAD ÄR SAMBI Federation och identitetsfederation SAML Tillitsramverk LOA Behörighetsstyrning genom attribut HUR FUNGERAR SAMBI Organisation, arbetsformer Arkitektur och identitetshantering

Varför Sambi?

Bakgrund & Historia 2007 Swamid - Den tekniska förebilden 2011 SIS/TK450 - Skolfederation 2012 De 16 principerna för samverkan IT-forum, Kommunförbundet Stockholms län (KSL) 2012 Förstudie Sambi, för sektorn vård, omsorg och e-hälsa Ett samarbete mellan ehälsomyndigheten, Inera och IIS Värd att läsa!

De 16 principerna för samverkan (KSL) Informationssäkerhet 1. att ha en antagen informationssäkerhetspolicy, eller motsvarande, med tillhörande styrande dokument 2. att ha minst en utsedd person som leder och samordnar informationssäkerhetsarbetet 3. att tillämpa en likvärdig metod och jämförbara nivåer för informationsklassning 4. att utifrån återkommande riskanalyser och inträffade incidenter vidta nödvändiga åtgärder för att upprätthålla rätt skyddsnivåer Tillit 5. att tillämpa gemensamma tillitsramverk för att skapa tillit över huvudmannagränser 6. att koppla informationstillgångar till relevanta tillitsnivåer

De 16 principerna för samverkan, forts. Federering 7. att ha förmågan att utfärda och/eller konsumera elektroniska identitets- och behörighetsintyg. 8. att säkerställa att alla delar i det elektroniska identitets- och behörighetsintyget följer aktuella tillitsramverk. 9. att kravställa federativ förmåga i varje tjänst. 10. att tillämpa gemensamma respektive sektorsrelaterade attribut som används i samverkan. Grundläggande infrastruktur 12. att tillse att all gränsöverskridande kommunikation kan ske över internet. 13. att verka för att kommunikation över öppen infrastruktur signeras och krypteras. 14. att säkerställa robusthet i för samverkan vitala infrastrukturkomponenter. 15. att den egna källan för tid är spårbar till den svenska nationella tidsskalan. Signering 11. att medverka till teknik- och leverantörsneutrala framtagna informationsstrukturer. lösningar för elektroniska underskrifter. -Är reviderat! 16. att kravställning bör bygga på nationellt

Principer för digital samverkan, i Sthlms län Utgå ifrån invånarnas behov Upprätthåll rätt nivå på informationssäkerhet och integritet Delegerat mandat och ansvar Låt behov och nytta vara styrande Säkerställ ledning och styrning av informationssäkerhetsarbetet Aktivt arbeta med federation och tillit Tillämpa gemensamma begrepp och informationsstrukturer Tillgängliggör information som öppna data Hämta information vid källan Använd standarder Säkerställ digitala tjänsters tillgänglighet

Principer för digital samverkan, i Sthlms län Syfte Principerna för digital samverkan syftar till att få regional samsyn kring digital samverkan, uttrycka vilka som är prioriterade principer i Stockholms län och även att underlätta utbyte av information mellan aktörerna vilket skapar förutsättningar att både förenkla och effektivisera för både invånare och verksamhet. Målgrupp Principerna har indelats i grund- och arkitekturprinciper för digital samverkan. Grundprinciperna vänder sig till högre tjänstemän/chefer och arkitekturprinciperna vänder sig till ITbeslutsfattare i kommuner eller landstinget. De områden som är mest prioriterade för digital samverkan i Stockholms län är informationsdelning, federation och tillit. Våra arkitekturprinciper har därför extra tyngdvikt på dessa områden.

Förstudie Sambi, för sektorn vård, omsorg och e-hälsa Ett samarbete mellan ehälsomyndigheten, CeHis, Inera och IIS. Rapporten kom 2012-06-15 Uppdraget var att ta fram en tjänstebeskrivning avseende en identitets- och behörighetsfederation för vård och omsorg Visionen: Federationen skall fungera som en nationell mötesplats för säkra e-tjänster genom att vara det infrastrukturella navet som sammanlänkar e-tjänster och användarorganisationer i en lösning som bygger på tillit och skydd för den personliga integriteten Rapporten blev en kravställning och underlag till projektdirektiv för hur Sambi skulle byggas upp

Mål som Sambi kan stötta 90% av medarbetarna kan år 2016 nå sina professionella verksamhetssystem med en samordnad, enkel och säker inloggning (single-sign-on) Ref: CeHis Handlingsplan 2013-2018?

Mål för Sambi Tillhandahålla en infrastrukturlösning för säker åtkomst av e-tjänster för hela sektorn ehälsa. Vara det självklara valet för organisationer som vill uppnå en optimerad nivå på hanteringen av identiteter och behörigheter samt skyddet av den personliga integriteten i sina verksamheter. Underlätta för informationsägare att fullgöra de skyldigheter som bland annat följer av personuppgiftsansvaret. Ur förstudierapporten Identitets- och behörighetsfederation för ehälsa

Mål för Sambi, forts. Vara ett självklart alternativ till att utforma separata lösningar för hanteringen av identiteter och behörigheter, separat för varje enskilt system, i varje enskild organisation. Tillhandahålla en gemensam och tydlig infrastruktur, baserad på standard, som erbjuder marknaden en tydlig bas för tillhandahållande av effektiva e-tjänster. Fungera som ett forum som verkar för medlemmarnas gemensamma intressen, verkar för samverkan, kunskapsutveckling, erfarenhetsutbyte och där spridning av goda exempel möjliggörs. Ur förstudierapporten Identitets- och behörighetsfederation för ehälsa

SEKTORN Ökad säkerhet Stimulera utveckling ANVÄNDARORGANISATION Valfrihet att välja sin egen lösning Enklare tjänsteintegration Enhetlig administration av användare TJÄNSTELEVERANTÖR Underlätta för informationsägare att fullgöra sina skyldigheter som bland annat följer av personuppgiftsansvaret Slippa administration av användare Enklare integration av vårdgivare ANVÄNDARE SSO, en inloggning till alla tjänster

Målgrupper för Sambi enligt förstudierapporten Kommuner Privata omsorgsgivare Apoteksaktörer Veterinärer Landsting Tandläkare Privata vårdgivare Regionförbund... Myndigheter Invånare Informationsinfrastruktur

Tänkbara medlemmar? 4 departement, 20 statliga myndigheter och 20 forskningsinstitutioner 21 landsting 291 kommuner 1 284 apoteksaktörer 1 933 tandläkarmottagningar

Tänkbara medlemmar? 15 000 privata vård- och omsorgsgivare 1000-tals offentliga vård- och omsorgsgivare 1 185 företag med veterinärverksamhet Leverantörer, färdtjänst, varor, journalsystem, läkemedel, etc. Patienter, exempel: diabetes appar för barn

Sambi = underlätta realisering av SSO Hösten/vintern 2015 genomförde Inera en SSO-förstudie på uppdrag av SLIT Landstingsrepresentanter utsedda av SLIT Region Skåne, VG region, Östergötland, Västmanland, Örebro, Uppsala, SLL, Region Gotland, Gävleborg, Jämtland-Härjedalen, Dalarna. Inom Strategi, Arkitektur, Klient, Katalog, Identitet och åtkomsthantering, SSO-projekt, SITHS, och så vidare. Enkäter, intervjuer/diskussioner, insamling material.

Underlätta realisering av SSO, forts. Avstämningar och möten Delrapport (nulägesanalys och inriktning) och en Slutrapport Presentationer av rapporten i olika forum (SLIT, olika program/projekt, etcetera).

SSO-rapporten Innehåll i rapporten Orienterande beskrivning av området Identitets-och åtkomsthantering (IAM) Nuläget i regioner och landsting och pågående initiativ Problemställningar och hinder Strategiska vägval Beslutsunderlag med styrande principer och åtgärdsförslag

Nuläge SSO Applikationer som saknar stöd (ingen SSO) Enkelriktade uthoppslösningar funktionalitet AD-integrerad inloggning Direkt kortinloggning i applikationen Klientbaserad SSO-agent, Enterprise SSO Klientbaserad applikationsportal - Navigator Biljettbaserad standardiserad SSO (med federationsstöd) Antal anslutna applikationer

Övningsuppgift 3-3 * 6 + 2 = -13 Eller?

Fika 10.00 10.15

Vad är Sambi?

Vad är en federation? Federation kommer från det latinska ordet för fördrag, fœdus, som in sin tur kommer från latinets fidere, att lita på, och betyder heller inte mycket mer än så; ett fördrag mellan parter som litar på varandra. Vilka som sluter fördraget, vad det går ut på, hur omfattande det är, vad som ska avgöras gemensamt och vad som ska avgöras av parterna var för sig, det vill säga vad slags stat som krävs, varierar från federation till federation. /Göran Rosenberg

Vad är en identitetsfederation? En identitetsfederation är en sammanslutning av organisationer som har kommit överens om att lita på varandras elektroniska identiteter och behörighetsstyrande attribut för att underlätta användarnas åtkomst till elektroniska tjänster och skydda den personliga integriteten. Sambifederationen blir vad federationens medlemmar vill att Sambi ska bli!

Vad är identitetshantering? I denna kontext: Den hantering som krävs för att en användare ska få erforderlig behörighet till ett IT-system IT-system DB

Hur sker vanlig identitetshantering? Ett vanligt scenario för en användare är behov av åtkomst till flera IT-system Journalsystem DB Labsystem DB Röntgensys DB I varje enskilt system administreras användaren och användarens behörighet separat Adm.system DB

Undvik olika typer av integrationer Användar- Organisation A IdP SP Tjänsteleverantör A e-tjänst Användar- Organisation B IdP SP Tjänsteleverantör B e-tjänst Användar- Organisation C IdP SP Tjänsteleverantör C e-tjänst Detta problem vill Sambi adressera

En standard för integrationen FEDERATION Gemensam regler, standard och infrastruktur ANVÄNDARORGANISATIONER TJÄNSTELEVERANTÖRER

Det handlar om säkerställda identiteter och attribut Användarorganisation Inloggning SITHS E-LEG ID IdP INTYG E-TJÄNST SP Användaruppgifter Användaradministration och kontohantering hos användarorganisationen IdP - Identity Provider SP - Service Provider

SAML 2.0 är den tekniska standarden ANVÄNDARORGANISATION TJÄNSTELEVERANTÖR INTYGSUTGIVARE INTYG pseudonym + attribut E-TJÄNST Intyget ska innehålla uppgifter för att E-tjänsten ska kunna fatta beslut om åtkomst

Distribuerat ansvar ANVÄNDARORGANISATION TJÄNSTELEVERANTÖR INTYGSUTGIVARE INTYG pseudonym + attribut E-TJÄNST ATTRIBUTS- REGISTER Varje Användarorganisation ansvarar för att dess kataloguppgifter är korrekta

Distribuerat ansvar ANVÄNDARORGANISATION TJÄNSTELEVERANTÖR INTYGSUTGIVARE Inloggnings -metoden valfri -SITHS -e-leg -BankID ATTRIBUTS- REGISTER INTYG pseudonym + attribut E-TJÄNST Varje användarorganisation ansvarar för sin e-legitimationslösning och användarhantering

Behov av en federationsoperatör ANVÄNDARORGANISATION TJÄNSTELEVERANTÖR INTYGSUTGIVARE SITHS E-LEG ID ATTRIBUTS- REGISTER INTYG pseudonym + attribut E-TJÄNST MEDLEMSREGISTER

Sambi SAMVERKAN Teknisk standard Gemensam infrastruktur Krav på säkerhet Behörighetsstyrande attribut

Tillit SAMVERKAN Teknisk standard Gemensam infrastruktur Krav på säkerhet Behörighetsstyrande attribut

Hur? Federationen skall fungera som en nationell mötesplats för säkra e-tjänster genom en lösning som bygger på tillit och skydd för den personliga integriteten Underlätta för informationsägare att fullgöra sina skyldigheter som bland annat följer av personuppgiftsansvaret

Hur underlätta för informationsägare att fullgöra de skyldigheter som bland annat följer av personuppgiftsansvaret? SITHS E-LEG ID E-TJÄNST SP Användaruppgifter

Bygg tillit över huvudmannagränser! Användarorganisation (huvudman) Användarorganisation E-TJÄNST SP Användaruppgifter klargöra och följa upp huvudmännens ansvar för sina användare och deras identitetshantering.

Medlem ett fundamentalt begrepp Användarorganisation: Organisation vars huvudsakliga uppdrag är att utföra tjänster inom hälso- sjukvårds eller omsorgsområdet. Detta inkluderar organisation med: verksamhet som har skyldighet att följa Hälso- och sjukvårdslagen, Socialtjänstlagen (SoL, Lag om stöd och service till vissa funktionshindrade (LSS), verksamhet som för att utföra sitt uppdrag har personal i verksamheten och där personalen är skyldig att följa Patientsäkerhetslagen (PSL) eller vård- och omsorgsverksamheter som lyder under respektive lag och som också har anmälningsplikt/tillståndsplikt hos IVO. Tjänsteleverantör: Organisation som tillhandahåller en eller flera E-tjänster åt Användarorganisationer.

Vad är Tillit? Vi kan ha tillit till någon utan att ha fullständig information om denna Inte bara en tro på människors goda avsikter, utan en välgrundad tro att vissa principer är uppfyllda

Tillitsnivåer - ett koncept för identiteter i federationer LoA, Level of Assurance LoA 1 LoA 2 LoA 3 LoA 4 OBS! Ingen eller liten tillit till identiteten Typ Facebook, Google, Hotmail Begränsad tillit till identiteten AD-identitet, företagsinternt, domänspecifikt Hög tillit till identiteten Svensk e-legitimation, SITHS, Pass, körkort Mycket hög tillit till identiteten Klassningen gäller endast för identiteter, inte för de behörighetsstyrande attributen.

Sambis Tillitsramverk Syftet är att medlemmarna ska känna tillit till varandra eftersom de vet att medlemmarna uppnår en känd säkerhetsnivå. Ramverket är uppdelat i följande delar Generella krav E-legitimationsutfärdare Attributsutgivare Identitetsintygsutgivare Tjänsteleverantör Sambiombud

Sambis Tillitsramverk och granskning Syftet med granskning och godkännande: Ge förlitande parter en försäkran om att vissa principer är uppfyllda utan att alla behöver ha direkt insyn

Rätt avtalspart är en viktig del i Sambis förtroendekedja Lagar och föreskrifter Riktlinjer för medlemskap i Sambi Godkänna medlemskap i Sambi Federationsoperatörens ansvar Garant för att endast behöriga Användarorganisation blir medlemmar i federationen Kontroll av att rätt organisationsuppgifter för medlemmen läggs in i federationens metadata Användarorganisationens ansvar Ansvara för Användarna Utfärda av korrekt SAML-intyg Tjänsteleverantörens ansvar Kontroll av organisationsuppgiften i SAML-intyget stämmer överens med metadata för Användarorganisationen Kontroll av övriga behörighetsstyrande attribut Beslut om åtkomst till E-tjänsten

Bensträckare 5 minuter

Övningsuppgifter Vad är federationsoperatörens ansvar? Garant för att endast behöriga Användarorganisation blir medlemmar i federationen Kontroll av att rätt organisationsuppgifter för medlemmen läggs in i federationens metadata Vad är användarorganisationens ansvar? Hålla koll på sina uppgifter kring sin organisation och medarbetare Utfärdare av korrekt SAML-intyg Vad är tjänsteleverantörens ansvar? Kontroll av organisationsuppgiften i SAML-intyget stämmer överens med metadata för Användarorganisationen Kontroll av övriga behörighetsstyrande attribut Beslut om åtkomst till E-tjänsten

Attributsförvaltning SAMVERKAN Teknisk standard Gemensam infrastruktur Krav på säkerhet Behörighetsstyrande attribut

Omfattning för Sambi attributshantering De attribut för behörighetsstyrning som sänds i intyget från Användarorganisationen Inte förbjudet för tjänsten att använda ytterligare attribut T.ex. efter inloggningen hämta attribut från annan lämplig katalog, ex en lokal AD-katalog 54

Status för attributförvaltningen

Statusrapport för attributförvaltningen

Stöd för versionshantering Namngivningen för attribut i Sambi stödjer versionshantering genom att major-version av attributet ingår i dess namn. Exempel där major-versionen är 1 : http://sambi.se/attributes/1/personalidentitynumber Exempel på användning Nedan är ett exempel på användning av attributen i SAML2.0 intyg: <saml2:attribute Name="http://sambi.se/attributes/1/personalIdentityNumber" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="personalIdentityNumber"> <saml2:attributevalue xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:type="xs:string">191212121212</saml2:attributevalue> </saml2:attribute>

Samverkan mellan Sambi och katalogtjänster Sambi står för en gemensam standard och regler, inte en attributkatalog HSA, EK etc är viktiga attributkataloger för Sambi (då de utgör en stor del av användarorganisationernas beskrivning av sina organisationer & medarbetare) Gemensamt intresse av attributkvalité

Vad Sambi inte är!

Sambi är ett ramverk, INTE en central inloggningstjänst Ej central inloggning ANVÄNDARORGANISATIONER TJÄNSTELEVERANTÖRER

Sambi förändrar inte ansvaret för åtkomstkontroll Användarorganisation Tjänsteleverantör Avtal Intyg med attribut Sambi

Inte GDPR Båda Sambis tillitsramverk och GDPR förutsätter att det bedrivs ett strukturerat arbete men deras omfattning är olika GDPR avser hantering av personuppgifter, medan Sambis tillitsgranskning endast avser tillit till identiteter och attribut Sambi underlättar för informationsägare att fullgöra sina skyldigheter som följer av personuppgiftsansvaret

Övningsuppgift Vem ansvarar för utfärdande av identitet? A. Intygsutgivaren (IdP:n) B. Användarorganisationen C. Sambi

Övningsuppgift Vem ansvarar för att avgöra behörighets-beslutet? A. Intygsutgivaren (IdP:n) B. Användarorganisationen C. e-tjänsten

Övningsuppgift Hur kan e-tjänsten fatta ett behörighetsbeslut? A. Att inloggningsbiljetten är utställd av en betrodd utfärdare B. Baserar sitt beslut på attributen i inloggningsbiljetten C. Att biljetten är utställd till e-tjänsten

Övningsuppgift Vilken LOA-nivå krävs det för hantering av patientinformation? A. 1 B. 4 C. 3

Övningsuppgift Vilka attribut är obligatoriska i Sambi? A. HSAid-medarbetare, LOA-nivå, organisationstillhörighet B. PNR-medarbetare, LOA-nivå C. Inga alls

Bensträckare 5 minut

Hur fungerar Sambi? (hur arbetar man i Sambi?)

Sambis styrgrupp Från vänster: Petter Könberg, Inera, Danny Aerts, IIS (styrgruppsordförande), Carina Landberg, IT-forum Stockholms län. Saknas på bilden: Stefan Leonardsson, ehälsomyndigheten, Stephen Dorch, ehälsomyndigheten

Sambis organisation Sambis styrgrupp Sambis löpande verksamhet Federationstjänstens förvaltningsråd Referensgrupp Sambis arbetsgrupp Sambis Federationstjänst Sambis Attributstandard Sambis Tillitsgranskningstjänst

Sambis arbetsgrupp Syftet En grupp för utbyte av information och kunskaper och bidraga till vidareutveckling av Sambi Är även en referensgrupp för gemensamma frågor inom Sambi Består av deltagare till exempel från: ehälsomyndigheten, Inera, IIS, landsting, kommuner Leverantörer: Tieto, Nexus, Svensk e-identitet, Pulsen, med flera. Träffas regelbundet, se webben

Sambis arbetsgrupp

Sambis förvaltningsråd Syftet Att hantera och kommunicera planerade förändringar inom infrastruktur och gemensamma objekt inom federationen Tjäna som en CAB inom Sambi Kommer ev även att hantera incident & problem Består bl.a med deltagare från Inera, SLL, IIS, ehm Träffas vid behov, oftast i samband med arbetsgruppsmöten

Infrastruktur - ändringar

Sambi attributsförvaltning Förvaltningen är organisatoriskt placerad på Inera, som en del av Säkerhetstjänsternas förvaltning, men uppdraget är att förvalta för Sambi Uppdraget omfattar att etablera och underhålla standard för federationens attribut Att ta fram och kommunicera en ensad bruttolista på i Sambi överenskomna attribut Omfattar inte lagring av attributen

Samverkan Samverkan utgående från olika kulturer och förutsättningar Landsting, kommunal, apoteksaktörer, Internet och akademiska federationer Offentlig och privata aktörer Regionala samarbeten Nationella initiativ som Svensk e-legitimation EU, Electronic identification and trust services (eidas)

Federationsoperatören Internetstiftelsen, IIS är federationsoperatören för Sambi. Dess uppgift är att: Att stötta och bidraga till förvaltningen och utvecklingen av Sambi Att tjäna som federationsoperatör

Sambis federationsdrift idag Medlemshantering Metadatahantering Drift av infrastrukturen Attributförvaltning Tilliten till identiteter och attribut Attributförvaltning Information

Tillitsgranskningsprocessen

Vad granskas? De generella kraven i Sambis Tillitsramverk, vilka utgörs av generella krav på: verksamheten, säkerhetsarbetet, kryptografiska säkerhet, ansvar för underleverantörer, handlingars bevarande och tillhandahållande av information För användarorganisationer och deras underleverantörer granskas Tillitsramverkets specifika krav på hanteringen av deras funktioner för e- legitimationsutfärdare, attribututgivare och identitetsintygsutgivare För tjänsteleverantör och deras underleverantörer granskas hur de uppfyller Tillitsramverkets specifika krav för tjänsteleverantörer

Sambiombud TG Federationsoperatör Sambiombud Användarorganisation

Sambiombud Sambiombudets uppgift är att förenkla Användarorganisationers anslutning till Sambi genom att paketera en teknisk och administrativ tjänst inom Sambis ramar och bistå Användarorganisationen med att lever upp till kraven i Sambis Tillitsramverk.

Intresse att bli Sambiombud Svensk e-identitet (arbete pågår) Inera planerar att bli Sambiombud

Dags för lunch kl 12.00-13.00 Kontakt info@sambi.se www.sambi.se

Övningsuppgift? 6 * 7 = 42? 5 * 6 = 30? 4 * 5 = 20? 2 * 3 = X6

Teknik https://www.sambi.se/teknik/

Agenda, teknik SAML 2.0 SSO, SLO Metadata Anvisningstjänst/Discovery Service Profiler Tekniska miljöer Därefter fika!

Traditionell inloggning Användarorganisation Användare E-tjänst Vad är det för fel på det här då? www.e-service.se www.e-service.se Användarnamn ********** DB

Exempel på problem med traditionell inloggning som SAML angriper Administration av behörigheter/tjänst Inloggning per tjänst Lösenord per tjänst Säkerhetskrav Lösenordssupport www.e-service.se www.e-service.se Användarnamn ********** DB

SP-initierad inloggning https://www.eordinationpascal.se/ Begär åtkomst 1 DB 4 Intyg 3 https://www.eordinationpascal.se/ Välkommen! Intyg 5 Begäran Begäran 2

Exemplet väcker några frågor Hur vet SP:n vilken IdP användaren kan logga in på? Hur vet e-tjänsten att den kan lita på intyget från IdP:n? Vad är det för information i intyget?

Hur vet SP:n vilken IdP användaren kan logga in på? https://www.eordinationpascal.se/

Hur vet SP:n vilken IdP användaren vill logga in på? Exempel: IdP-initierad inloggning idp.iis.se/sso=www.e-service1.se* Intyg Iis.se/portal Välkommen! e-service1 e-service2 Intyg 2 3 1 e-service3 www.e-service.se

Hur vet tjänsten att den kan lita på intyget? Intyg www.e-service.se X.509 Certifikat Metadata Out of Band Certifikat Metadata

Information i intyget (förenklat) Name ID Ex. transient / persistent ID (pseudonym) Iuerfn#y873yniuw%eyr847 Användarens attribut Namn: Kalle Karlsson E-post: kalle.karlsson@ronneby.se Organisation: Ronneby Vårdcentral Roll: Läkare Livslängd Giltig till och med 2016-02-25/13:54

<SAML AuthnRequest> Exempel på hur en SAML Request kan se ut i verkligheten <samlp:authnrequest xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" ID="_5e26e081472a56ebdd4db1be6f23ed643facddf2f3" Version="2.0" IssueInstant="2015-08-06T12:51:42Z" Destination="https://idp.example.com/simplesaml/saml2/idp/SSOService.php" AssertionConsumerServiceURL="https://sp.example.com/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST > <saml:issuer>https://sp.example.com/simplesaml/module.php/saml/sp/metadata.php/default-sp</saml:issuer> <samlp:nameidpolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:email AllowCreate="true /> </samlp:authnrequest>

<SAML Response> <samlp:response xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" ID="_dc151d8adbd6eea9236ad0bd832da03a4903c2bfd3" Version="2.0" IssueInstant="2015-08-06T12:51:52Z" Destination="https://sp.example.com/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp" InResponseTo="_5e26e081472a56ebdd4db1be6f23ed643facddf2f3" > <saml:issuer>https://idp.example.com/simplesaml/saml2/idp/metadata.php</saml:issuer> <ds:signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:signedinfo> <ds:canonicalizationmethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <ds:signaturemethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:reference URI="#_dc151d8adbd6eea9236ad0bd832da03a4903c2bfd3"> <ds:transforms> <ds:transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <ds:transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> </ds:transforms> <ds:digestmethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <ds:digestvalue>6kf9zznkephlvp/pp3p9exb46bm=</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>qzwzehtyazdssarw3pb7uormb61efe0xcqjyob3liivojslumjgws44l5bpebbvx+d/lk8sityfktaad7xalao7f2wp48bs8nz0pd18 siuiwpntw99ekrxtqfue6ujdzuhctpsu7foen2ybgqsqkmmbf4vzuzskfvtgbv/i0qqd0nz8tkfqze1c9gqrs21ojmemkvvyllkgg6lqjgjdfnc8ly4iymgeimldkc8hrr wel/voftmwpithbiclhrqijwfesecwltynzzcto8m/bf/7gfhvvmftgrdmsrddnfy+scsurce0umznq9xbzfpectnacudqgi02h+0phylwxga==</ds:signaturevalue> <ds:keyinfo> <ds:x509data> <ds:x509certificate>miidszccapugawibagijap7rfq50ps1jma0gcsqgsib3dqebcwuamhaxczajbgnvbaytalnfmriweaydvqqidaltdg9ja2 hvbg0xejaqbgnvbacmcvn0b2nrag9sbtemmaoga1uecgwdsultmqwwcgydvqqldangzwqxhtabbgnvbammfhnhbwxpzhaubxlkb21haw4ubg9jmb4xdte1mdgwndexndmz NloXDTIwMDgwMzExNDMzNlowcDELMAkGA1UEBhMCU0UxEjAQBgNVBAgMCVN0b2NraG9sbTESMBAGA1UEBwwJU3RvY2tob2xtMQwwCgYDVQQKDANJSVMxDDAKBgNVBAsMA0 ZlZDEdMBsGA1UEAwwUc2FtbGlkcC5teWRvbWFpbi5sb2MwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDT1HIQFaO7i5Zxt/Nf6kyHzy7gDXXaxLO++E7cjbM nawug/5dswu0oblpme+1m+7dybqqsig9+yjqkjks22z/2go3mb9pbnxmiaplhayjwn7obgpo1r1dwofyqznlo/ibh0rt+odzv8rvxkhltgaspnr/b5miwrnipwlxgcsyb AHNQPi/9peW5eNIq26AHF7QwxgUOHnSazNPCWkSjTye00uFHx8xHYQ7Fjq2pifzhTrDABZgtc3ws/bxOwxz2XnbLWAYhivUCSXCtNErLO68yO0X2NILtUJpJJ6JD+yRFj jbp6kffwcseiohnj7tw+jk+gayfrrlrzb9xp/yjo+jfagmbaagjudbomb0ga1uddgqwbbtdeqkkzm7pxo6wqmw74xytvpf5gdafbgnvhsmegdawgbtdeqkkzm7pxo6wqmw 74xYTvPf5GDAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQBawGnUJabQ/V9UG6/+tCZwKCge4qZKVQ67feu4NAIiQKrcnuuQb0U0g/CrwrJ2TTwHzRVJscf5K W9bWhK4Xuwm2Pq+ySTExHputJW8VaAYZ5J5G7K4M7H4zjCRJwdDSSNI3Jv4+Bs/sOi5jcLQ7wk0oCjQkiARFbB6On22WeAun618AHBTVgn0TsP2JasJyJJomrP6IqVF2Ox 6/NB0GEr1gRAv5Apzvxvgra72JN9DcPjgsceJrRpTa8BBAglj87SFPq9khCrv1mnu2PQU0KM7aw35IjvgOdAXnBVmMX+S1UvB6UkT6L2T8PbjAR4Y3k8B4lbJxPVfk807T ma07byf</ds:x509certificate> </ds:x509data> </ds:keyinfo> </ds:signature> <samlp:status> <samlp:statuscode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:status> <saml:assertion xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xs="http://www.w3.org/2001/xmlschema" ID="_e7b74db5970e2c0479c4c461d2131da110c75f84d5" Version="2.0" IssueInstant="2015-08-06T12:51:52Z" > <saml:issuer>https://idp.example.com/simplesaml/saml2/idp/metadata.php</saml:issuer> <ds:signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:signedinfo> <ds:canonicalizationmethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <ds:signaturemethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:reference URI="#_e7b74db5970e2c0479c4c461d2131da110c75f84d5"> <ds:transforms> <ds:transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <ds:transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> </ds:transforms> <ds:digestmethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> <ds:digestvalue>n0bgozprm6cnwmv49ikuce2zsxu=</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>ygbgmrrcdkgtayubcxkpntfjzzvs636iopnkmlmlqkc4edkykjc7n2n9grxvyyeqih+ussdcwoornviwhubslf9zz+xnnfawzg4u Nt4H+DSWwYgGNowW66L8ZKhUySpaYIPq0bvQ8uVyzJNs3b1xcliu+v8LTR7okmE9lXyh1RTJsE/OBwNj7bbFXUi4TsZICd7pB2mgjp+76gU3yh+585jdkzYvK4jcE/G4Xpp 22yPQ3jGfHZpSAgggj8kAbf2jCQiQsf+xbMwkKOyhiAcCnkHWCplIYrW6mJ0yi6ua0YkL5zn6jUbMpm2TVQTtKzBLtviwGrqKmHQQUWO6WFhrWg==</ds:SignatureValue> <ds:keyinfo> <ds:x509data> <ds:x509certificate>miidszccapugawibagijap7rfq50ps1jma0gcsqgsib3dqebcwuamhaxczajbgnvbaytalnfmriweaydvqqidaltdg9j a2hvbg0xejaqbgnvbacmcvn0b2nrag9sbtemmaoga1uecgwdsultmqwwcgydvqqldangzwqxhtabbgnvbammfhnhbwxpzhaubxlkb21haw4ubg9jmb4xdte1mdgwndexndmz NloXDTIwMDgwMzExNDMzNlowcDELMAkGA1UEBhMCU0UxEjAQBgNVBAgMCVN0b2NraG9sbTESMBAGA1UEBwwJU3RvY2tob2xtMQwwCgYDVQQKDANJSVMxDDAKBgNVBAsMA0Zl ZDEdMBsGA1UEAwwUc2FtbGlkcC5teWRvbWFpbi5sb2MwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDT1HIQFaO7i5Zxt/Nf6kyHzy7gDXXaxLO++E7cjbMnaWUg /5dsWU0oBLpme+1m+7DybQQsIg9+yjqkJkS22z/2go3MB9PBnxmiaplhAYjWN7oBGpo1R1dwofYQZnLo/iBH0rT+odzv8RvxkhLtGASpNR/b5MIwrnIpWLXgcSybAHNQPi/9 pew5eniq26ahf7qwxguohnsaznpcwksjtye00ufhx8xhyq7fjq2pifzhtrdabzgtc3ws/bxowxz2xnblwayhivucsxctnerlo68yo0x2niltujpjj6jd+yrfjjbp6kffwcse IOHnJ7TW+jk+gAYFrRLRZb9Xp/yjO+JFAgMBAAGjUDBOMB0GA1UdDgQWBBTDeQkkzM7pXo6WQmW74xYTvPf5GDAfBgNVHSMEGDAWgBTDeQkkzM7pXo6WQmW74xYTvPf5GDAM BgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQBawGnUJabQ/V9UG6/+tCZwKCge4qZKVQ67feu4NAIiQKrcnuuQb0U0g/CrwrJ2TTwHzRVJscf5KW9bWhK4Xuwm2Pq+ ystexhputjw8vaayz5j5g7k4m7h4zjcrjwddssni3jv4+bs/soi5jclq7wk0ocjqkiarfbb6on22weaun618ahbtvgn0tsp2jasjyjjomrp6iqvf2ox6/nb0ger1grav5apz vxvgra72jn9dcpjgscejrrpta8bbaglj87sfpq9khcrv1mnu2pqu0km7aw35ijvgodaxnbvmmx+s1uvb6ukt6l2t8pbjar4y3k8b4lbjxpvfk807tma07byf</ds:x509certificate> </ds:x509data> </ds:keyinfo> </ds:signature> <saml:subject> <saml:nameid SPNameQualifier="https://sp.example.com/simplesaml/module.php/saml/sp/metadata.php/default-sp" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" >_7e8eee69632e14392716b67c49f4998096f86ea90d</saml:NameID> <saml:subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:subjectconfirmationdata NotOnOrAfter="2015-08-06T12:56:52Z" Recipient="https://sp.example.com/simplesaml/module.php/saml/sp/saml2-acs.php/default-sp" InResponseTo="_5e26e081472a56ebdd4db1be6f23ed643facddf2f3" /> </saml:subjectconfirmation> </saml:subject> <saml:conditions NotBefore="2015-08-06T12:51:22Z" NotOnOrAfter="2015-08-06T12:56:52Z" > <saml:audiencerestriction> <saml:audience>https://sp.example.com/simplesaml/module.php/saml/sp/metadata.php/default-sp</saml:audience> </saml:audiencerestriction> </saml:conditions> <saml:authnstatement AuthnInstant="2015-08-06T12:51:52Z" SessionNotOnOrAfter="2015-08-06T20:51:52Z" SessionIndex="_cab37416a1a1ffb6190d07517331302f092dc50cd2" > <saml:authncontext> <saml:authncontextclassref>urn:oasis:names:tc:saml:2.0:ac:classes:password</saml:authncontextclassref> </saml:authncontext> </saml:authnstatement> <saml:attributestatement> <saml:attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml:attributevalue xsi:type="xs:string">student@example.com</saml:attributevalue> </saml:attribute> <saml:attribute Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" > <saml:attributevalue xsi:type="xs:string">student@mymail.loc</saml:attributevalue> </saml:attribute> </saml:attributestatement> </saml:assertion> </samlp:response> Exempel på hur ett SAML Response Message kan se ut i verkligheten

Initiering av SAML-inloggning, sammanfattning IdP-initierad inloggning Inloggningen startar hos användarorganisationen som i det tidigare exemplet SP-initierad inloggning Inloggningen startar hos e-tjänsten (det vanligaste).

Hur vet SP:n vilken IdP som kan ställa ut intyg för användaren? Anvisningstjänst Borås Gävle? Krokom www.e-service.se

IdP-discovery (exempel) Tjänsten tillhandahåller en unik URL för respektive användarorganisation (www.iis.e-service.se, www.skatteverket.e-service.se) Tjänsten känner till användarorganisationens IP-adressrymd Tjänsten listar alla aktuella IdP:er i en anvisningstjänst och användaren får aktivt välja sin IdP E-tjänster kan använda flera smarta metoder i kombination för att underlätta autentiseringen av användaren

Anvisningstjänst OrganizationDisplayName 2 Anvisningstjänst Borås 4 E-tjänst SP 3 Borås Gävle 1 Krokom Gävle Allt informationsutbyte sker genom omdirigering av användarens webbläsare Krokom

Exempel på problem med traditionell inloggning som SAML angriper Administration av behörigheter Inloggning per tjänst Lösenord per tjänst Säkerhetskrav Lösenordssupport www.e-service.se www.e-service.se Användarnamn **********

Bensträckare 5 minut

Övningsuppgift + + = 30 + + = 18 - = 2 + * =?? 21

Men Vi har nya problem i en annan dimension

Anslutning mellan parter Certifikat Metadata Out of Band Certifikat Metadata www.e-service.se Förutsätter att parterna enats om: Teknik/standard Tillämpning Information Format Tillit/säkerhet Rutiner

Användarorganisationens perspektiv Följ min standard! SP IdP SP SP

E-tjänstens perspektiv IdP SP IdP IdP Följ min standard!

Sektorns perspektiv En integration per anslutning IdP IdP SP SP IdP SP Hundratals eller tusentals organisationer

En standard för integrationen FEDERATION Gemensam standard och infrastruktur

Gemensam standard Sambis tekniska krav & ramverk SAML 2.0 Implementationsprofil egov2 2.0 beskriver vilka delar av SAML som måste implementeras Deploymentprofilen saml2int beskriver vilka delar av SAML som måste vara i bruk samt hur dessa ska användas Namnstandard för anvisningstjänst Attributsprofiler

Andra federationer

edugain edugain is an international interfederation service interconnecting research and education identity federations. It enables the secure exchange of information related to identity, authentication and authorisation between participating federations. The service is managed by a team led by TERENA. edugain is a registered trademark of DANTE.

Gemensam infrastruktur Aggregerat metadataregister signerat med federationens nyckel Central anvisningstjänst Verktyg för validering av metadata Testmiljöer

Aggregerat metadataregister Metadata Certifikat Metadata Certifikat Metadata Certifikat Aggregerad och publicerad metadata Metadata+certifikat 1 Metadata+certifikat 2 Metadata+certifikat 3 Metadata+certifikat 4 Metadata+certifikat 5 Metadata+certifikat 6 / / Aggregerat metadata Signera och publicera Metadata Certifikat Metadata Certifikat Metadata Certifikat Federationsoperatör

Aggregerad metadata Skolfederation

Anvisningstjänst - exempel

Tekniska miljöer i Sambi

Övningsuppgift Vilka är federationsoperatörens 2 viktigaste uppgifter? A. Centralt & aggregerat metadataregister samt tekniskt & regulatoriskt ramverk B. Säkerställa identitetshanteringen samt centralt & aggregerat metadataregister C. Säkerställa identitetshanteringen samt tekniskt & regulatoriskt ramverk

FIKA! Kl 14.15 14.30

Agenda, fortsättning 14.30 Fortsättning 16:00 Avslut SAML 2.0 Övningsuppgifter SAML Status pågående arbeten Komma igång

SAML 2.0 Security Assertion Markup Language

Kort om SAML Öppen standard från OASIS XML-baserat ramverk för att kommunicera information för autentisering, behörighet och attribut för användare 2002 - SAML 1.0 2003 SAML 1.1 2005 SAML 2.0

SAML 2.0 Assertions Protocols Bindings Information om användaren Authentication statements (hur användaren har autentiserats) Attribute statements (användarens attribut) Authorization decision statements (information för att avgöra användarens rättigheter) Paketering och hantering av SAML-element Assertion Query and Request Protocol Authentication Request Protocol Artifact Resolution Protocol Mappar SAML-protokoll till andra protokoll SAML SOAP Binding (based on SOAP 1.1) Reverse SOAP (PAOS) Binding HTTP Redirect (GET) Binding HTTP POST Binding HTTP Artifact Binding SAML URI Binding Profiles Beskriver hur ovanstående kombineras SSO Profiles Artifact Resolution Profile för en specifik tillämpning Assertion Query/Request Profile Name Identifier Mapping Profile SAML Attribute Profiles

Övningsuppgift - korv 2 Homer äter korven 1 Den grillade korven förbereds för att ätas 3 Homer grillar en korv

Övningsuppgift - SAML Nisse har just kommit till jobbet och har ännu inte loggat in i någonstans. Innan han gör något annat vill han klara av ett ärende i tjänsten service.se. Tjänsten finns inte i portalen på Nisses företag. I vilken ordning händer nedanstående? idp.krokom.se Användarnamn Lösenord Logga in Välkommen! Logga in med: E-post lösenord www.service.se Välkommen Nisse! www.service.se Välj din intygsutfärdare Borås Gävle Krokom IdP:n har ställt ut ett intyg och dirigerar Nisse tillbaka till SP:n som skickade begäran. service.se har identifierat vilken IdP Nisse använder och dirigerar honom vidare med en AuthnRequest (begäran om intyg). Nisse vill till tjänsten service.se. Tjänsten finns inte i portalen på Nisses företag. Nisse vill logga in via en federation. Eftersom han gick direkt till tjänstens webbsida så känner den inte till vilken IdP Nisse använder, utan diririgerar honom till en anvisningstjänst. service.se har många olika typer av användare och erbjuder därför flera olika alternativ för inloggning.

Övningsuppgift - SAML SAML-implementationen i exemplet är inte ett föredöme avseende användarvänlighet. Användaren ställs inför flera val i olika sammanhang under inloggningsflödet. Överkurs: Hur skulle en mer användarvänlig implementation kunna se ut? 4 2 5 1 3 idp.krokom.se Användarnamn Lösenord Logga in Välkommen! Logga in med: E-post lösenord www.service.se Välkommen Nisse! www.service.se Välj din intygsutfärdare Borås Gävle Krokom IdP:n har ställt ut ett intyg och dirigerar Nisse tillbaka till SP:n som skickade begäran. service.se har identifierat vilken IdP Nisse använder och dirigerar honom vidare med en AuthnRequest (begäran om intyg). Nisse vill till tjänsten service.se. Tjänsten finns inte i portalen på Nisses företag. Nisse vill logga in via en federation. Eftersom han gick direkt till tjänstens webbsida så känner den inte till vilken IdP Nisse använder, utan diririgerar honom till en anvisningstjänst. service.se har många olika typer av användare och erbjuder därför flera olika alternativ för inloggning.

Kom ihåg det här Inloggning här! Intyg med användarinformation via omdirigering av webbläsare Intyg www.e-service.se Välkommen! Användarnamn Intyg 2 ********** 3 1 www.e-service.se DB

Flöde och inblandade system, repetition Användare vill logga in Vårdsystem Vårdsystemet begär autentisering av användaren IdP IdP n begär användarens inloggning Användaren loggar in IdP Kontrollerar certifikat T.ex. SITHS IdP n skickar tillbaka användarens inloggningsbiljett till vårdsystemet Hämtar behörighetsstyrande uppgifter HSA AD etc Vårdsystem

Vad är SSO? Single sign-on (SSO) en användare behöver endast logga in en gång för att nå de system som är anpassade till tjänsten. Även Single sign-off brukar inkluderas i begreppet SSO kan som begrepp dels vara den tekniska delen, dels hur en inloggning kan upplevas av en användare För att kunna sköta det dagliga arbetet handlar det ofta om att jaga information i 20 30 olika system och applikationer, förutom patientjournalsystemet. Man loggar in i och ut ur system hela tiden att informationsflödet inte hänger ihop. Spretigheten i IT-stödet har blivit en betydande arbetsmiljöfråga i vården!

Hur fungerar SSO, tekniskt? Applikation A Användaren vill logga in IdP= Identity Provider (intygsutfärdare) SP= Service Provider (e-tjänst)

Hur fungerar SSO? Applikation A SP:n ber användaren logga in

Hur fungerar SSO? Applikation A Användaren skickas till IdP:n och får där autentisera sig m.h.a exempelvis ett SITHS-kort och sin PIN-kod.

Hur fungerar SSO? Applikation A IdP:n verkställer autentiseringen och skapar och skickar en SAML-biljett till webläsaren Användaren är nu inloggad i IdP:n

Hur fungerar SSO? Applikation A Webbläsaren skickar SAML-biljetten vidare till SP:n som använder SAML-biljetten för att logga in användaren i SP:n. Utifrån de behörighetsstyrande attributen i SAML-biljetten får användaren tillgång till de funktioner som användaren får nyttja i SP:n. (SP:n har egentligen inget beroende till autentiseringsmetoden, litar på intyget.)

Hur fungerar SSO? Applikation A All kommunikation sker nu bara mellan webbläsaren och SP:n. Användaren har dock en tidsbegränsad inloggningssession i IdP:n. IdP:n har hjälpt till med att upprätta en session mellan webbläsaren och SP:n och har nu inte längre något ansvar. SP:n håller sin session tills användaren loggar ut från SP:n

Hur fungerar SSO? Applikation A Applikation B Användaren vill nu även logga in i en annan tjänst

Hur fungerar SSO? Applikation A Applikation B Användaren anropar den andra SP:n

Hur fungerar SSO? Applikation A Applikation B SP:n ber användaren logga in och skickar en inloggningsbegäran via webbläsaren till IdP:n

Hur fungerar SSO? Applikation A Applikation B Webbläsaren gör en inloggningsbegäran. IdP:n upptäcker att användaren redan är inloggad och skapar en ny SAML-biljett till begärd SP - om inte sessionstiden har gått ut.

Hur fungerar SSO? Applikation A Applikation B IdP:n skickar SAML-biljetten via webbläsaren till SP:n SP:n använder SAML-biljetten för att logga in användaren i SP:n. Utifrån de behörighetsstyrande attributen i SAML-biljetten får användaren till gång till de funktioner som användaren får nyttja i SP:n.

Hur fungerar SSO? Applikation A Applikation B Användaren kan nu arbeta i bägge applikationerna, baserat på EN inloggning i IdP:n, det vill säga SSO.

Hur fungerar SSO? Applikation A Applikation B TLSsession TLSsession Sessionen ligger nu mellan webbläsaren och e-tjänsten, SP:n. När webbläsaren stängs så försvinner sessionen eller om man loggar ut ur e-tjänsten Urloggning sker således i e-tjänsten!

Gemensamt ansvar Användarens ansvar Är att följa lagar och föreskrifter som är applicerbara inom e-tjänstens användningsområde Tillse att ingen obehörig har åtkomst till inloggad e-tjänst. Vilket t ex innebär skyldighet att logga ut & stänga e-tjänsten då e-arbetsplatsen lämnas obevakad e-arbetsplatsens (PC:n) ansvar Är att tillse att kommunikationen med e-tjänsten samt med IdP:n sker med förväntad säkerhet. För att detta ska kunna uppfyllas krävs att den är rätt konfigurerad och har erforderlig programvara installerad och uppdaterad

Gemensamt ansvar, forts. IdP:n ansvar Är att identifiera och autentisera en användare och utställa ett identitetsintyg (SAML-biljett) till de applikationer som aktören avser att nyttja e-tjänstens ansvar Är att validera riktigheten i identitetsintyget (SAML-biljetten) och utifrån dess behörighetsstyrande attribut tilldela/neka tillgång till funktioner inom e- Tjänsten

Hur fungerar SLO (Single Logout)? SLO

Mer information på: www.sambi.se/teknik

Övningsuppgift Vilka 3 viktiga saker säkerställer SAML-biljettens riktighet? Signerad ID på inloggningsbegäran (AuthnRequest Id/InResponseTo) Utställd till (Recipient)

Status och pågående arbeten

Referensarkitektur, IAM -framgångsfaktor för inträde i Sambi Samverkansprojekt drivet av Inera med representanter från regioner och landsting Förstudie nuläget, problem, drivkrafter (2015/16) Referensarkitektur för Identitet & åtkomst (ht -2016) Kravunderlag (ht -2016) för upphandling och utveckling av IT-stöd Resultatet förvaltas av Inera Arkitektur & Regelverk www.inera.se/riv-ta

Vad var då problemet? Egna varianter av inloggning & behörighet i varje system Direktintegration med tekniken Ett sätt att logga in ( kortet ) passar inte all verksamhet Svårt att realisera Single Sign-On Dålig förvaltningsbarhet Höga kostnader

En smartare och mer skalbar arkitektur Investering i säkerhetsteknik kan läggas i gemensam ITinfrastruktur Standardiserad integration (SAML2, OpenID Connect, OAuth2) Möjliggör införande av ny teknik för inloggning, mobila bärare, biometri Underlättar att kvalitetssäkra identitetsdata

Hur kan vi använda referensarkitekturen? Underlag vid anskaffning, vidareutveckling och utformning av e-tjänster gemensam och lokal ITinfrastruktur www.inera.se/riv-ta

Möjligheter! Singelinloggning snabb, enkel och säker tillgång till information Kvalitetssäkring av e-identiteter Nya inloggningsmetoder Mobila arbetssätt Standardisering minska inlåsning och kostnader Säker samverkan över organisationsgränser

E-identitet för offentlig sektor (EFOS) Ny tjänst för utfärdande av e- identiteter i samverkan Inera och Försäkringskassan Målgrupp: alla inom offentlig sektor Ersätter både SITHS och Myndighets-CA Moderniserade autentiseringslösningar - både e-id på kort och mobilt e-id Utformning utfärdandeprocess, tester, anslutning nationella e-tjänster under 2017 Lanseras i början av 2018 Autentisering s-tjänst Inloggning Utfärdande e-id E-identitetsutfärdare Säkerhetsapp

Status, medlemmar, Sambi Användarorganisationer Stockholms stad Stockholms Läns Landsting Danderyds kommun ehälsomyndigheten E-tjänster SLL Beställningsportalen

Status, forts. Inera Anpassningsarbete av Ineras Säkerhetstjänster pågår för inträde i Sambi Pascal följer därefter

Betrodda parter (tillitsgranskade) utöver medlemmarna Betrodd part Omfattning Typ Tieto Sweden AB Inera AB Svensk e-identitet Lidingö stad Brokertjänst IdP i Inera Nationella Säkerhetstjänster IdP Underleverantör till Tjänsteleverantör Underleverantör till Användarorganisation Underleverantör till Användarorganisation Användarorganisation

Granskningar Godkänd part Godkänd som Återkommande tillitsgranskning senast/notering Tieto Sweden AB, Brokertjänst Leverantör till tjänsteleverantör 2018-06-09 Stockholms läns landsting, Beställningsportalen (HSF, Avdelningen för Närsjukvård, Rehabilitering, habilitering och hjälpmedel.) Tjänsteleverantör 2018-09-21 Stockholms stad Användarorganisation 2018-10-07 Inera AB, katalogtjänst HSA Leverantör till Användarorganisation 2018-10-16

Granskningar Godkänd part Godkänd som Återkommande tillitsgranskning senast/notering ehälsomyndigheten, stödtjänster med tillhörande infrastrukturtjänster Tjänsteleverantör 2018-10-30 Receptexpeditionsstöd tjänsterna omfattar bland annat åtkomst till receptregistret, läkemedelsförteckningen, högkostnadstrappan, fullmakter och grunddata. E-receptstöd för att en vårdaktör ska kunna skicka elektroniska recept från ett journalsystem. Stöd för att visa privata läkemedel och recept för privatpersoner. Stöd för att visa privatpersoners läkemedel och recept för vård- och apotekspersonal.

Granskningar Godkänd part Godkänd som Återkommande tillitsgranskning senast/notering Inera AB, IdP i Inera Nationella Säkerhetstjänster Leverantör till Användarorganisation 2019-10-05 Svensk e-identitets IdP Leverantör till Användarorganisation 2020-04-19 SLL Stockholms läns sjukvårdsområde, IdP Användarorganisation Godkänd med krav på komplettering Danderyds kommun, för användning av Användarorganisation Godkänd med SITHS som Elektronisk identitetsutfärdare förbehåll HSA som attributsutgivare Inera säkerhetstjänst som Identitetsintygsutgivare Lidingö stad, för användning av SITHS som Elektronisk identitetsutfärdare HSA som attributsutgivare Inera säkerhetstjänst som Identitetsintygsutgivare Användarorganisation Godkänd med förbehåll

Inera Inera har nu publicerat metadata för Nationella säkerhetstjänster och Pascal i Sambis Trial-miljö.

Kommuner Danderyds kommun Medlemsantal med Sambi har tecknats och de önskar komma i gång med SLL:s beställningsportal via Sambi. Huddinge kommun Godkänd som utfärdare av Svensk e-legitimation (Den första!!!) De är nu intresserade att komma i gång med att testa lämplig tjänst i Sambi. Stockholms stad Godkänd

Deltagare testbädd Inera MobilityGuard Nexus Svensk e-identitet Tieto ehälsomyndigheten SLL Stockholms stad

Uppdatering av dokumentation och webbplats Kvalitetsprojekt för Sambis Tillitsgranskningstjänst har avslutats och följande dokumentation har gåtts igenom och publicerats: Se: https://www.sambi.se/tillit/tillitsramverk/ Anslutningsavtal Sambi Sambis Bilaga 1 - Definitioner för Sambi Sambis Bilaga 3- Tillitsramverk Sambis Bilaga 4 - Föreskrifter för Sambis Federationsoperatör Sambis Bilaga 5 - Avgifter Tjänstebeskrivning för Sambis Federationstjänst Tjänstebeskrivning för Sambis Tillitsgranskningstjänst Tillitsgranskningsavtal Tillitsgranskningsavtal Bilaga 1 Tillitsgranskningens omfattning Tillitsdeklarationsmall Granskningsinstruktion och Checklista för tillitsdeklaration Instruktioner för Sambis Granskare Sekretessförbindelse med Granskare samt ett stort antal interna rutindokument!

Komma igång

Komma igång förberedande Gör en analys hemma Vad ska vi börja med? Vilka vinster gör vi? Vilka förutsättningar har vi? Identifiera kompetensbehov SAML, Identitetshantering, ADFS, WS-Trust?, Informationssäkerhet Ta hjälp!

Komma igång förberedande, forts. Ta vara på andras erfarenheter SLL, Inera Ta del av Ineras SSO-förstudie samt Referensarkitekturen för IAM Sätt upp mål och resurssätt Sätt realistiska mål. Saker tar tid

Bli medlem Intresseanmälan Använda Trial-miljö Tillitsdeklaration Avtal Produktion

Vad kostar medlemskap i Sambi?

Medlemsavtal Anslutningsavtal Bilaga 1 Definitioner Bilaga 2 - Tekniska krav Bilaga 3 Tillitsramverk Bilaga 4 - Föreskrifter för federationsoperatören Bilaga 5 - Avgifter Kontaktuppgifter (blankett) https://www.sambi.se/medlemskap/anslutningsavtal/

Kontaktblankett

Kontaktuppgifter Huvudkontakt övergripande, publiceras på Sambis webbplats Teknisk kontakt den person som blir motringd vid uppladdning av nytt metadata! Incidentansvarig kan vara en funktionsbrevlåda/-telefon, ska alltid bevakas Fakturakontakt

Metadatahantering Validering Sänd via formulär https://www.sambi.se/teknik/metadata/lamna-nytt-metadata/ Checksumma Kundtjänst motringer teknisk kontakt Publicering

Infrastruktur - miljöer Test-Idp Test-SP

Information www.sambi.se Nyhetsbrev allmänna tekniska Kurser Arbetsgruppens möten

Vilka är de stora utmaningarna? Arvet, behov av att federationsanpassa tjänster och system Enas om gemensamma attribut för sektorn ett ledningssystem för informationssäkerhet (LIS) som baseras på ISO/IEC 27001 eller motsvarande Börja i tid! Se till att kravställa nya tjänster så att de är federationsanpassade och följer Referensarkitekturen

Sammanfattning, mål för Sambi Underlätta realisering av SSO Underlätta för informationsägare att fullgöra de skyldigheter som bland annat följer av personuppgiftsansvaret Vara ett självklart alternativ till att utforma separata lösningar för hanteringen av identiteter och behörigheter, separat för varje enskilt system, i varje enskild organisation Tillhandahålla en gemensam och tydlig infrastruktur, baserad på standard, som erbjuder marknaden en tydlig bas för tillhandahållande av effektiva e-tjänster Fungera som ett forum som verkar för medlemmarnas gemensamma intressen, verkar för samverkan, kunskapsutveckling, erfarenhetsutbyte och där spridning av goda exempel möjliggörs

Sammanfattning, Sambi är en federation En identitetsfederation är en sammanslutning av organisationer som har kommit överens om att lita på varandras elektroniska identiteter och behörighetsstyrande attribut för att underlätta användarnas åtkomst till elektroniska tjänster och skydda den personliga integriteten. Genom Sambi och dess ramverk uppnås ovanstående. Sambifederationen blir vad federationens medlemmar vill att Sambi ska bli!

Sammanfattning, tekniska standarder