SAML-Profil

Owned by Former user (Deleted)
Last updated: okt. 07, 2024 by Pär Hylback

Innehållsförteckning

Revisionshistorik

 Visa innehållsförteckning

Version

Datum

Författare

Kommentar

0.1

  

Pär Hylback
  • Kopierat från gammal version
0.2 Stefan Ehlert
  • Justerat stycke om nyckelbyten
1.0 Pietu HammarströmGodkä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

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

PrefixNamnrymd
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>.
  • 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:

  1. SP har redan ett inläst metadata hos IdP med en befintlig nyckel
  2. SP tar fram ett nytt metadata där både den nya och den gamla nyckel finns med som exemplet nedan visar
  3. SP skickar metadatat till IdP för inläsning
  4. IdP läser in metadata
  5. SP genomför nyckelbytet
  6. (Optionellt) SP tar fram ett nytt metadata där enbart den nya nyckel finns med
  7. (Optionellt) SP skickar metadatat med endast den nya nyckeln till IdP för inläsning
  8. (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:RequesterFel av SP, t.ex om inkommande <AuthnRequest>
inte passerar valideringen som görs av IdP'n
urn:oasis:names:tc:SAML:2.0:status:ResponderFel av IdP, eller t.ex. problem under autentiseringen.
urn:oasis:names:tc:SAML:2.0:status:VersionMismatchFelaktig 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:AuthnFailedNiAS 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:RequestDeniedIdP 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.

ParameterObligatoriskBeskrivning
providerIdXDet 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

ReferensHä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.



Publik Information