1. Introduktion

Denna profil definierar ett urval av alla tekniker och lösningar som definieras av SAML samt SAMBI Attributspecifikation 1.0. Syftet är att implementatörer kan anpassa sig enligt krav i denna profil och på så sätt säkert erhålla interoperabilitet dem emellan.

Profilen är framtagen för att SAML Web SSO skall fungera i federerad miljö med olika produkter, så att sann Web SSO kan erhållas.

Profilen är en utökning på OASIS specifikationer gällande SAML V2.0 (se referenser). För att uppfylla denna profil SKALL alla krav i denna profil samt kraven som OASIS ställer i sina specifikationer (primärt SAML Web SSO profile) vara uppfyllda. Denna profil försöker inte upprepa sådana krav som finns i grundspecifikationerna.

Två existerande profiler har valts som arbetsunderlag för framtagandet av denna profil. Dessa är

• Kantara Initiative eGovernment Implementation Profile of SAML V2.0 [eGov2] 
• Interoperable SAML 2.0 Web Browser SSO Deployment Profile [SAML2Int]

1.1. Specifikation

Identifikation: sambi-saml-profil
Kontaktinformation: Per Mützell, Inera

1.2. Notation

Tjänsteleverantör (Service Provider) benämns som SP genomgående i profilen.

Identifikationsleverantör (Identity Provider) benämns som IdP genomgående i profilen.

Senast vald IdP (om sådan finns) benämns som SSO IdP genomgående i profilen.

XML Element skrivs med annat, "oformaterat", typsnitt

   <saml2p:AuthnRequest>

Hänvisning till referenser skrivs inom hakparenteser [referensidentifikation]

• SKALL är de krav som måste uppfyllas för att vara kompatibel med denna profil.
• KAN är de krav som är frivilliga, huruvida de uppfylls eller inte påverkar inte kompatibiliteten mot denna profil.
• BÖR är krav som rekommenderas att följas.

1.3. XML namnrymd

Följande namnrymder hanteras av profilen

saml2

urn:oasis:names:tc:SAML:2.0:assertion

saml2p

urn:oasis:names:tc:SAML:2.0:protocol

md

urn:oasis:names:tc:SAML:2.0:metadata

idpdisco

urn:oasis:names:tc:SAML:profiles:SSO:idp-disovery-protocol

mdattr

urn:oasis:names:tc:SAML:metadata:attribute

ds

http://www.w3.org/2000/09/xmldsig#

2. Metadata och förlitande hantering

SAML Metadata SKALL användas för att distribuera information mellan SAML-entiteter.

IdP och SP SKALL stödja SAML V2.0 Metadata Interoperability Profile Version 2.0 [MetaIOP]

IdP och SP SKALL stödja import och export av SAML V2.0 Metadata dokument.

IdP och SP BÖR stödja import och export av dokument genom följande metoder

• Filresurs
• Publicera och erhålla via “Well-Known Location”, definierad av [SAML2Meta]

Implementationer BÖR stödja PKIX och OCSP/CRL för att säkerställa status på SAML entiteters certifikat, som används till ex. signering, server autentiserad SSL/TLS etc.

Implementationer KAN stödja ytterligare metoder för att säkerställa certifikat, ex. kontrollera certifikatets subjektnamn.

IdP och SP SKALL stödja metadatadokument vars rot-element är <md:EntityDescriptor> eller <md:EntitiesDescriptor>.

BÖR att vid uppdatering av nycklar ha med den äldre, samt den nya nyckeln i metadata dokumentet (i.e. två eller fler <md:KeyDescriptor>) för att få en smidig övergång.

2.1. IdP Metadata

IdP SKALL hantera metadata enligt följande

• SKALL finnas ett <md:IDPSSODescriptor> element.
• SKALL finnas minst en <md:KeyDescriptor> som innehåller ett <ds:KeyInfo> som i sin tur identifierar IdPs certifikat via <ds:X509Certificate>.
• BÖR finnas ett eller flera <md:NameIDFormat> som identifierar vilka namn-id format som stödjas.

2.2. SP Metadata

• Om [IdPDisco] används BÖR ett eller flera <idpdisco:DiscoveryResponse> finnas (under <md:Extensions> element), som beskriver vart IdP discovery svaret skall skickas. Om IdPDisco används och SP saknar <idpdisco:DiscoveryResponse> måste HTTP parameter för svaret anges enligt [IdPDisco].
• SKALL finnas ett <md:SPSSODescriptor> element.
• SKALL finnas minst en <md:keyDescriptor> som innehåller ett <ds:KeyInfo> som i sin tur identifierar SPs certifikat via <ds:X509Certificate>.
• SKALL finnas ett eller flera <md:NameIdFormat> som identifierar vilka namn-id format som stödjs.
• BÖR finnas <md:AttributeConsumerService> som beskriver vilka tjänster SP tillhandhåller, samt dess egenskapsbehov.
• BÖR finnas <md:SingleLogoutService> som beskriver vilka SLO-tjänster SP tillhandahåller (om SP:n stödjer SLO).
• SKALL finnas ett <md:Organization> element som namnger organsiationen för denna SP.
• SKALL finnas ett <md:ContactPerson> element med egenskap "contactType" satt till support och BÖR finnas ytterligare ett <md:ContactPerson> element med egenskapen "contactType" satt till "technical". <md:ContactPerson> BÖR innehålla minst ett <md:EmailAddress> element.

3. Namn-id format

IdP SKALL stödja samtliga nedanstående namn-id format, och SP SKALL stödja minst ett.

• urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
• urn:oasis:names:tc:SAML:2.0:nameid-format:transient


4. Egenskaper

<saml2:Attribute> SKALL innehålla egenskapen NameFormat som är satt till urn:oasis:names:tc:SAML:2.0:attrname-format:uri.

<saml2:AttributeValue> BÖR endast innehålla en XML nod, som då är text.

4.1. Bas-egenskaper

Nedan specificeras alla bas-egenskaper som är definierade. Vissa egenskaper kan finnas med två gånger i utställt SAML-intyg (då även med det äldre namnet), för bakåtkompatibilitet.

Viktigt dock att ta avstånd från dessa om möjligt.

4.1.1. urn:sambi:names:attribute:authnMethod

Anger identifikationsmetod.

Möjliga värden:

urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient (Certifikat såsom SITHS)

urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorUnregistered (OTP via sms)

Källa: IdP

4.1.2. urn:sambi:names:attribute:x509IssuerName

Anger utfärdare av certifkatet (t.ex SITHS) som användes vid identifikationen. Anges enbart om certifikat användes vid identifikationen.

Källa: Issuer ifrån certifkatet som användes vid identifikationen.

4.1.3. urn:sambi:names:attribute:levelOfAssurance

Anger tillåtsnivå(LoA)

Möjliga värden:

urn:sambi:names:ac:classes:LoA1

urn:sambi:names:ac:classes:LoA2

urn:sambi:names:ac:classes:LoA3

urn:sambi:names:ac:classes:LoA4

Källa: IdP

4.1.4. http://sambi.se/attributes/1/healthcareProfessionalLicense

Tvåställig kod enligt Socialstyrelsens HOSP register. Läs mer på sambi.se...

Detta attribut mappas mot HSA-värdet hsaTitle. I de fall en mappning mot kodverk inte kan göras erhålls istället namnet i klartext som det kommit från HSA.

Äldre namn: urn:sambi:names:attribute:title
OBS!  Detta äldre attribut finns kvar i Säkerhetstjänster 2.18 i sin ursprungliga form från hsaTitle där värdet presenteras i klartext direkt från HSA (t.ex Läkare istället för tvåställig kod LK)

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  credentialInformation.healthCareProfessionalLicence

4.1.5. http://sambi.se/attributes/1/paTitleCode

Personens befattningskoder. Läs mer på sambi.se...

Äldre namn: urn:sambi:names:attribute:titleCode

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  credentialInformation.paTitleCode 

4.1.6. http://sambi.se/attributes/1/personalPrescriptionCode

Förskrivarkod för specificerad person. Läs mer på sambi.se...

Äldre namn: urn:sambi:names:attribute:personalPrescriptionCode
OBS!  Detta äldre attribut finns kvar i Säkerhetstjänster 2.14 med sin ursprungliga logik där HSA returnerar första bästa gruppförskrivarkod i det fall minst en sådan finns och personlig förskrivarkod saknas.

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  credentialInformation.personalPrescriptionCode

4.1.7. http://sambi.se/attributes/1/groupPrescriptionCode

Gruppförskrivarkoder för specificerad person. Läs mer på sambi.se...

Äldre namn: Nytt från version 2.4

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  credentialInformation.groupPrescriptionCode

4.1.8. http://sambi.se/attributes/1/employeeHsaId

Användarens HSA-ID. Läs mer på sambi.se...

Äldre namn: urn:sambi:names:attribute:employeeHsaId

1. Källa vid inloggning med SITHS Certifikat: SerialNumber ifrån certifikatets Subject-del.

2. Källa vid inloggning personnummer via engångslösen (OTP): Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  credentialInformation.personHsaId

4.1.9. http://sambi.se/attributes/1/givenName

Användarens förnamn. Läs mer på sambi.se...

Äldre namn: urn:sambi:names:attribute:givenName

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  credentialInformation.givenName

4.1.10. http://sambi.se/attributes/1/surname

Användarens mellan- och efternamn. Läs mer på sambi.se...

Äldre namn: urn:sambi:names:attribute:middleAndSurname

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  credentialInformation.middleAndSurName

4.1.11. http://sambi.se/attributes/1/systemRole

Systemroller kopplade till specificerad användare. Läs mer på sambi.se...

Äldre namn: urn:sambi:names:attribute:systemRole

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  credentialInformation.hsaSystemRole

4.1.12. http://sambi.se/attributes/1/commissionRight

Rättighet för aktuell uppdrag. Läs mer på sambi.se...

Äldre namn: urn:sambi:names:attribute:commissionRight

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  commission.commissionRight

4.1.13. http://sambi.se/attributes/1/commissionPurpose

Syfte med aktuell uppdrag. Läs mer på sambi.se...

Äldre namn: urn:sambi:names:attribute:commissionPurpose

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  commission.commissionPurpose

4.1.14. http://sambi.se/attributes/1/commissionHsaId

HSA-identitet för valt uppdrag. Läs mer på sambi.se...

Äldre namn: urn:sambi:names:attribute:assignmentHsaId

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  commission.commissionHsaId

4.1.15. http://sambi.se/attributes/1/commissionName

Namn på valt uppdrag. Läs mer på sambi.se...

Äldre namn: urn:sambi:names:attribute:assignmentName

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  commission.commissionName

4.1.16. http://sambi.se/attributes/1/healthCareUnitHsaId

HSA-identitet på den vårdenhet aktuellt uppdrag tillhör. Läs mer på sambi.se...

Äldre namn: urn:sambi:names:attribute:careUnitHsaId

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  commission.healthCareUnitId

4.1.17. http://sambi.se/attributes/1/healthCareUnitName

Namn på den vårdenhet aktuellt uppdrag tillhör. Läs mer på sambi.se...

Äldre namn: urn:sambi:names:attribute:careUnitName

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  commission.healthCareUnitName

4.1.18. http://sambi.se/attributes/1/healthCareProviderHsaId

HSA-identitet på den vårdgivare aktuellt uppdrag tillhör. Läs mer på sambi.se...

Äldre namn: urn:sambi:names:attribute:careProviderHsaId

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  commission.healthCareProviderHsaId

4.1.19. http://sambi.se/attributes/1/healthCareProviderName

Namn på den vårdgivare aktuellt uppdrag tillhör. Läs mer på sambi.se...

Äldre namn: urn:sambi:names:attribute:careProviderName

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:authorizationmanagement
Kontrakt: GetCredentialsForPersonIncludingProtectedPerson
Fält:  commission.healthCareProviderName

4.1.20. https://www.sambi.se/attributes/1/personalidentitynumber/

Identifiering av inloggad användare. Läs mer på sambi.se...

HSA levererar i dagsläget inte personnummer så detta attribut är endast definierat i förberedande syfte.

4.1.21. https://www.sambi.se/attributes/1/mail/

Individens e-postadress. Läs mer på sambi.se...

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:employee
Kontrakt: GetEmployeeIncludingProtectedPerson
Fält:  personInformation.mail

4.1.22. https://www.sambi.se/attributes/1/telephonenumber/

Individens telefonnummer. Läs mer på sambi.se...

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:employee
Kontrakt: GetEmployeeIncludingProtectedPerson
Fält:  personInformation.telephoneNumber

4.1.23. https://www.sambi.se/attributes/1/mobileTelephoneNumber/

Individens mobilnummer. Läs mer på sambi.se...

Källa: Katalogtjänst HSA
Domän: infrastructure:directory:employee
Kontrakt: GetEmployeeIncludingProtectedPerson
Fält:  personInformation.mobileNumber

4.2. Egenskaper när uppdrag saknas

Följande egenskaper medföljer även om aktören saknar uppdrag

• urn:sambi:names:attribute:authnMethod
• urn:sambi:names:attribute:x509IssuerName (endast vid autentisering genom certifikat )
• urn:sambi:names:attribute:levelOfAssurance
• http://sambi.se/attributes/1/employeeHsaId (endast vid autentisering genom certifikat)
  Äldre namn: urn:sambi:names:attribute:employeeHsaId

5. SSO IdP Identifiering

Detta kapitel identifierar metoder och tekniker som används för att identifiera SSO IdP.

Vid autentisering SKALL identifiering av aktör alltid göras mot den s.k. SSO IdP, detta för att erhålla sann Web SSO. För att göra detta finns tre möjliga alternativ.

• SP använder Identity Discovery Profile [SAML2Prof], d.v.s. common-domain cookie, för att erhålla aktörens SSO IdP.
• SP använder Identity Discovery Protocol and Profile [IdPDisco] för att erhålla aktörens SSO IdP.
• Om inget av ovan nämnda alternativ används kan SP använda en IdP som den vet agerar IdP proxy. Viktigt är dock att samma teknik används för att erhålla SSO IdP.

IdPDisco SKALL realiseras med tekniken common-domain cookie, enligt Identity Discovery Profile [SAML2Prof]. IdP proxy SKALL identifiera aktörens SSO IdP med en av de två förstnämnda metoder ovan.

Common-domain cookie SKALL vara transient.

Dessa krav resulterar i att ovan nämnda tre SSO IdP identifieringsmetoder är kompatibla med varandra.

6. Autentiseringsbegäran

6.1. Bindningar och säkerhetskrav

• SP SKALL stödja HTTP-Redirect bindning för utfärdande av begäran.
• IdP SKALL stödja HTTP-Redirect bindning för mottagande av begäran.
• IdP SKALL stödja SOAP bindning för mottagande av begäran.
• SSL/TLS SKALL användas för att säkra kommunikationen.

6.2. Begärans innehåll

SP KAN stödja, att delge vid behov, följande element

• <saml2:AssertionConsumerServiceURL> och <saml2:ProtocolBinding> eller <saml2:AssertionConsumerServiceIndex>.  
  Om <saml2:ProtocolBinding> anges SKALL det vara satt till HTTP-Post alt HTTPArtifact.  
• <saml2:ForceAuthn>
• <saml2:IsPassive>
• <saml2:AttributeConsumingServiceIndex>
• <saml2p:RequestedAuthnContext>
• <saml2p:NameIDPolicy>
• <saml2:Subject>

IdP SKALL stödja alla ovan nämnda element som definieras av [SAML2Core].

IdP SKALL verifiera att begärande SP och angiven <saml2p:AssertionConsumerService...> är överensstämmande (med hjälp av SAML Metadata).

<saml2p:AuthnRequest> KAN innehålla ett <saml2:Subject>, huruvida IdP använder det eller inte är upp till IdP.

IdP som agerar proxy SKALL stödja <saml2p:AuthnRequest> som inte innehåller ett <saml2p:Scoping> element. Proxy IdPns <saml2p:AuthnRequest> KAN innehålla ett <saml2p:Scoping> element, fastän den initiala begäran inte hade det.

Om <saml2p:RequestredAuthnContext> anges SKALL egenskapen "comparison" utelämnas eller vara satt till "exact".

7. Autentiseringssvar

7.1. Bindningar och säkerhetskrav

• SP SKALL stödja HTTP-Post, alternativt HTTP-Artifact för mottagande av svaret.
• IdP SKALL stödja HTTP-Post för utfärdande av svaret.
• SP KAN stödja HTTP-Artifact för mottagande av svaret (se HTTP-Artifact kaptiel nedan).
• IdP SKA stödja HTTP-Artifact för utfärdande av svaret (se HTTP-Artifact kapitel nedan).  
• SP SKALL säkra HTTP-Post URL med SSL/TLS.  
• <saml2:EncryptedId> och <saml2:EncryptedAttribute> BÖR inte användas.
• IdP SKALL signera <saml2:Assertion> elementet (alltså inte <saml2:Response> elementet).  
• SP och IdP SKALL hantera ”unsolicitated responses”
• SSL/TLS SKALL användas för att säkra kommunikationen.

7.2. HTTP-Artifact

• Om HTTP-Artifact används måste följande följas.
• SKALL stödja ”Artifact resolution” enligt [SAML2Prof]
• SOAP SKALL användas för <saml2p:ArtifactResolve> och <saml2p:ArtifactResponse>.
• Artifakt format urn:oasis:names:tc:SAML:2.0:artifact-04 SKALL stödjas, definierat i [SAML2Prof].

7.3. Svarets innehåll

• <saml2:Response> SKALL innehålla maximalt en <saml2:Assertion, en <saml2:AuthnStatement> och en <saml2:AttributeStatement>.
• <saml2:Subject> KAN innehålla ett <saml2:NameID>.
• SP SKALL verifiera att signaturen på  <saml2:Assertion> elementet är korrekt (med hjälp av SAML Metadata).

8. IdP som Proxy

8.1. Autentiseringsbegäran 

• SKALL stödja mappning mellan inkommande och utgående <saml2:RequestedAuthnContext> och <saml2:NameIDPolicy>.
• SKALL stödja att man kan ”dölja” <saml2:RequesterID> från utgående <saml2:AuthnRequest>.

8.2. Autentiseringssvar

• SKALL stödja mappning mellan inkommande och utgående <saml2:AuthnContext> och <saml2:NameIDPolicy>.
• SKALL stödja att man kan ”dölja” <saml2:AuthenticatingAuthority> element från utgående <saml2:AuthnContext>.

9. Koordinerad utloggning (SLO)

Initierande begäran SKALL skickas över front-channel bindnig (HTTP-Redirect alt HTTP-POST). Propagerande av begäran/svar sker på respektive SP föredragen bindning (med hjälp av metadata).

9.1. Utloggningsbegäran 

Efterföljande utloggningsbegäran mellan IdP och de SP som är autentiserade i samma session kan ske över back-channel(SOAP) eller front-channel(HTTP-Redirect/HTTP-POST).

Back-channel propagering har större fördelar än front-channel, eftersom det bedöms som mer troligt att lyckas med koordinerad utloggning. Front-channel är känslig i och med att aktörens webb-läsare identifierar för många omdirigeringar (redirects) som ett fel. Webb-läsaran kan då visa ett fel för användaren istället för att tillåta omdirigeringen. En annan nackdel med frontchannel är att aktören kan stänga webb-läsaren innan alla meddelanden har propagerats, och således erhålls inte fullständig koordinerad utloggning. Nackdelen med back-channel är att det ställer krav på SP, som ex vid lastbalanserade lösningar måste dela sessionsdata, avseende inloggning. Utöver måste SP hålla någon form av mappning mellan aktörer (alt SSO sessionsindex) och dess webbsessioner.

Om front-channel används är REKOMMENDATION att SP BÖR använda HTTP-POST bindning framför HTTP-Redirect för att undvika problemet med för många omdirigeringar.

9.2. Bindning och säkerhetskrav

• IdP SKALL stödja HTTP-POST och HTTP-Redirect för utfärdande och mottagande av <saml2p:LogoutRequest>.
• SP SKALL stödja HTTP-POST för utfärdande och mottagande av <saml2p:LogutRequest>.
• IdP KAN stödja SOAP för utfärdande och mottagande av <saml2p:LogoutRequest>.
• SP KAN stödja SOAP för utfärdande och mottagande av <saml2p:LogoutRequest>.
• SSL/TLS SKALL användas för att säkra kommunikationen.

9.3. Webb-läsare (User Agent)

• IdP SKALL stödja aktörs-initierad utloggning.
• IdP SKALL informera aktören om att endast delvis utloggning var möjlig. Då genom att returnera ett <saml2p:LogoutResponse>  element med korrekt status-kod.
• IdP SKALL tillåta administrativ utloggning av aktörer.
• SP SKALL tillåta aktörs-initierad utloggning.

9.4. Loggoutsvar 

• IdP SKALL stödja SOAP bindning och HTTP-Redirect samt HTTP-POST för utfärdande av <saml2p:LogoutResponse>.
• IdP SKALL stödja HTTP-POST och SOAP bindning för mottagande av <saml2p:LogoutResponse>.
• SP SKALL stödja HTTP-Redirect och/eller SOAP och/eller HTTP-POST för både utfärdande och mottagande av <saml2p:LogoutResponse>.
• SSL/TLS SKALL användas för att säkra kommunikationen.

10. Identifikation av aktör (och uppdragsval) 

Definierar mekanismer för att hantera identifiering av aktören, samt ev. uppdragsval.

För att byta uppdrag SKALL en SLO begäran göras (som avslutar SSO sessionen), för att sedan på nytt autentisera aktören (då uppdrag måste väljas).

• IdP SKALL identifiera aktören.
• IdP SKALL säkerställa att aktören är upplagd i HSA-katalogen, genom anrop till HSAWS. Om aktören inte är upplagd SKALL ett <saml2p:Response> med följande felkod returneras. 
  • urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal
• IdP SKALL, om aktören inte har en giltig SSO session, hämta aktörens alla uppdrag från HSA-katalogen, genom anrop till HSA-WS. Uppdragsval SKALL hanteras enligt följande: 
  • Inga uppdrag funna, autentisering skall fortgå. 
  • Ett uppdrag funnet. Det uppdraget SKALL väljas automatiskt. 
  • Två eller flera uppdrag funna. Aktören SKALL presenteras en ”välj uppdrag” dialog, där aktören aktivt väljer uppdrag.
• IdP SKALL vid forceAuthn satt till TRUE endast identifiera aktören på nytt, INTE presentera uppdragsval (förutsatt att aktören redan har en giltig SSO session).

11. Authentication Context (AuthnContext)

Detta kapitel definierar AuthnContext tillitsnivå (assurance level), enligt [IAFAL]. Tillitsnivån medföljer utställt SAML-intyg (se kapitel Egenskaper).

11.1. Tillitsnivåer (LoA)

Följande tillitsnivåer definieras av denna profil:

Tillitsnivå LoA1
Låg tillit till en aktörs identitet.
Identifikation: urn:sambi:names:ac:classes:LoA1
Nytt namn: http://id.sambi.se/loa/loa1

Tillitsnivå LoA2
Viss tillit till en aktörs identitet.
Identifikation: urn:sambi:names:ac:classes:LoA2
Nytt namn: http://id.sambi.se/loa/loa2

Tillitsnivå LoA3
Hög tillit till en aktörs identitet.
Identifikation: urn:sambi:names:ac:classes:LoA3
Nytt namn: http://id.sambi.se/loa/loa3

Tillitsnivå LoA4
Mycket hög tillit till en aktörs identitet.
Identifikation: urn:sambi:names:ac:classes:LoA4
Nytt namn: http://id.sambi.se/loa/loa4

11.2. Identifikationsmetoder 

Nedan definieras de identifikationsmetoder som initialt behöver stödjas. Aktuell identifikationsmetod medföljer utställt SAML-intyg (se kapitel Egenskaper).

SSL/TLS Certificate-Based Client Authentication
Identifikation: urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
Tillitsnivå: LoA3
Krav: SKALL stödjas av IdP. Denna används för att autentisera aktören genom dess X.509 certifikat (ex SITHS).

MobileTwoFactorUnregistered
Identifikation: urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorUnregistered
Tillitsnivå: LoA3
Krav: KAN stödjas av IdP. Denna används för att autentisera aktören med hjälp av dess mobiltelefon (ex OTP).

12. Feature matrix

13. Kryptering/Signering

[SAML2Conf] definierar SHA-1 hash algoritm som SKALL. Med hänseende till den matematiska svaghet som identifierades 2005, används den starkare hash algoritmen SHA-2 (SHA256) där det är möjligt.

Enligt [SAML2Conf] ska implementationer som använder Web SSO profilen stödja följande SSL/TLS algoritmer.

SSL-kompatibla implementeringar måste förhålla sig till följande

• SKALL SSL_RSA_WITH_3DES_EDE_CBC_SHA (Pga säkerhetsbrister i SSL stöds enbart TLS)

TLS-kompatibla implementeringar måste förhålla sig till följande

• SKALL TLS_RSA_WITH_3DES_EDE_CBC_SHA
• BÖR TLS_RSA_AES_128_CBC_SHA
• BÖR TLS_RSA_AES_256_CBC_SHA

13.1. XML

13.1.1. Signaturalgoritmer

Digest: SKALL SHA256

MAC: SKALL HMAC-SHA256

XML canonicalization: SKALL CanonicalXML (without comments)

Transform: SKALL Enveloped signature

Signature: SKALL RSAwithSHA256

Signature: BÖR DSAwithSHA256

13.1.2. Krypteringsalgoritmer

Block Encryption: SKALL TRIPLE DES, AES-128, AES-256

Key Transport: SKALL RSA-v1.5, RSA-OAEP 

14. Termer

15. Referenser

16. Bilaga 1

16.1. Avsteg från arbetsunderlaget

Följande kapitel specificerar en delmängd avsteg, alternative tillägg, som är gjorda mot de båda profiler som ligger till grunden för denna profil. För tydliga specifikationer gällande denna profil, se respektive kapitel.

• [eGov2] definierar publicering samt erhålla SAML metadata från ”Well-Known Location” som SKALL, denna profil definierar detta som BÖR.
   
• [eGov2] definierar IdPDisco som SKALL. [SAML2Int] definierar endast att om den används SKALL <idpdisco:DiscoveryResponse> inkluderas i metadata för SP, denna profil definierar detta som KAN.
   
• [SAML2Int] definierar att <md:ContactPerson> BÖR finnas. [eGov2] hanterar inte detta. Denna profil väljer att följa [SAMBI] och definierar detta som SKALL.
   
• [eGov2] definierar HTTP-Artifact bindning som SKALL, denna profil har BÖR.
   
• [SAML2Int] BÖR, medans [eGov2] SKALL säkerställa att <saml:AssertionConsumerServiceURL> alt <saml:AssertionConsumingServiceIndex> är korrekta enligt SPs metadata. Denna profil har SKALL.
   
• [SAML2Int] definierar att <saml2p:AuthnRequest> SKALL INTE innehålla <saml2:Subject>. Se kapitel namn-id format, samt autentiseringsbegäran för denna profils definition.
   
• [SAML2Int] hanterar inte koordinerad utloggning. Denna profil rättar sig enligt [eGov2], förutom ställningstagande gällande utloggning från lokal alt global session.