sou · GYB3104 · 2010-12-23 00:00:00 — Specifikation av innehåll och format på identitets- och attributsintyg Varje deltagande identitetsintygstjänst eller e-tjänsteleverantör i identitetsfederationen måste uppfylla de identitetsprofiler som presenteras i denna specifikation. Det står identitetsintygstjänst fritt att kommunicera ytterligare information i intygen förutsatt att intygen följer det i detta dokument fastlagda formatet. Inom infrastruktur för Svensk e-legitimation hanteras tre olika identitetsprofiler eller användningsscenarier; personlig, anonymiserad samt organisationsanknuten identitet. Nedan följer exempel på användar- fall som motsvaras av de tre identitetstyperna. Närmare specifikation av attributen ges i avsnitt 1.4. Personlig identitet används när en medborgare behöver identifiera sig mot en e-tjänst med personnummer. Detta kan liknas vid inloggning med certifikatsbaserad e-legitimation innehållande personnummer. Obligatoriska attribut: pseudonym, personnummer, namn Valfria attribut: tillitsnivå, adress, telefonnummer, e-post För vissa tillämpningar är det intressant att basera användarens identitet på organisationstillhörighet. Information om identitet hos den aktuella organisationen kan även kompletteras med personlig identitet (personnummer). Obligatoriska attribut: pseudonym, organisationstillhörighet(er) och namn Valfria attribut: personnummer, adress, telefonnummer, e-post Flera samtidiga organisationstillhörigheter representeras i intyget som en sekvens av attribut av samma typ. En pseudonymiserad identitet används för att skydda den personliga integriteten. En sådan identitet kan användas närhelst en e-tjänst inte kräver koppling av användaren till en specifik fysisk individ. Många enklare webbtjänster som används utanför offentlig sektor lämpar sig för denna typ av inloggning. Obligatoriska attribut: pseudonym Valfria attribut: adress, telefonnummer, e-post Format och hantering av identitetsintyg beskrivs i [SAML2Core]. Inom identitetsfederationen måste alla identitetsintyg av säkerhets- och anonymitetskäl skickas i krypterad form. Det är valfritt för e- tjänsteleverantörerna att signera identitetsförfrågningar men obligatoriskt att signera attributförfrågningar. Kryptering och signering sker med respektive parts publika nyckel vilken publicerats i metadata. Regler för utgivande av identitetsintyg ges nedan. 1.Om identitetsintygstjänsten önskar returnera ett fel ska svaret inte innehålla någon . 2.Om autentiseringen är lyckad ska identitetsintyget innehålla åtminstone: Utfärdaren av identitetsintyget som elementet . En innehållande exakt en som innehåller ett med en persistent pseudonym. Intyget innehåller även ett flertal attribut i enlighet med avsnitt 2.1. Tillitsnivå kommuniceras som del av enligt specifikation i [IdAssurProf] och [AuthCtx]. Faktiska tillitsnivåer och namnrymd är definierade i tillitsramverket []. Det är valfritt men rekommenderat att utöver tillitsnivå även kommunicera använd autentiseringsmetod som del av . XML-attributet NameFormat på elementet Attribute måste vara urn:oasis:names:tc:SAML:2.0:attrname-format:uri Attributnamn måste vara en som beskrivet ovan. XML-attributet FriendlyName är valfritt. Alla attribut måste ha en OID och ska använda denna som namn. Alla attributvärden måste vara av typen "xs:string". Ett exempelattribut formaterat enligt ovanstående regler ges nedan: Pseudonymisering består i att ersätta identifierbar data såsom personnummer med en artificiell identifierare. Av anonymitetskäl är den unika användaridentifieraren i identitetsintyget en pseudonym. Pseudonymen genereras av IdP baserat på EntityID för IdP, SP samt en unik användaridentifierare endast känd av IdP:n. Det är viktigt att pseudonymen är genererad på ett sådant sätt att den inte kan användas för att härleda användarens identitet. I samtliga användarfall beskrivna i avsnitt 2.1 kommuniceras pseudonymen som SAML NameID i identitetsintyget. Endast attribut med befintlig allokerad OID (objektidentifierare se [RFC3061]) är tillåtna. Följande obligatoriska attribut hanteras som del av identitetsintyg inom federationen. Namn (alternativ) *Attributet används även för samordningsnummer [Samord]. ** Fördelen med displayName är att attributet är av single value typ. Identifieraren ska identifiera en organisation (svenskt organisations- nummer) med möjlighet att specificeras en inom organisationen lokal identifierare, t.ex. anställningsnummer eller användarnamn. Roll inom organisationen specificeras inte genom denna identifierare. < se-org-no > [/< local-part >] Exempel på organisationsidentifierare för en organisation med organisationsnummer skulle kunna vara: Inom infrastrukturen för identifiering kan det uppstå behov attribut som endast några få deltagare i infrastrukturen behöver känna till. Om en attributstjänst exempelvis tillhandahåller ett attribut som är anpassat till en viss tjänst, så är det bara användare av den tjänsten som behöver känna till hur detta attribut ska hanteras. Definition av attribut som används inom ramen för svensk e- legitimation kan därför hanteras olika beroende på attributets användningsområde: Attribut som måste kunna hanteras av alla deltagare i infrastrukturen – Information om dessa attribut införs i infrastrukturens attribut- specifikation Attribut som är av allmänt intresse – Information om dessa attribut kan ingå i infrastrukturens attributsspecifikation men kan även definieras i separata dokument som godkänns och publiceras av e-legitimations- nämnden. Privata attribut som bara behöver förstås av några få aktörer inom ramen för ett avgränsat användningsområde - Definition av dessa attribut kan göras oberoende av e-legitimationsnämnden. Om ett sådant attribut listas i något av federationens register (metadata) så måste dock attributets definition godkännas och publiceras av e-legitimations- nämnden. En aktör som behöver definiera ett nytt attribut med begränsat användningsområde kan göra så och fritt förmedla information om detta attribut till berörda parter utan att ansöka om tillstånd. Ett exempel på en tjänst som begagnar attributsförfrågan skulle kunna vara att vill låta privatpersoner se skattekonton för de företag respektive person företräder. För att ta reda på denna information gör en attributförfrågan till . Attributsintyg använder SAML-profilen / Response definierad i [SAML2Prof] och [SAML2Core]. Attributsförfrågningar använder en så kallad och attributsintyget kommuniceras inom ramen för ett . Attributförfrågningar autentiseras mot attributintygstjänsten med e- tjänsteleverantörens certifikat (enligt metadata) som klientcertifikat. I denna specifikation görs ingen reglering av vilken information som får eller måste kommuniceras inom attributsintyg inom federationen. Däremot ges i följande tabell rekommendationer för vilka faktiska attribut som bör användas för att representera vissa vanliga egenskaper. Nedanstående tabell kompletterar attributdefinitionerna i avsnitt 1.4. OASIS Standard, Authentication Context for the (SAML) V2.0, . OASIS Standard, SAML V2.0 Identity Profiles Version 1.0, . RFC 3061, A URN Namespace of Object Identifiers, IETF Proposed Standard, . Samordningsnummer, SKV 707, utgåva 2, OASIS Standard, Assertions and Protocols for the (SAML) V2.0, . OASIS Standard, Profiles for the Assertion Markup Language (SAML) V2.0, mars Utredningen kring bildandet av en ny e-legitima- tionsnämnd FI 2010:05, , 2010 Användning av SAML metadata för svensk eID-federation Hanteringen av federationsregister och förtroende inom identitets- federationen ska följa OASIS Metadata Interoperability Profile [MetaIOP]. Profilen är framtagen för att standardisera upprättande av förtroende via metadata. Federationsregister signeras av federations- operatören. Attribut refererade i metadata identifieras unikt av sin OID. Obligatoriska attribut och hantering av aktörerna egendefinierade attribut beskrivs i attributspecifikationen [AttrSpec]. Såväl identitets- som attributsintyg ska både krypteras och signeras. Ingen reglering görs av identitetsförfrågningar medan attributs- förfrågningar måste signeras. För att på ett enkelt sätt garantera global unicitet för EntityID rekommenderas federationsaktörerna använda ett URI-baserat format involverande den egna organisationen. Utöver EntityID förväntas Identitetsintygsgivare kommunicera följande information via metadata i enlighet med [MetaIOP]: Läsbart namn som unikt identifierar e-legitimationsutfärdaren. Lämpligt attribut är orgFriendlyName. tillgängliga tillitsnivåer, se avsnitt 1.3.1. Ovanstående kan kompletteras med tillgängliga attribut representerat som en sekvens av element. Bilaga 14 SOU 2010:104 Attributintygsgivare behöver endast kommunicera URL samt certifikat. E-tjänsteleverantörer förväntas kommunicera följande information via metadata i enlighet med [MetaIOP] och [SAML2Meta]: efterfrågade användarattribut som en sekvens av efterfrågad tillitsnivå, se avsnitt 2.3. En e-tjänsteleverantör kan tillhandahålla flera e-tjänster förutsatt att tjänsterna har unika URL:er. I och med att metadata används i praktiken har det uppstått ett behov av att kunna lägga in godtyckliga attribut. Detta regleras i SAML V2.0 Metadata Extension for Entity Attributes [MetaAttr]. Nedan ges ett exempel på hur man lägger till en tillitsnivå för antingen en identitetsintygsgivare eller en e-tjänsteleverantör. Attributnamnet Name ska som i exemplet ovan vara: urn:oasis:names:tc:SAML:attribute:assurance-certification För att göra det möjligt för identitetsintygsgivare att kontrollera sin grafiska representation hos anvisningstjänsten är det möjligt att använda metadata UI extensions beskrivna i [MetaUI]. Användningen av gränssnittsutvidgningen är frivillig inom federationen. Federationens tre register sammanställs, signeras och publiceras av federationsoperatören. Federationsoperatören ansvarar för att innehållet i respektive register är korrekt. Medlemsinformation kan inhämtas till registret med valfri metod förutsatt att äktheten kan garanteras. För att garantera en god tillgänglighet till anvisningstjänsten rekommenderas e-tjänsteleverantörer att lagra en lokal kopia av federationsregistret för identitetsintygsgivare. Utredningen kring bildandet av en ny e-legitimations- nämnd FI 2010:05, Attributspecifikation, 2010 Specification, SAML V2.0 Extension for Entity Attributes Version 1.0, 2009. Specification, SAML V2.0 Interoperability Profile Version 1.0, 2009. Specification, SAML V2.0 Extensions for Login and Discovery User Interface Version [SAML2Core] OASIS Standard, Assertions and Protocols for the Assertion Markup Language (SAML) V2.0, 2005. [SAML2Meta] OASIS Standard, Metadata for the Assertion Markup Language (SAML) V2.0, 2005 Software requirements for the Swedish Infrastructure for eID This document is directly based on the InCommon implementation profile for SAML interoperability [InCommon]. Some modifications and additions have been made to adjust to special requirements of the Swedish Infrastructure for eID. The major adjustments relate to the use of pseudonyms and attribute queries. This profile specifies behavior and options that implementations of the SAML v2 Web Browser SSO Profile and Assertions Query/Request Profile [SAML2Prof] are required to support for use within the Swedish eID-federation. The requirements specified are in addition to the requirements of the original profiles, and readers should be familiar with all relevant reference documents. such requirements are not repeated here except where deemed necessary to highlight a point of discussion or draw attention to an issue addressed in errata, but remain implied. SAML leaves substantial latitude to implementations with regard to how software is architected and combined with authentication and application infrastructure. Where the terms "Identity Provider" and "Service Provider" are used, they should be understood to include the total software footprint intended to provide the desired functionality; no specific assumptions are made as to how the required features are exposed to deployers, only that there is some method for doing so. Identity Provider, Service Provider, and implement- tations MUST support the use of SAML v2.0 Metadata [SAML2Meta] in conjunction with their support of the SAML V2.0 Web Browser SSO Profile [SAML2Prof]. Additional expectations around the use of particular metadata elements related to profile behavior may be encountered in subsequent sections. Implementations MUST support the SAML V2.0 Metadata Interoperability Profile Version 1.0 [MetaIOP]. It is OPTIONAL for implementations to support the generation, publication, or exportation of metadata, but implementations MUST support the following mechanisms for the importation of metadata: -remote resource at fixed location accessible via HTTP 1.1 [RFC2616] or HTTP 1.1 over TLS/SSL [RFC2818] In the case of HTTP resolution, implementations MUST support use of the "ETag" header for cache management; other cache control support is OPTIONAL. Implementations SHOULD support the use of more than one fixed location for the importation of metadata, but leave their behavior unspecified if a single entity's metadata is present in more than one source. In accordance with [MetaIOP], importation of multiple entities' metadata contained within an element MUST be supported. Verification of metadata MUST include XML signature verification at least at the root element level, and SHOULD support the following mechanisms for signature key trust : -direct comparison against known keys -some form of path-based certificate validation against one or more trusted root certificates and certificate revocation lists The latter mechanism does not impose a particular profile for certificate validation, as no such profile has wide enough adoption across tools and libraries to warrant such a requirement, but should be understood as being consistent with the "usual" practices encountered in the imple- mentation of certificate validation. Where possible, implementations SHOULD document known limitations of the mechanisms they employ. Implementations SHOULD support the SAML V2.0 Metadata Extension for Entity Attributes Version 1.0 [MetaAttr] and provide policy controls on the basis of SAML attributes supplied via this extension mechanism. Finally, implementations SHOULD allow for the automated updating/reimportation of metadata without substantial disruption of services. 3 Identity Provider Discovery Service Provider and implementations MUST support the Protocol Profile in conformance with section 2.4.1 of [IdPDisco]. Identity Provider and Service Provider implementations MUST support the following SAML V2.0 name identifier formats, in accordance with the normative obligations associated with them by [SAML2Core]: Support for other formats is OPTIONAL. Identity Provider and Service Provider implementations MUST support the generation and consumption of elements that conform to the MACE-Dir Attribute Profile for SAML 2.0 [MACEAttr], with the exception that the ability to support elements whose values are not simple strings (e.g., , or other XML values) is OPTIONAL. As a non-normative summary, this requirement primarily implies the capability to ensure the use of particular Name and NameFormat values when generating and consuming elements, rather than relying on hard-wired assumptions or proprietary sets of attribute identifiers. 6.1Binding and Security Requirements Identity Provider and Service Provider implementations MUST support the use of the HTTP-Redirect binding [SAML2Bind] for the transmission of messages, including the generation or verification of signatures in conjunction with this binding. Because verification of signatures by Identity Providers cannot be guaranteed in deployments, Service Provider implementations MUST NOT rely on the integrity of a signed request for the enforcement of requirements derived from options such as the ForceAuthn attribute or the element. Rather, Service Providers MUST enforce such requirements based on the content of the messages they receive. Support for other bindings is OPTIONAL. In addition to standard core- and profile-driven requirements, Service Provider implementations MUST support the inclusion of at least the following child elements and attributes (when appropriate): Identity Provider implementations MUST support all child elements and attributes defined by [SAML2Core], but provide that support in the form of returning appropriate errors when confronted by particular request options. However, implementations SHOULD fully support the options enumerated above. Implementations limit their support of the element to the value "exact" for the Comparison attribute. 7.1Binding and Security Requirements Identity Provider and Service Provider implementations MUST support the use of the HTTP-POST binding [SAML2Bind] for the transmission of messages. Support for other bindings is OPTIONAL. Identity Provider and Service Provider implementations MUST support the signing of elements in responses; support for signing of the element is OPTIONAL. Identity Provider and Service Provider implementations MUST support the use of XML Encryption via the element; support for the and elements is OPTIONAL. The Web Browser SSO Profile allows responses to contain any number of assertions and statements. Identity Provider implementations MUST allow the number of , , and elements in the message to be limited to one. In turn, Service Provider implementations limit support to a single instance of those elements when processing messages. It is OPTIONAL for Identity Provider implementations to support the inclusion of a Consent attribute in messages. Service Provider implementations that provide some form of session semantics MUST support the element's Identity Provider and Service Provider implementations MUST support the Assertion Query/Request Profile as defined in [SAML2Prof] and [SAML2Core]. 8.1Binding and Security Requirements Identity Provider and Service Provider implementations MUST support the use of the SOAP binding [SAML2Bind] for the transmission of attribute query and response messages. Identity Provider and Service Provider implementations MUST support requests with accompanying and corresponding responses. Support for other assertion request types is OPTIONAL. RFC 2616, Hypertext Transfer Protocol – HTTP/1.1, RFC 2818, HTTP , 2000 Specification, Identity Provider Protocol and Profile, 2008. InCommon Federation SAML 2.0 Profiles, InCommon SAML Attribute Profiles, . Specification, SAML V2.0 Metadata Extension for Entity Attributes Version 1.0, 2009. Specification, SAML V2.0 Metadata Interoperability Profile Version 1.0, 2009. [SAML2Core] OASIS Standard, Assertions and Protocols for the Assertion Markup Language (SAML) V2.0, 2005. [SAML2Meta] OASIS Standard, Metadata for the Assertion Markup Language (SAML) V2.0, 2005. [SAML2Bind] OASIS Standard, Bindings for the Assertion Markup Language (SAML) V2.0, 2005. [SAML2Prof] OASIS Standard, Profiles for the Assertion Markup Language (SAML) V2.0, 2005. Teknisk specifikation för anvisningstjänst inom infrastukturen för Svensk e-legitimation Detta dokument utgör teknisk specifikation för en anvisningstjänst () som upprättas inom ramen för infrastukturen för Svensk e-legitimation. Anvisningstjänstens funktion är att underlätta användarens val av e-legitimation vid utnyttjande av en e-tjänst. Genom anvisningstjänsten ges användaren en möjlighet att informera om vilken e-legitimation användaren brukar använda så att ett förenklat gränssnitt, där användarens tidigare använda e- legitimation kommer upp som förvalsalternativ, kan skapas vid legitimering. Användarens tidigare val av e-legitimationer kommuniceras inte med e-tjänsten utan hanteras uteslutande mellan användaren och anvisningstjänsten genom en s.k. cookie som lagras i användarens webbläsare. Denna cookie innehåller ingen information om användarens aktiviteter eller identitet och anvisningstjänsten har ingen information om vilken individ som utnyttjar tjänsten för att välja e-legitimation. Genom att lagra senaste val lokalt hos användaren genom denna metod behöver inte anvisningstjänsten lagra någon information om användares senaste val i anvisningstjänsten mellan användarens nyttjande av e-tjänster. Anvisningstjänsten tillhandahålls i två utförande. I det ena utförandet överförs användaren till anvisningstjänsten som tillhandahåller gränssnitt för användarens val av e-legitimation. I det andra utförandet tillhandahåller e-tjänsten ett eget gränssnitt mot användaren genom en dynamisk webbsida som automatiskt anpassas till tidigare val av e-legitimation genom kommunikation med anvisningstjänsten. I detta utförande är inte tillgång till anvisningstjänsten kritisk. Om anvisningstjänsten inte är tillgänglig innebär detta bara att användaren inte får upp sin e-legitimation som förval. En e-tjänst som tillämpar det första utförandet är dock beroende av att anvisningstjänsten är tillgänglig för användaren för att en legitimering ska kunna genomföras. I inget utförande är det kritiskt att användaren accepterar en cookie från anvisningstjänsten. En användare som inte accepterar att lagra en cookie, eller av andra orsaker inte har en cookie med förvalsinformation lagrad, får göra ett förnyat val. E-tjänster måste inte använda anvisningstjänsten. Ett tredje alternativ för e-tjänsten är att skapa en helt egen dialog med användaren för val av e-legitimation genom att hämta nödvändig information från federationens metadata (federationsregistret). Detta alternativ kan även kombineras med alternativ 2 så att gräns- snittet fungerar även om anvisningstjänsten av någon anledning inte är tillgänglig. Det är rekommenderat att alltid använda anvisningstjänsten i någon form där detta är möjligt för att kunna erbjuda användarna ett förenklat gränssnitt. 2 Definitioner och förkortningar Följande begrepp används som synonymer Service Provider (E-tjänst) Identity Provider (Identitetsutfärdare) Denna specifikation är uteslutande definierad för Anvisningstjänst inom ramen för Infrastukturen för Svensk e-legitimation. Anvis- ningstjänstens funktion förutsätter att varje typ av e-legitimation som representeras av ett unikt namn i användargränssnitt för val av e-legitimation representeras av en specifik IdP och att denna unika relation mellan e-legitimation och IdP är dokumenterad i federa- tionens metadata (federationsregistret). Anvisningstjänsten måste kunna identifiera en och endast en Identitetsutfärdare utifrån det val av e-legitimation som användaren gör. Detta innebär att användaren aldrig först ska behöva välja e- legitimation för att sedan behöva göra ytterligare att val av vilken Identitetsutfärdare som ska utföra autentisering. Anvisningstjänst som upprättas enligt denna specifikation ska tillhandahålla tjänst till e-tjänster som underlättar processen att fastställa vilken Identitetsutfärdare som ska autentisera en användare. Anvisningstjänsten ska erbjuda tjänsten i två utförande avsedda för 1.E-tjänster som inte tillhandahåller eget gränssnitt för användarens val av e-legitimation, och 2.E-tjänster som själva tillhandahåller att gränssnitt för användarens val av e-legitimation. 5Utförande 1 – e-tjänst utan gränssnitt för val av e-legitimation Detta utförande av Avisningstjänsten ska implementeras enligt Protocol and Profile [SAML-Discovery]. 1.Begäran om anvisning genom HTTP redirect till anvisningstjänst 3.Resultat av anvisning genom HTTP redirect till e-tjänsten. Enligt detta utförande sker anvisning av Identitetsutfärdare enligt följande förfarande: 1.E-tjänsten skickar en begäran om anvisning som en HTTP Get request enligt [SAML-Discovery] till Anvisningstjänsten i en HTTP redirect. 2.Anvisningstjänsten (DS) returnerar en webbsida där användaren ges möjlighet att välja e-legitimation.