BILAGA 2 Tekniska krav Version 0.81

Transkript

1 BILAGA 2 Tekniska krav Version 0.81 Sammanfattande teknisk kravbild Sambi har likt andra federativa initiativ som mål att använda följande SAMLv2 1 profiler: Implementationsprofilen egov2 2 (beskriver vilka SAML förmågor som erfordras) Deploymentprofilen saml2int 3 (beskriver hur SAML förmågorna ska användas) De SAML förmågor, där merparten är en del av implementationsprofilen egov2, och hur SAML förmågor påverkas av deploymentprofilen saml2int, redovisas övergripande i beskrivningen av den tekniska kravbilden nedan. Aktörskrav Tjänsteleverantör (SP, Service Providers) Den Medlem som erbjuder tjänster och som har förmågan att konsumera utfärdade elektroniska intyg är att betrakta som tjänsteleverantör. Tjänsteleverantören är ofta kravställare av identifieringsbegrepp och eventuellt erfordrade attribut inom ramen för vad som överenskommits i federationen. I de fall tjänsteleverantören är informationsägare kravställer denne också tillitsnivå (LoA) med utgångspunkt från informationens skyddsvärde. Intygsutfärdare (IdP, Identity Provider) Den Medlem som har förmågan identifiera och autentisera en användare är att betrakta som intygsutfärdare. En lyckad identifiering och autentisering medför att intygsutfärdaren kan ställa ut ett intyg. Det bör beaktas att i rollen som intygsutfärdare kan vederbörande också ha tillgång till erforderliga källor för att bidra med de eventuella attribut som efterfrågas av tjänsteleverantören. Attribut kan vara allt från personliga egenskaper till behörigheter. 1 Organization for the Advancement of Structured Information Standards (OASIS) Security Assertion Markup Language (SAML) 2 Kantara Initiative egov 2.0 profile 3 Interoperable SAML 2.0 Web SSO deployment profile

2 Det kan inte nog poängteras att ett intyg inte nödvändigtvis behöver innehålla någon information som knyter an till en personuppgift. Användare (Subject) Den som använder federationens tekniska infrastruktur benämns kort och gott användare (subjekt). Det kan vara en fysisk person, ett program eller en process. I Sambi är en användare vanligtvis en fysisk person som agerar i tjänsten där denne representerar eller verkar hos en juridisk person. Federationsoperatör Federationsoperatören är den aktör som tillhandahåller gemensamma infrastrukturella tjänster för federationen. En av federationsoperatörens viktigaste uppgifter är att tillhandahålla digitalt signerat aggregerat SAML metadata vilket kan anses vara federationens kärna, den grundläggande tilliten. Övergripande teknisk kravbild Krypteringsnycklar Samtliga Medlemmar i federationen ska hantera och förvara sina krypteringsnycklar i enlighet med de krav som ställs i Sambis tillitsramverk. Där annat inte sägs ska val av algoritmer och nyckellängder för autentisering, kryptering och signering följa NIST SP samt ETSI TS Detta kan till exempel betyda SHA2 ( ) och RSA nycklar som är minst 2048 bitar långa. SAML metadata (MD) För att Medlemmarna i federationen ska kunna lita på varandras intyg krävs ett utbyte av de publika nycklarna, som används för att verifiera intygens signaturer. Utbytet sker genom att lokalt SAML metadata (MD), vilket beskriver en aktörs egenskaper, förmågor och publika nycklar, aggregeras till federationsoperatören vilken digitalt signerar och publicerar det aggregerade SAML metadatat. Det aggregerade och signerade SAML metadata som publiceras av federationsoperatören är således den samlade bilden av federationens samtliga aktörers egenskaper, förmågor och publika nycklar A/sp A.pdf 5

3 Federationens aggregerade och signerade SAML metadata publiceras här: 1_0.xml Där 1.0 är en versionsbeteckning. 1_0.xml Där 1.0 är en versionsbeteckning. Federationsoperatörens publika nyckel som används för verifiering av SAML metadata publiceras här: En checksumma (hash) av den publika nyckeln kommer att tillgängliggöras över ytterligare en kanal. Varje Medlem ska signaturverifiera SAML metadata vid varje förändring mot minst en nyckelkälla. Sambi använder saml2int som deployment profil vilken tydligt beskriver hur SAMLmetadata ska presenteras. Utformningen av SAML metadata regleras i OASIS SAML V2.0 metadata specification [SAML2Meta 6 ] och hantering av SAML metadata regleras i OASIS Metadata Interoperability Profile [MetaIOP 7 ]. Samtliga ingående Medlemmar i federationen ska stödja detta. Anvisningstjänst (DS) I grundscenariot där en användare önskar använda en tjänst men är oidentifierad så blir denne ombedd att autentisera sig. I en tvåpartsrelation så vet tjänsten vilken intygsutfärdare som denne ska anvisa användaren till. I en federation likt Sambi med kanske 100 talet intygsutfärdare krävs sålunda en generisk funktion för att anvisa användaren till sin intygsutfärdare. Funktionen benämns anvisningstjänst (DS, discovery services). Anvisningstjänsten använder SAML metadata för att visa användaren de i federationen ingående intygsutfärdarna. Federationens centrala anvisningstjänst finns här: Det bör poängteras att en central anvisningstjänst inte är en nödvändighet utan tjänsteleverantören kan själv välja att implementera en funktion för lokal anvisning baserat på SAML metadata. 6 open.org/security/saml/v2.0/saml metadata 2.0 os.pdf 7 open.org/security/saml/post2.0/sstc metadata iop.pdf

4 Det bör också poängteras att det finns möjlighet till ett scenario med icke ombedda intyg (unsolicited respons). Där ansluter användaren först till sin intygsutfärdare med en parameter i anropet som sedan används för att anvisa användaren till rätt tjänst. Hantering av anvisning regleras av OASIS Identity Provider Discovery Service Protocol Profile [IdPDisco 8 ]. Samtliga ingående Medlemmar i federationen bör stödja detta. Pseudonymiserade identitetsbegrepp (NameID) En av Sambis hörnstenar är att ständigt värna om den personliga integriteten därför bör, i möjligaste mån, pseudonymer användas som identifieringsbegrepp (NameID). Det finns två typer av pseudonymer. Dels persistenta pseudonymer vilka har egenskapen att de alltid mappar en användare till samma pseudonym per tjänst, dels transienta pseudonymer vilka aldrig mappar en användare till samma pseudonym. Vid användning av persistenta pseudonymer presenteras olika pseudonymer för olika tjänster. Vid användning av transienta pseudonymer presenteras en ny pseudonym vid varje nytt tillfälle och för varje tjänst. Pseudonymer är en del av standardspecifikationen för SAML 2.0 [SAML2Core 9 ] och följande ska stödjas: urn:oasis:names:tc:saml:2.0:nameid format:persistent urn:oasis:names:tc:saml:2.0:nameid format:transient Autentiseringsförfrågan I grundscenariot där en användare önskar använda en tjänst, men är oidentifierad så blir denne ombedd att autentisera sig. Den förfrågan som tjänsten skapar i detta scenario är en autentiseringsförfrågan vilken användaren tar med sig till intygsutfärdaren. Sambi använder saml2int som deployment profil vilken tydligt beskriver hur SAML V2.0 Web Browser SSO Profile [SAML2Prof 10 ] ska användas vilket i sin tur återspeglar sig på autentiseringsförfrågan. Där återfinns bland annat att: Kommunikationen ska skyddas med TLS/SSL på transportnivå Det inte är något krav att signera autentiseringsförfrågan Autentiseringssvar Autentiseringssvaret kan vara en följd av en autentiseringsförfrågan, men det kan också vara ett autentiseringssvar utan någon föregående autentiseringsförfråga vilket benämns icke ombedda intyg (unsolicited respons) 8 open.org/security/saml/post2.0/sstc saml idp discovery.pdf 9 open.org/security/saml/v2.0/saml core 2.0 os.pdf 10 open.org/security/saml/v2.0/saml profiles 2.0 os.pdf

5 Sambi använder saml2int som deployment profil vilken tydligt beskriver hur SAML V2.0 Web Browser SSO Profile [SAML2Prof] ska användas vilket i sin tur återspeglar sig på autentiseringssvaret. Där återfinns bland annat: Kommunikationen ska skyddas med TLS/SSL på transportnivå Om TLS/SSL inte kan tillämpas ska autentiseringssvaret krypteras i sin helhet Autentiseringssvaret ska signeras Tjänster ska acceptera icke ombedda intyg (unsolicited respons) Hantering av olika tillitsnivåer (LoA) Sambi är en federation som hanterar flera olika tillitsnivåer i enlighet med tillitsramverket. Tjänsteleverantören är den som väljer tillitsnivå utifrån informationstillgångens skyddsvärde. Därför måste Medlemmarna i mellan kunna utbyta information om vilka tillitsnivåer som en intygsutfärdare kan erbjuda och vilken tillitsnivå som tjänsteleverantören kräver. Informationen om tillitsnivån kan dels adderas i SAML metadata, dels inom ramen för en autentiseringsfråga och ett autentiseringssvar. Information om tillitsnivå i SAML metadata ger fördelen att anvisningstjänsten, som använder SAML metadata för att presentera för användare lämpliga intygsutfärdare, kan begränsa presentationen till användare till att enbart presentera de intygsutfärdare som minst uppfyller den efterfrågade tillitsnivån. I SAML metadata representeras tillitsnivån av ett eller flera attribut. Samtliga ingående Medlemmar bör hantera utökat SAML metadata som tillåter presentation av attribut i enlighet med SAML V2.0 Metadata Extension for Entity Attributes 11. Attributen för tillitsnivå presenteras i enlighet med SAML V2.0 Identity Assurance Profiles 12 och har följande benämning: Utbytet av informationen om tillitsnivå inom ramen för en autentiseringsfråga och ett autentiseringssvar ger möjlighet att hantera det faktum att en intygsutfärdare kan representeras av olika kategorier av användare där det inte är självklart att alla användare representerar samma tillitsnivå. Vidare kan en användare ha tillgång till olika autentiseringsmetoder som i sin tur kan representera olika tillitsnivåer. Utbytet av information sker inom ramen för Authentication Context for the OASIS Security Assertion 11 open.org/security/saml/post2.0/sstc metadata attr.pdf 12 open.org/security/saml/post2.0/sstc saml assurance profile cd 01.pdf

6 Markup Language (SAML) V Presentationen av tillitsnivåerna sker i enlighet med SAML V2.0 Identity Assurance Profiles. Sambis tillitsnivåer presenteras som governingagreementref attribut under elementet GoverningAgreement i Authentication Context och har följande benämningar: Samtliga ingående Medlemmar bör stödja detta. Notera att Medlemmar som inte har stöd att hantera olika tillitsnivåer enligt ovan antas tillhöra tillitsnivå tre (LoA 3) i Sambi. Single logout (SLO) Sambi ställer inledningsvis inget krav på att ingående Medlemmar ska stödja singlelogout. Federationen sätter dock inte några infrastrukturella hinder att implementera single logout. Den tekniska specifikationen för att hantera single logout inryms i Single logout Profile 14. Noterbart att själva sessionshanteringen inte är något som hanteras inom ramen för SAML viket gör frågan större än att bara vara en del i en teknisk specifikation. Om en tjänst implementerar funktionen är det viktigt att det framgår i användargränssnittet att den är en single logout som utförs och att det innebär en användare loggas ur från (förhoppningsvis) alla tjänster där denna är inloggad. Attributstjänst (AA) Sambi har inte inledningsvis pekat på några för federationen gemensamma attributstjänster (AA, Attribute Authority). Federationen sätter dock inte några infrastrukturella hinder att implementera attributstjänster. Exempelvis skulle Socialstyrelsen kunna ha en attributstjänst för att lämna uppgifter om legitimation och specialitet. Tid Det är avgörande för Sambi att ingående Medlemmar använder en tillförlitlig källa för tid. Tidskällan ska vara spårbar till den svenska nationella tidsskalan UTC(SP) 15. Detta realiseras förslagsvis med det standardiserade protokollet, Network Time Protocol (NTP) open.org/security/saml/v2.0/saml authn context 2.0 os.pdf 14 open.org/security/saml/v2.0/saml profiles 2.0 os.pdf 15