Hantering av tillitsnivåer



Relevanta dokument
BILAGA 2 Tekniska krav Version 1.3

BILAGA 2 Tekniska krav

BILAGA 2 Tekniska krav Version 1.3

BILAGA 2 Tekniska krav Version 1.52

BILAGA 2 Tekniska krav Version 0.81

Tekniskt ramverk för Svensk e-legitimation

Tekniskt ramverk för Svensk e- legitimation

RIV TA Domänschema 2.1

Utveckling av Skolfederations tillitshantering

RIV TA Domänschema 2.1

RIV Tekniska Anvisningar 2.1

SAMBI SAML Profil. Samverkan för Behörighet och Identitet inom hälsa, vård och omsorg

BILAGA 1 Definitioner

Internetstiftelsen i Sverige.

Testning av Sambi. Testplan. Version PA12. Fil namn: SAMBI_TP.docx Senast sparad: Copyright (c) 2014 IIS

BILAGA 1 Tekniska krav Version 1.0

Introduktion till SWAMID

InTime Message Center SMS gränssnittsspecifikation V2.3

Apotekens Service. federationsmodell

BILAGA 1 Tekniska krav

BILAGA 1 Definitioner Version: 2.01

INTEGRATIONER, INLOGGNING, SÄKERHETSASPEKTER RUNT LADOK

Tillitsramverket. Detta är Inera-federationens tillitsramverk.

BILAGA 1 Definitioner Version: 2.02

BILAGA 1 Definitioner

Underlag till möte om Sambis testbädd och pilotverksamhet

Tentamen Informationsinfrastruktur

Anteckningar från möte om Sambis testbädd och pilotverksamhet

Guide till Inera IdP. Information angående anslutning av Nationella e-tjänster

torsdag 17 oktober 13 IT's a promise

05:01 Riktlinjer för utveckling av standardmeddelanden för förenklat informationsutbyte med elektroniska standarddokument

LEX INSTRUKTION LEX.CONFIG

Regelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga A. Tekniska ramverk. Version: 1.0

BILAGA 3 Federationsgemensamma attribut

Regelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga A. Tekniska ramverk. Version: 3.0

E-legitimationsdagen dag 2. Så här kopplar ni upp era e-tjänster mot den svenska eidas-noden

Varför Sambi, för vad och vem, samexistens med andra lösningar, svensk e-leg, SITHS, HSA, Skolfederation et cetera (Ulf Palmgren, SKL, CeSam)

Mötesantecknignar - Sambidemo

Införande av Skolfederation. Erfarenheter i Sundsvalls kommun

E-legitimationsdagen

Tillit och användbarhet med Skolfederation

SWAMID. Nyttjandestatistik av SWAMID. Vad är SWAMID? Så, hur mycket används SWAMID idag? Vi vet inte.. en första demonstration!

Pass 4. Vad är en metadatastandard? SND Svensk nationell datatjänst

Svensk e-legitimation

Identitetsfederering etapp II Höga och låga observationer

Elevlegitimation ett konkret initiativ.

Authentication Context QC Statement. Stefan Santesson, 3xA Security AB

Anteckningar från Sambis arbetsgruppsmöte

Skolfederation.se. KommITS

RIV TA Tjänsteschema 2.1 RIV Tekniska Anvisningar

E-legitimationsdagen dag 2. En översikt av eidas-arkitekturen och E-legitimationsnämndens erbjudande

Federering i praktiken

RIV Tekniska Anvisningar Tjänsteschema

PhenixID & Inera referensarkitektur. Product Manager

Dokument: Attest-signatur. Författare. Sida 1 av 16 Ola Ljungkrona PO Datum

RIV Tekniska Anvisningar Tjänsteschema

MMS gränssnittsspecifikation (v1.0)

Krav på identifiering för åtkomst till konfidentiell information

Anteckningar från referensgruppens möte

Modell fo r ä ndringshäntering äv Sämbis gemensämmä tekniskä infrästruktur Version 1.0

ÖTP Sambruks höstmöte

Federerad åtkomst Information om åtkomst till Apotekens Services tjänster inom ramen för en identitetsfederation.

Dokumentschema förpackning av externa objekt. Version: 1.0 Status: Standard Datum:

Attributprofil för skolfederationen

E-legitimationsnämndens legitimeringstjänster för test

Hur många standarder har du använt idag?

SAMBI Test specification. Jan Säll

Testning av Sambi. Testplan. Version PA5. Fil namn: SAMBI_TP.docx Senast sparad: Copyright (c) 2014 IIS

Identitetsfederationer

Swami. Valter Nordh, Göteborgs Universitet 50% SWAMID/Swami 50% edugain X% GU

Workshop med focus på AL-processer

!! Sambi!! Attributspecifikation! Version 1.0

Tjänstespecifikation

Regionalt samarbete. Tillit Federativ lösning för identitets och behörighetshantering

Uppgiftskravstjänsten Beskrivning av XML-schema för uppgiftskrav som öppna data. Version 2.0

Säkerhet och Tillit i en identitetsfederation

Sign Message i Legi+meringstjänster Designförslag Stefan Santesson sec.com)

Vad innebär Skolfederation.se för en kommun?

Meddelandespecifikation Avbrottsrapportering

ERFARENHETSUTBYTE KRING FEDERATIVA IDENTITETSLÖSNINGAR

Meddelandespecifikation Avbrottsrapportering

Tillämpningsanvisningar

Frågor i avslutande workshop Huvudtema. Identifikationsfederationer för vad och vilka? Rolf Lysell, rolf.lysell@innotiimi.se

Välkomna till introduktionskurs i Sambi

Sambi och Sambis roll Håkan Josefsson Service Manager, Apotekens Service AB

Anteckningar referensgruppens möte

Kravunderlag inom området Identitet och Åtkomst

Tekniska möjligheter att förenhetliga inloggning med öppna standarder och gränssnitt UBISECURE SOLUTIONS, INC.

Anvisningar e-tjänster. Anvisningar och rekommendationer för e-tjänster i samverkan SAML & SSO

Introduktion till Skolfederation

Underlag till referensgruppens möte

Byta bort SITHS-cert i frontend

XML. XML is a method for putting structured data in a text file

Anvisningar för användare vid användning av e- Tjänster. Anvisningar och rekommendationer för användare av e-tjänster i samverkan SAML & SSO

Postbeskrivning. Sjukanmälan

Attributprofil för Skolfederation

Transkript:

Hantering av tillitsnivåer Version 1.2 Innehåll Hantering av tillitsnivåer för Skolfederation... 1 1 Inledning... 2 2 Tillitsnivåer... 2 3 Profiler och referenser... 2 3.1 Förtydligande gällande deploymentprofil... 2 4 Signalering av tillitsnivå... 3 4.1 Service Provider... 3 4.2 Identity Provider... 3 5 Anvisningstjänst... 4 6 Context Classes [.xsd]... 5 6.1 LoA Bas... 5 6.2 LoA 2fa... 6 6.3 LoA 2 (tillämpas inte för närvarande)... 7 6.4 LoA 3 (tillämpas inte för närvarande)... 8

1 Inledning Detta dokument beskriver hur tillitsnivåer ska signaleras mellan intygsutfärdare (IdP) och tjänsteleverantör (SP) inom Skolfederation. 2 Tillitsnivåer Följande tillitsnivåer tillämpas inom federationen: 1. [http://id.skolfederation.se/loa/bas] 2. [http://id.skolfederation.se/loa/2fa] Numreringen anger nivåernas inbördes relation där högre numrering innebär högre tillit. Följande nivåer finns registrerade men tillämpas för nuvarande inte: [http://id.skolfederation.se/loa/loa2] [http://id.skolfederation.se/loa/loa3] Ovanstående nivåer är ännu inte specificerade och bör inte användas för att signalera tillitsnivå inom federationen. 3 Profiler och referenser Hanteringen av tillitsnivåer som beskrivs i detta dokument refererar inte till några andra standarder eller profiler än de som tillämpas generellt inom Skolfederation. 3.1 Förtydligande gällande deploymentprofil Den, inom Skolfederation, tillämpade deploymentprofilen http://saml2int.org/profile/current. rekommenderar att en <saml2p:authnrequest> endast bör innehålla elementet <saml2p:requestedauthncontext> i de fall där en uppgörelse träffats mellan IdP och SP. The <saml2p:authnrequest> message MAY contain a <saml2p:requestedauthncontext> element, but SHOULD do so only in the presence of an arrangement between the Identity and Service Providers regarding the Authentication Context definitions in use. I detta dokument beskrivs hur signaleringen ska utföras på ett enhetligt sätt inom federationen, men ansvaret att besluta om vilken tillitsnivå som ska tillämpas för åtkomst av en specifik kvarstår hos intygsutgivaren och tjänsteleverantören.

4 Signalering av tillitsnivå Tillitsnivå signaleras genom att addera aktuell <saml:authncontextclassref> till elementet <saml2p:requestedauthncontext> i <saml2p:authnrequest> och <saml2p:authnresponse>. I det fall ingen tillitsnivå begärs ska alla signalerade tillitsnivåer godkännas såväl som utebliven signalering av tillitsnivå. Det innebär i praktiken att inget annat än federationens lägsta tillitsnivå kan säkerställas, vilket är ekvivalent med [http://id.skolfederation.se/loa/bas]. Context Class för respektive URI finns beskrivet på http://www.iana.org/assignments/loaprofiles/loa-profiles.xhtml 4.1 Service Provider SP:n anger vilken tillitsnivå som krävs för att nå en specifik resurs genom att signalera detta i <saml2p:authnrequest>. Attributet [Comparison] bör sättas till exact då vissa SAML-mjukvaror endast har stöd för exakt matchning av <saml:authncontextclassref>. För att undvika problem för en användare som redan är autentiserad med en högre tillitsnivå än tjänsten kräver, bör autentiseringsfrågan innehålla samtliga tillitsnivåer som uppfyller tjänstens krav. En <saml2p:authnrequest> kommer därför att innehålla fler än en <saml:authncontextclassref> i de fall en annan tillitsnivå än den starkaste efterfrågas. Tillitsnivåerna i autentiseringsfrågan ska listas i fallande ordning, med den föredragna tillitsnivån överst i listan (Exempelvis; om tjänsten kräver tillitsnivå [Bas], placeras den högst i listan. Eftersom även tillitsnivå [2FA] är godkänd så signaleras även den, men placeras efter [Bas] i listan). Om [Comparison] helt utelämnas, kommer det att tolkas av IdP på samma sätt som exact i enlighet med SAML-Core-2.0. Om ingen annan tillitsnivå än [http://id.skolfederation.se/loa/bas] krävs för den aktuella tjänsten så kan signalering av tillitsnivå utelämnas helt som ett alternativ till att signalera den faktiska nivån. Detta innebär att tjänsten inte behöver ha kännedom om federationens tillitsnivåer över huvud taget och användaren kommer att autentiseras oavsett vilken tillitsnivå IdP:n stödjer. 4.2 Identity Provider IdP:n besvarar en begärd tillitsnivå i <saml2p:authnrequest> genom att, i <saml2p:authnresponse>, signalera den tillitsnivå som användaren autentiserats för. En autentiseringsfråga kan innehålla fler än en <saml:authncontextclassref> i en ordnad lista. Listan ska tolkas i fallande ordning med föredragen tillitsnivå överst. Om IdP:n inte kan matcha någon av de efterfrågade tillitsnivåer, ska <StatusCode> [urn:oasis:names:tc:saml:2.0:status:noauthncontext] anges i svaret.

5 Anvisningstjänst Det finns några tänkbara scenarion där en användare som, i normalfallet, enbart ansluter till tjänster genom IdP-initerade inloggningar, kommer att bli omdirigerad till anvisningstjänsten. Det kan exempelvis ske om användaren är autentiserad med en viss tillitsnivå och sedan begär en resurs som kräver en högre tillitsnivå. En användare som vanligtvis inte nyttjar anvisningstjänsten kan uppleva det en aning förvirrande att plötsligt behöva interagera med den, vilket bör beaktas vid utformning av den specifika implementation. Skolfederation har för närvarande inga specifika rekommendationer avseende hur detta bör hanteras. Två lösningar som kan reducera/förenkla användandet är under utvärdering och kan komma att tillämpas inom federationen framöver. Dessa beskrivs kortfattat nedan. Filtrering av presenterade IdP:er i anvisningstjänsten baserat på tillitsnivå: Syftet med denna funktion är att användaren inte ska kunna välja en IdP som inte uppfyller den efterfrågade tillitsnivån. Detta förutsätter att anvisningstjänsten känner till vilka IdP:er som uppfyller vilka tillitsnivåer, samt vilken tillitsnivå som efterfrågas i varje given autentiseringsfråga som dirigeras via anvisningstjänsten. Behovet av funktionen antas vara lågt i nuläget, men den kan komma att implementeras i framtiden. Common Domain Cookie: En gemensam domän beslutas för federationen (ex. skolfederation.se) och respektive IdP/SP ges möjlighet att dirigera autentiseringsfrågor/svar via domänen. Information om de IdP:er användaren nyttjas lagras i form av en lista där senast använda IdP placeras högst upp i listan. IdP/SP har möjlighet att skriva/läsa [Common Domain Cookie] och en SP kan därmed dirigera en autentiseringsfråga direkt till den IdP användaren nyttjat senast. Funktionen utreds för närvarande inom federationen Sambi och kan komma att införas i Skolfederation framöver. Utöver de centrala lösningar som beskriv ovan, kan tjänsteleverantörer som väljer att tillämpa embedded discovery hantera logiken i den egna tjänsten.

6 Context Classes [.xsd] Nedanstående scheman finns även här: http://www.iana.org/assignments/loa-profiles/loaprofiles.xhtml 6.1 LoA Bas <?xml version="1.0" encoding="utf-8"?> <xs:schema targetnamespace="http://id.skolfederation.se/loa/bas" xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns="http://id.skolfederation.se/loa/bas" finaldefault="extension" blockdefault="substitution" version="2.0"> <xs:redefine schemalocation="http://docs.oasis-open.org/security/saml/v2.0/samlschema-authn-context-types-2.0.xsd"> <xs:annotation> <xs:documentation> Class identifier: http://id.skolfederation.se/loa/bas Defines the basic level of the Assurance Framework </xs:documentation> </xs:annotation> <xs:complextype name="authncontextdeclarationbasetype"> <xs:restriction base="authncontextdeclarationbasetype"> <xs:sequence> <xs:element ref="governingagreements"/> </xs:sequence> <xs:attribute name="id" type="xs:id" use="optional"/> <xs:complextype name="governingagreementreftype"> <xs:restriction base="governingagreementreftype"> <xs:attribute name="governingagreementref" type="xs:anyuri" fixed="http://id.skolfederation.se/loa/bas" use="required"/> </xs:redefine> </xs:schema>

6.2 LoA 2fa <?xml version="1.0" encoding="utf-8"?> <xs:schema targetnamespace="http://id.skolfederation.se/loa/2fa" xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns="http://id.skolfederation.se/loa/2fa" finaldefault="extension" blockdefault="substitution" version="2.0"> <xs:redefine schemalocation="http://docs.oasis-open.org/security/saml/v2.0/samlschema-authn-context-types-2.0.xsd"> <xs:annotation> <xs:documentation> Class identifier: http://id.skolfederation.se/loa/2fa Defines the strong authentication level of the Assurance Framework </xs:documentation> </xs:annotation> <xs:complextype name="authncontextdeclarationbasetype"> <xs:restriction base="authncontextdeclarationbasetype"> <xs:sequence> <xs:element ref="governingagreements"/> </xs:sequence> <xs:attribute name="id" type="xs:id" use="optional"/> <xs:complextype name="governingagreementreftype"> <xs:restriction base="governingagreementreftype"> <xs:attribute name="governingagreementref" type="xs:anyuri" fixed="http://id.skolfederation.se/loa/2fa" use="required"/> </xs:redefine> </xs:schema>

6.3 LoA 2 (tillämpas inte för närvarande) <?xml version="1.0" encoding="utf-8"?> <xs:schema targetnamespace="http://id.skolfederation.se/loa/loa2" xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns="http://id.skolfederation.se/loa/loa2" finaldefault="extension" blockdefault="substitution" version="2.0"> <xs:redefine schemalocation="http://docs.oasisopen.org/security/saml/v2.0/saml-schema-authn-context-types-2.0.xsd"> <xs:annotation> <xs:documentation> Class identifier: http://id.skolfederation.se/loa/loa2 Defines Level 2 of the Assurance Framework </xs:documentation> </xs:annotation> <xs:complextype name="authncontextdeclarationbasetype"> <xs:restriction base="authncontextdeclarationbasetype"> <xs:sequence> <xs:element ref="governingagreements"/> </xs:sequence> <xs:attribute name="id" type="xs:id" use="optional"/> <xs:complextype name="governingagreementreftype"> <xs:restriction base="governingagreementreftype"> <xs:attribute name="governingagreementref" type="xs:anyuri" fixed="http://id.skolfederation.se/loa/loa2" use="required"/> </xs:redefine> </xs:schema>

6.4 LoA 3 (tillämpas inte för närvarande) <?xml version="1.0" encoding="utf-8"?> <xs:schema targetnamespace="http://id.skolfederation.se/loa/loa3" xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns="http://id.skolfederation.se/loa/loa3" finaldefault="extension" blockdefault="substitution" version="2.0"> <xs:redefine schemalocation="http://docs.oasisopen.org/security/saml/v2.0/saml-schema-authn-context-types-2.0.xsd"> <xs:annotation> <xs:documentation> Class identifier: http://id.skolfederation.se/loa/loa3 Defines Level 3 of the Assurance Framework </xs:documentation> </xs:annotation> <xs:complextype name="authncontextdeclarationbasetype"> <xs:restriction base="authncontextdeclarationbasetype"> <xs:sequence> <xs:element ref="governingagreements"/> </xs:sequence> <xs:attribute name="id" type="xs:id" use="optional"/> <xs:complextype name="governingagreementreftype"> <xs:restriction base="governingagreementreftype"> <xs:attribute name="governingagreementref" type="xs:anyuri" fixed="http://id.skolfederation.se/loa/loa3" use="required"/> </xs:redefine> </xs:schema>