Innehållsförteckning

Visa innehållsförteckning

Revisionshistorik

Visa innehållsförteckning

Version	Datum	Författare	Kommentar
0.1	8 okt. 2024	Pär Hylback	Kopierat från gammal version
0.2	9 okt. 2024	Stefan Ehlert	Justerat stycke om nyckelbyten
1.0	10 okt. 2024	Pietu Hammarström	Godkänd

Introduktion

Denna profil definierar ett urval av alla tekniker och lösningar som definieras av SAML samt SAMBI Attributspecifikation 1.4.. 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]
SAMBI Tekniska krav (https://www.sambi.se/medlem-i-sambi/avtal-och-bilagor/#tekniska-krav)

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 "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.

XML namnrymd

Följande namnrymder hanteras av profilen

Prefix	Namnrymd
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#

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 SKALL stödja PKIX och BÖR stödja 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>.

SP SKALL använda funktionscertifikat som är godkänd för anslutning till IdP, se Guide till IdP.

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>.
SKALL finnas ett eller flera <md:NameIDFormat> som identifierar vilka namn-id format som stödjas.
SKALL finnas <md:SingleSignOnService> i enlighet med definierade bindings.
SKALL finnas en <md:Organization> som identifierar ansvarig organisation.
SKALL finnas minst en <md:ContactPerson contactType="support"> samt minst en <md:ContactPerson contactType="technical">.

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>.
- För krav på SPs funktionscertifikat, se Guide till Inera IdP.
SKALL finnas ett eller flera <md:NameIdFormat> som identifierar vilka namn-id format som stödjs.
SKALL finnas <md:AssertionConsumerService> i enlighet med definierade bindings.
Om <saml2:AttributeStatement> förväntas i <saml2p:Response> SKALL <md:AttributeConsumingService> finnas, den ska beskriver vilka tjänster SP tillhandhåller, samt dess egenskapsbehov.
SKALL 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" samt ett med "contactType" satt till "technical".

Byte av signeringsnyckel

För att kunna genomföra sömlösa nyckelbyten mot IdP:n behöver SP:n ha möjlighet att generera ett SP metadata som innehåller två <KeyDescriptor> på samma gång. Rent praktiskt går ett sådant nyckelbyte till såhär:

SP har redan ett inläst metadata hos IdP med en befintlig nyckel
SP tar fram ett nytt metadata där både den nya och den gamla nyckel finns med som exemplet nedan visar
SP skickar metadatat till IdP för inläsning
IdP läser in metadata
SP genomför nyckelbytet
(Optionellt) SP tar fram ett nytt metadata där enbart den nya nyckel finns med
(Optionellt) SP skickar metadatat med endast den nya nyckeln till IdP för inläsning
(Optionellt) IdP läser in metadata

Exempel för metadata vid övergång till ny nyckel

<KeyDescriptor use="signing">
	<X509Data>
		<X509Certificate>Certifikat 1 ..... </X509Certificate>
	</X509Data>
</KeyDescriptor>
<KeyDescriptor use="signing">
	<X509Data>
		<X509Certificate>Certifikat 2 ..... </X509Certificate>
	</X509Data>
</KeyDescriptor>

Namn-id format

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

Format

Beskrivning

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

Permanent id som återanvänds mellan sessioner. Id är unikt för kombinationen Subjekt och SP.

Id är genererat och ingen personinformation kan utläsas.

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

Aktören får ett nytt id vid varje ny SSO-session. Ett id för varje SP.

Id är genererat och ingen personinformation kan utläsas.

Egenskaper

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

SKALL innehålla 1..* <saml2:AttributeValue> som då är text (kan vara vanlig text eller formatterade text exempelvis JSON).

SAML attribut

Se attributspecifikation.

Egenskaper när uppgifter i attributkälla saknas

Följande egenskaper kan erhållas även om aktören saknas i attributkällan.

http://www.w3.org/2000/09/xmldsig#X509IssuerName (endast vid autentisering genom certifikat)
http://www.w3.org/2000/09/xmldsig#X509SubjectName (endast vid autentisering genom certifikat)
urn:sambi:names:attribute:authnMethod
urn:sambi:names:attribute:levelOfAssurance

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.

I enlighet med SAMBI använder SP Identity Discovery Protocol and Profile [IdPDisco] för att erhålla aktörens SSO IdP.

Autentisering

Begäran

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.
SSL/TLS SKALL användas för att säkra kommunikationen.

Begärans innehåll

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

<saml2:AssertionConsumerServiceURL> och <saml2:ProtocolBinding> eller <saml2:AssertionConsumerServiceIndex>
<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.

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

Svar

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 SKALL stödja HTTP-Artifact för utfärdande av svaret (se HTTP-Artifact kapitel nedan).
<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.

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>.
IDP och SP SKALL signera <saml2p:ArtifactResolve>.
Artifakt format urn:oasis:names:tc:SAML:2.0:artifact-04 SKALL stödjas, definierat i [SAML2Prof].

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).

Underskrift

Tjänster ansluter inte direkt mot IdP:n för underskrift utan denna integration görs mellan underskrifttjänsten och IdP:n.
Metadata för det kan hittas under

<IDPURL>/saml/sign
<IDPURL>/saml/sign/sithseid-other-device
<IDPURL>/saml/sign/sithseid-same-device

Metadatan är för respektive inloggningsmetod.

Denna ska inte användas av SP.

Utloggning (SLO)

IdP propagerar inte utloggningsbegäran till andra SP. Vid korrekt utloggningsbegäran från SP avslutas den aktuella IdP-sessionen vilket förhindrar fortsatt SSO och SP erhåller ett LogoutResponse.

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

Begäran

Bindning och säkerhetskrav

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

Webb-läsare (User Agent)

IdP SKALL stödja aktörs-initierad utloggning.
SP SKALL tillåta aktörs-initierad utloggning.

Svar

Bindning och säkerhetskrav

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

Authentication Context (AuthnContext)

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

Tillitsnivåer (LoA)

Följande tillitsnivåer definieras av denna profil:

Tillitsnivå LoA1
Låg tillit till en aktörs identitet.
Identifikation: http://id.sambi.se/loa/loa1

Tillitsnivå LoA2
Viss tillit till en aktörs identitet.
Identifikation: http://id.sambi.se/loa/loa2

Tillitsnivå LoA3
Hög tillit till en aktörs identitet.
Identifikation: http://id.sambi.se/loa/loa3

Tillitsnivå LoA4
Mycket hög tillit till en aktörs identitet.
Identifikation: http://id.sambi.se/loa/loa4

Identifikationsmetoder

Nedan definieras den identifikationsmetod som initialt stöds. 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å: Beror på egenskaper i certifikatet. Detta hanteras i enlighet med https://www.inera.se/globalassets/projekt/e-identitet-for-offentlig-sektor/dokumentblock/pki/e-identitet-for-offentlig-sektor-pki-struktur.pdf.

Krav: SKALL stödjas av IdP. Denna används för att autentisera aktören genom dess X.509 certifikat (ex SITHS).

Utfärdare

IdP'n SKALL stödja följande utfärdare av användarcertifikat.

SITHS Type 1 CA v1

Felhantering - SAML status

Vid ett fel så SKALL IdP skicka ett <Response> till SP, förutsatt att SP:ns identitet och returadress kan verifieras mot metadata.

Returen skall innehålla en <Status> med <StatusCode> satt till något av följande värden:

Primär `<StatusCode>`	Beskrivning
`urn:oasis:names:tc:SAML:2.0:status:Requester`	Fel av SP, t.ex om inkommande `<AuthnRequest>` inte passerar valideringen som görs av IdP'n
`urn:oasis:names:tc:SAML:2.0:status:Responder`	Fel av IdP, eller t.ex. problem under autentiseringen.
`urn:oasis:names:tc:SAML:2.0:status:VersionMismatch`	Felaktig version på inkommande `<AuthnRequest>`

Vid behov kan IdP inkludera en sekundär <StatusCode> för mer detaljerad felinfo.

Om det råder osäkerhet kring varifrån en begäran kommit, eller vart ett felmeddelande skall skickas, till exempel om det saknas SAML-metadata för SP, så kan IdP inte tillhandahålla något SAML <Response>.

Sekundära statuskoder

Sekundär `<StatusCode>`	Exempel
`urn:oasis:names:tc:SAML:2.0:status:AuthnFailed`	NiAS timeout, felaktigt cert, etc.
`urn:oasis:names:tc:SAML:2.0:status:InvalidAttrNameOrValue`
`urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy`	`<NameIDPolicy>` i autentiseringsbegäran matchar inte tillåtna nameid-format.
`urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext`	`<RequestedAuthnContext>` i autentiseringsbegäran kan inte uppfyllas eller matchar inte Metadata.
`urn:oasis:names:tc:SAML:2.0:status:NoAvailableIDP`
`urn:oasis:names:tc:SAML:2.0:status:NoPassive`
`urn:oasis:names:tc:SAML:2.0:status:NoSupportedIDP`
`urn:oasis:names:tc:SAML:2.0:status:PartialLogout`
`urn:oasis:names:tc:SAML:2.0:status:ProxyCountExceeded`
`urn:oasis:names:tc:SAML:2.0:status:RequestDenied`	IdP vägrar kommunicera med SP av någon anledning, t.ex. säkerhetsrisker.
`urn:oasis:names:tc:SAML:2.0:status:RequestUnsupported`
`urn:oasis:names:tc:SAML:2.0:status:RequestVersionDeprecated`
`urn:oasis:names:tc:SAML:2.0:status:RequestVersionTooHigh`
`urn:oasis:names:tc:SAML:2.0:status:RequestVersionTooLow`
`urn:oasis:names:tc:SAML:2.0:status:ResourceNotRecognized`
`urn:oasis:names:tc:SAML:2.0:status:TooManyResponses`
`urn:oasis:names:tc:SAML:2.0:status:UnknownAttrProfile`
`urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal`
`urn:oasis:names:tc:SAML:2.0:status:UnsupportedBinding`

Användningsstöd

Autentisering

En förutsättning för att en SP skall kunna använda en IdP är att dessa metadata finns registrerat i IdP'n. På samma sätt är det en förutsättning att IdP'ns metadata är registrerat hos SP'n.

SP-initierad

Med detta avses inloggning som initieras hos SP'n, dvs där det är SP'n som sätter samman ett <AuthnRequest> som den senare förmedlar till IdP'n via lämplig binding (exempelvis HTTP-Redirect).

Ur ett aktörsperspektiv så kan man se det som att aktören först försöker komma åt (anger webbadress i browsern) applikationen. SP ansvarar då för att lista ut vilken IdP som skall användas och detta leder sedan till en inloggning via just den IdP'n. Bilden nedan visar ett exempel på detta.

IdP-initierad (Unsolicited SSO)

IdP-initierad inloggning innebär att inloggningsflödet startar i IdP'n istället för hos SP'n. Man kan se det som att det är aktören som väljer IdP'n.

Detta flöde kan vara användbart i de fall en SP kan tillåta autentisering från olika IdP'er, och man vill kunna tillhandahålla en portal där användaren väljer med hjälp av vilken IdP de vill logga in i applikationen. Bilden nedan visar ett exempel på detta.

För att använda IdP-initierad inloggning görs ett GET anrop från aktörens browser in till IdP'n. Formatet på detta är enligt följande.

URL: https://<idphostname>/saml/unsolicited/sso (där <idphostname> byts ut mot adressen för IdP'n). Följande parametrar SKALL / KAN användas.

Parameter	Obligatorisk	Beskrivning
`providerId`	X	Det EntityID som den SP aktören vill logga in till har. Detta SKALL vara URLEncoded.
`shire`		URL till SAML 2.0 Response location hos SP'n. (AssertionConsumerServiceURL). Om den utlämnas väljer IdP'n utifrån SP'ns metadata. Denna SKALL vara URLEncoded.
`target`		Motsvarar RelyState i SAML 2.0 protokollet.
`time`		Används inte idagsläget.

Exempel

Enbart EntityID

https://idp.ineratest.org/saml/unsolicited/sso?providerId=https%3A%2F%2Ftest.example.se%3A443%2Fsp%2Fsaml

Med AssertionConsumerServiceURL

https://idp.ineratest.org/saml/unsolicited/sso?providerId=https%3A%2F%2Ftest.example.se%3A443%2Fsp%2Fsaml&shire=https%3A%2F%2Ftest.example.se%3A443%2Fsp%2Fsaml%2FHTTP-POST

Med RelayState

https://idp.ineratest.org/saml/unsolicited/sso?providerId=https%3A%2F%2Ftest.example.se%3A443%2Fsp%2Fsaml&target=ss%3Amem%3A6aa181259dc9ba41725ce239fe77925c430e0132cd92076dc16ebbe9806866c7

Anvisningstjänst

Hanteras av SAMBI för anslutna IdP:er/SP:ar enligt tekniska kraven under sambi anslutningsavtal.

Ange vilka attribut som SP efterfrågar

I SP-metadatat SKALL det specificeras vilka attribut som IdP:n skall (bör) leverera till SP:n. Detta görs genom att ange 1..* <md:AttributeConsumerService>.

Se Attributstyrning SAML för mer information.

Tidsstämplar i biljetten

En saml-biljett innehåller ett flertal tids-stämplar som man som SP bör känna till.

Assertion → IssueInstant

Tidpunkt då saml-biljetten skapats av IdP:n

<saml2:Assertion
	ID="_466ef75b0524a76c1602e239c79bebcd33a683f1be0dff661bbcbcd80fef"
	IssueInstant="2018-06-12T17:25:57.695Z" Version="2.0"
	xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

SubjectConfirmationData → notOnOrAfter

SubjectConfirmation begränsar tiden ”användaren” har på sig att presentera biljetten för SP:n. (för att undvika replay-attacker), vilket i normalfallet sätts en kort stund efter att IdP:n skapade saml-intyget (1 min i detta exempel)

<saml2:SubjectConfirmationData
	InResponseTo="4f80dd94-86f2-4ac1-8c41-ecbbe67edd3b"
	NotOnOrAfter="2018-06-12T17:26:57.703Z" Recipient="https://sp.dev.inera.test:8881/api/saml/sso/HTTP-POST"/>

Conditions → notOnOrAfter

IdP:n kan sätta en tidpunkt fram till vilken biljetten är giltig. Om det sätts och hur länge kan t.ex. styras genom ett ramverk (typ sambi) i en federation. Men i princip skulle en IdP kunna sätta en giltighetstid på 1h medan en annan inte har någon giltighetstid, vilket man som SP då måste hantera.

<saml2:Conditions NotOnOrAfter="2018-06-12T18:25:57.701Z">

AuthnStatement → AuthnInstant

Tidpunkt då autentisering skedde i IdP:n

<saml2:AuthnStatement AuthnInstant="2018-06-12T17:25:53.875Z" SessionIndex="ecdba7f0-dafd-42ae-8de1-d38b7f2e2946">

AuthnStatement → SessionNotOnOrAfter

Anger IdP sessionens giltighetstid.

Sätts ej av Inera IdP pga dess inverkan på SP'ns sessionshantering i vissa SP produkter/ramverk (ex. Shibboleth SP), där SP sessionen avslutas då den angivna tiden passerats.

Exempel

IdP Metadata

Notera att detta enbart är ett exempel. Korrekt metadata måste inhämtas från aktuell IdP.

<md:EntityDescriptor entityID="https://auth.dev.inera.test:8443/saml" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:idpdisco="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
	xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
	xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
  <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/2001/04/xmldsig-more#rsa-sha256"/>
      <ds:Reference URI="">
        <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/2001/04/xmlenc#sha256"/>
        <ds:DigestValue>9I2CWL2vgsDRB0gaQsCq8cdMWUDuY99m7Qgh0imvHv0=</ds:DigestValue>
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>jQaDxr...
</ds:SignatureValue>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MIIDtj...</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
  </ds:Signature>
  <md:Extensions>
    <mdattr:EntityAttributes>
      <saml2:Attribute Name="urn:oasis:names:tc:SAML:attribute:assurance-certification" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml2:AttributeValue>http://id.sambi.se/loa/loa2</saml2:AttributeValue>
        <saml2:AttributeValue>http://id.sambi.se/loa/loa3</saml2:AttributeValue>
        <saml2:AttributeValue>http://id.sambi.se/loa/loa4</saml2:AttributeValue>
      </saml2:Attribute>
    </mdattr:EntityAttributes>
  </md:Extensions>
  <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509Certificate>MIIFZj...</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509Certificate>MIID2...</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://auth.dev.inera.test:8443/saml/artifact/SOAP" index="0" isDefault="true"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://auth.dev.inera.test:8443/saml/slo/HTTP-Redirect"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://auth.dev.inera.test:8443/saml/slo/HTTP-Artifact"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://auth.dev.inera.test:8443/saml/slo/HTTP-POST"/>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://auth.dev.inera.test:8443/saml/sso/HTTP-Redirect"/>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://auth.dev.inera.test:8443/saml/sso/HTTP-Artifact"/>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://auth.dev.inera.test:8443/saml/sso/HTTP-POST"/>
    <saml2:Attribute FriendlyName="commissionHsaId" Name="http://sambi.se/attributes/1/commissionHsaId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
    <saml2:Attribute FriendlyName="commissionName" Name="http://sambi.se/attributes/1/commissionName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
    <saml2:Attribute FriendlyName="commissionPurpose" Name="http://sambi.se/attributes/1/commissionPurpose" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
    <saml2:Attribute FriendlyName="commissionRight" Name="http://sambi.se/attributes/1/commissionRight" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
    <saml2:Attribute FriendlyName="employeeHsaId" Name="http://sambi.se/attributes/1/employeeHsaId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
    <saml2:Attribute FriendlyName="givenName" Name="http://sambi.se/attributes/1/givenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
    ...
  </md:IDPSSODescriptor>
</md:EntityDescriptor>

SP Metadata

Notera att detta enbart är ett exempel. Korrekt metadata måste sammanställas av den egna SP'n med dess aktuella uppgifter.

<md:EntityDescriptor entityID="https://sp.dev.inera.test:8881"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:idpdisc="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol"
	xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"
	xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
	xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
  <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:Extensions>
      <idpdisc:DiscoveryResponse Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location="https://sak.ost.se:443/spadmin" index="0" isDefault="true"/>
    </md:Extensions>
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509Certificate>MIIFZjCCB...</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://sp.dev.inera.test:8881/api/saml/artifact/SOAP" index="1" isDefault="true"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://sp.dev.inera.test:8881/api/saml/slo/HTTP-Artifact"/>
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sp.dev.inera.test:8881/api/saml/slo/HTTP-POST"/>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sp.dev.inera.test:8881/api/saml/sso/HTTP-POST" index="1" isDefault="true"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://sp.dev.inera.test:8881/api/saml/sso/HTTP-Artifact" index="2"/>
    <md:AttributeConsumingService index="0" isDefault="true">
      <md:ServiceName xml:lang="sv">Lite attribut</md:ServiceName>
      <md:RequestedAttribute FriendlyName="authnMethod" Name="urn:sambi:names:attribute:authnMethod" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
            <md:RequestedAttribute FriendlyName="x509IssuerName" Name="http://www.w3.org/2000/09/xmldsig#x509IssuerName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
      <md:RequestedAttribute FriendlyName="x509SubjectName" Name="http://www.w3.org/2000/09/xmldsig#x509SubjectName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
      <md:RequestedAttribute FriendlyName="levelOfAssurance" Name="urn:sambi:names:attribute:levelOfAssurance" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
    </md:AttributeConsumingService>
    <md:AttributeConsumingService index="1">
      <md:ServiceName xml:lang="sv">Mera attribut</md:ServiceName>
      <md:RequestedAttribute FriendlyName="employeeHsaId" Name="http://sambi.se/attributes/1/employeeHsaId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
      <md:RequestedAttribute FriendlyName="givenName" Name="http://sambi.se/attributes/1/givenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
      <md:RequestedAttribute FriendlyName="surname" Name="http://sambi.se/attributes/1/surname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
      <md:RequestedAttribute FriendlyName="systemRole" Name="http://sambi.se/attributes/1/systemRole" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
      <md:RequestedAttribute FriendlyName="organizationIdentifier" Name="http://sambi.se/attributes/1/organizationIdentifier" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
      <md:RequestedAttribute FriendlyName="organizationName" Name="http://sambi.se/attributes/1/organizationName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
      <md:RequestedAttribute FriendlyName="authnMethod" Name="urn:sambi:names:attribute:authnMethod" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
      <md:RequestedAttribute FriendlyName="x509IssuerName" Name="http://www.w3.org/2000/09/xmldsig#x509IssuerName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
      <md:RequestedAttribute FriendlyName="x509SubjectName" Name="http://www.w3.org/2000/09/xmldsig#x509SubjectName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
      <md:RequestedAttribute FriendlyName="levelOfAssurance" Name="urn:sambi:names:attribute:levelOfAssurance" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>
    </md:AttributeConsumingService>
  </md:SPSSODescriptor>
  <md:Organization>
    <md:OrganizationName xml:lang="sv">Test SP</md:OrganizationName>
    <md:OrganizationDisplayName xml:lang="sv">Test SP</md:OrganizationDisplayName>
    <md:OrganizationURL xml:lang="sv">https://sp.dev.inera.test:8881/sp/saml</md:OrganizationURL>
  </md:Organization>
  <md:ContactPerson contactType="support" xml:lang="sv">
    <md:Company>CGI</md:Company>
    <md:GivenName>Anders</md:GivenName>
    <md:SurName>Andersson</md:SurName>
    <md:EmailAddress>anders.andersson@example.com</md:EmailAddress>
    <md:TelephoneNumber>0701234567</md:TelephoneNumber>
  </md:ContactPerson>
  <md:ContactPerson contactType="technical" xml:lang="sv">
    <md:Company>CGI</md:Company>
    <md:GivenName>Anders</md:GivenName>
    <md:SurName>Andersson</md:SurName>
    <md:EmailAddress>anders.andersson@example.com</md:EmailAddress>
    <md:TelephoneNumber>0701234567</md:TelephoneNumber>
  </md:ContactPerson>
</md:EntityDescriptor>

Autentiseringsbegäran

Notera att detta enbart är ett exempel. Korrekt AuthnRequest måste sammanställas av SP'n med för den korrekt uppgifter som matchar dessa tidigare registrerade metadata.

<saml2p:AuthnRequest
	Destination="https://auth.dev.inera.test:8443/saml/sso/HTTP-Redirect"
	ForceAuthn="false"
	ID="219c3745-4399-4366-82ef-ebc92f3af88f"
	IssueInstant="2018-06-13T05:51:17.122Z"
	ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
	Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
	AttributeConsumingServiceIndex="0">
  <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://sp.dev.inera.test:8881</saml2:Issuer>
  <saml2p:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
  <saml2p:RequestedAuthnContext Comparison="exact">
    <saml2:AuthnContextClassRef xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://id.sambi.se/loa/loa3</saml2:AuthnContextClassRef>
  </saml2p:RequestedAuthnContext>
</saml2p:AuthnRequest>

Autentiseringssvar

Notera att detta enbart är ett exempel. Svaret kommer vara baserat på aktuell SP's AuthnRequest i kombination med dessa metadata, och för IdP'n gällande uppgifter.

<saml2p:Response Destination="https://sp.dev.inera.test:8881/api/saml/sso/HTTP-POST" ID="_429608f164c7d54a3ff6fd24717312894416d804316ce2be22b3a5cb448a" InResponseTo="219c3745-4399-4366-82ef-ebc92f3af88f" IssueInstant="2018-06-13T05:52:36.810Z" Version="2.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://auth.dev.inera.test:8443/saml</saml2:Issuer>
  <saml2p:Status>
    <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </saml2p:Status>
  <saml2:Assertion ID="_65fe31566c29c13ece81904bdbe0d5ca20fb187394e893603aeb2e01ebe9" IssueInstant="2018-06-13T05:52:36.812Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://auth.dev.inera.test:8443/saml</saml2: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/2001/04/xmldsig-more#rsa-sha256"/>
        <ds:Reference URI="#_65fe31566c29c13ece81904bdbe0d5ca20fb187394e893603aeb2e01ebe9">
          <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#">
              <ec:InclusiveNamespaces PrefixList="xsd" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </ds:Transform>
          </ds:Transforms>
          <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
          <ds:DigestValue>bdYp4d/01W7JsbC7Ga9UugSX99YZK6NO71CHJGAMFII=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>OtuRPSg...
</ds:SignatureValue>
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509Certificate>MIIDtj...</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </ds:Signature>
    <saml2:Subject>
      <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">9c01e3aa-3046-45d2-a0c7-288842cfb50b</saml2:NameID>
      <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml2:SubjectConfirmationData InResponseTo="219c3745-4399-4366-82ef-ebc92f3af88f" NotOnOrAfter="2018-06-13T05:53:36.828Z" Recipient="https://sp.dev.inera.test:8881/api/saml/sso/HTTP-POST"/>
      </saml2:SubjectConfirmation>
    </saml2:Subject>
    <saml2:Conditions NotOnOrAfter="2018-06-13T06:52:36.824Z">
      <saml2:AudienceRestriction>
        <saml2:Audience>https://sp.dev.inera.test:8881</saml2:Audience>
      </saml2:AudienceRestriction>
    </saml2:Conditions>
    <saml2:AttributeStatement>
      <saml2:Attribute FriendlyName="commissionHsaId" Name="http://sambi.se/attributes/1/commissionHsaId" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">SE111-UPPDRAG-JLL-TEKSYSADMIN</saml2:AttributeValue>
      </saml2:Attribute>
      ...
    </saml2:AttributeStatement>
    <saml2:AuthnStatement AuthnInstant="2018-06-13T05:52:09.114Z" SessionIndex="60fd0dae-8277-4a22-a797-3e2bee41318e">
      <saml2:AuthnContext>
        <saml2:AuthnContextClassRef>http://id.sambi.se/loa/loa3</saml2:AuthnContextClassRef>
      </saml2:AuthnContext>
    </saml2:AuthnStatement>
  </saml2:Assertion>
</saml2p:Response>

Referenser

Referens	Hänvisning
eGov	https://kantarainitiative.github.io/SAMLprofiles/eGovImplProfile.html
SAML2Int	https://saml2int.org/profile/current/
SAML2Core	https://www.oasis-open.org/committees/download.php/35711/sstc-saml-core-errata-2.0-wd-06-diff.pdf
SAML2Prof	https://www.oasis-open.org/committees/download.php/35389/sstc-saml-profiles-errata-2.0-wd-06-diff.pdf
SAML2Bind	https://www.oasis-open.org/committees/download.php/35387/sstc-saml-bindings-errata-2.0-wd-05-diff.pdf
SAML2Conf	https://www.oasis-open.org/committees/download.php/35393/sstc-saml-conformance-errata-2.0-wd-04-diff.pdf
SAML2Err
SAML2Meta	https://www.oasis-open.org/committees/download.php/35391/sstc-saml-metadata-errata-2.0-wd-04-diff.pdf
IdPDisco
MetaIOP
XMLEnc
XMLDSig
IAFAL	Identity Assurance Framework:Assurance Levels
SAMBI-A attributspecifikation 1.0	SAMBIattributspecifikation 1.0 https://www.sambi.se/teknik/attribut/attribut/
SAMBI-T	SAMBI Tekniska krav https://www.sambi.se/teknik/

Bilaga 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 propagering av utloggning.
[eGov2] hänvisar till [SAML2Prof] som definierar att <saml2p:ArtifactResolve> BÖR signeras, denna profil definierar detta som SKALL.

2.6 SAML-Profil

Innehållsförteckning

Revisionshistorik

Introduktion

Notation

XML namnrymd

Metadata och förlitande hantering

IdP Metadata

SP Metadata

Byte av signeringsnyckel

Namn-id format

Egenskaper

SAML attribut

Egenskaper när uppgifter i attributkälla saknas

SSO IdP Identifiering

Autentisering

Begäran

Bindningar och säkerhetskrav

Begärans innehåll

Svar

Bindningar och säkerhetskrav

HTTP-Artifact

Svarets innehåll

Underskrift

Utloggning (SLO)

Begäran

Bindning och säkerhetskrav

Webb-läsare (User Agent)

Svar

Bindning och säkerhetskrav

Authentication Context (AuthnContext)

Tillitsnivåer (LoA)

Identifikationsmetoder

Utfärdare

Felhantering - SAML status

Sekundära statuskoder

Användningsstöd

Autentisering

SP-initierad

IdP-initierad (Unsolicited SSO)

Exempel

Anvisningstjänst

Ange vilka attribut som SP efterfrågar

Tidsstämplar i biljetten

Assertion → IssueInstant

SubjectConfirmationData → notOnOrAfter

Conditions → notOnOrAfter

AuthnStatement → AuthnInstant

AuthnStatement → SessionNotOnOrAfter

Exempel

IdP Metadata

SP Metadata

Autentiseringsbegäran

Autentiseringssvar

Referenser

Bilaga 1

Avsteg från arbetsunderlaget